Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Antonin Houska <ah@cybertec.at>)
Responses Re: Adding REPACK [concurrently]
List pgsql-hackers
Hello, Antonin!

More comments - now for 0005 (but v29, but I think they are mostly up to date).

--- 0005 ---

> potentiallly
extra 'l' in commit message

> Memory the queue is located int.
"in"?

>  again if its still eligible
if it's still eligible

> int initialized;
probably better to be bool (as in shared)

> DecodingWorkerState
such type does not exists in commit

> REPACK_WORKER_MAIN
Not used in code anywhere.

> int64 timeout = 0;
> WaitLSNResult   res;
formatting issue here (tab vs space)

> if (size >= MaxAllocSize)
Seems like we lost that check, I think it may be executed on storing
the data or before "tup = (HeapTuple) palloc(HEAPTUPLESIZE + t_len);"
in apply_concurrent_changes

> bool done;
I still think it is a confusing name.

> chgdst.file_seq = WORKER_FILE_SNAPSHOT + 1;
I think it is better to increment it once a snapshot is received. And
rename to last_processed/last_improrted to be aligned with
last_exported.

Best regards,
Mikhail.



pgsql-hackers by date:

Previous
From: Matheus Alcantara
Date:
Subject: Re: PL/Python initialization cleanup
Next
From: Jeff Davis
Date:
Subject: Use CASEFOLD() internally rather than LOWER()