public inbox for [email protected]
help / color / mirror / Atom feedFrom: Mihail Nikalayeu <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Wed, 28 Jan 2026 03:06:00 +0100
Message-ID: <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com> (raw)
In-Reply-To: <88003.1769511456@localhost>
References: <[email protected]>
<11247.1767609087@localhost>
<11558.1767609632@localhost>
<141054.1767891540@localhost>
<CADzfLwU-OmxW3t3AoQo9=K7uq4G1yZ-txcetzW3jbcVxV_pJew@mail.gmail.com>
<137668.1768235610@localhost>
<CADzfLwUJSHKGxYw+vMUZ_Hr2YeuxO2Q5w13HKgUUN1725tjY5Q@mail.gmail.com>
<CADzfLwXJ+4s1tJuG9injcxAUP3urj9D6dUAPOCaX33UeiUxrRQ@mail.gmail.com>
<74802.1769071060@localhost>
<CADzfLwVZ_DeU_3avD=G4ZHFJJgZ0EOFzxnmWxwyB23zsS-uxjA@mail.gmail.com>
<CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com>
<3901.1769412880@localhost>
<88003.1769511456@localhost>
Hello!
> PROC_IN_VACUUM shouldn't be used for the same reason
StartupDecodingContext()
> avoids setting PROC_IN_LOGICAL_DECODING in transaction. I've removed
that and
> the tests work for me. Especially the "cache lookup failed" error is
almost
> certainly related. Please let me know if you still get the other errors
Yes, now it is passing.
> (Except for 2, which is probably due to the MVCC-unsafe behavior, as
discussed
> earlier.)
Not happening too. BTW, it was non MVCC-related, because in that case
relcheckxmin would catch it.
What if:
1) add new PROC_IN_REPACK flag
2) use it in catalog horizon, but not in data (like was done in [0] for
PROC_IN_SAFE_IC)
And after we have options:
3) do not "table_close(NewHeap, NoLock);" -
keep ShareUpdateExclusiveLock all the time to prevent VACUUM enter
4) do not heap_page_prune_opt in repack transaction (just using simple
flag)
Or
3) preserve xmin/xmax of original transaction in repacked data
4) but better to keep ShareUpdateExclusiveLock anyway
Seems to be enough.
> The 0006 part needs more work (definitely beyond PG 19).
This is sad, because if you are in a situation then you need REPACK -
pinning the horizon for too long may just finish your DB....
And also, even with 0006 we still need to build indexes, which might pin it
for long (even duration caused by a single index).
Mikhail.
[0]:
https://github.com/postgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d
view thread (31+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Adding REPACK [concurrently]
In-Reply-To: <CADzfLwXdaJh4awQstc2PpBz=EBBc6tMA50wYLqMoEtY5B+WUnA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox