On 2025-Jan-31, Antonin Houska wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > Something that Robert Haas just mentioned to me is handling of row
> > locks: if concurrent transactions are keeping rows in the original table
> > locked (especially SELECT FOR KEY SHARE, since that's not considered by
> > logical decoding at present and it would be possible to break foreign
> > keys if we just do nothing), them we need these to be "transferred" to
> > the new table somehow.
>
> The current implementation acquires AccessExclusiveLock on the table
> (supposedly for very short time) so it can swap the table and index
> files. Once we have that lock, I think the transactions holding the row locks
> should no longer be running. Or can the row lock "survive" the table lock
> somehow?
Oh right, I forgot about this step. That seems like it should be
sufficient to protect against that problem.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".
