Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
От
Bertrand Drouvot
Тема
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Дата
Msg-id
ae8z7SlGtvjpm3Ic@bdtpg
Ответ на
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE (Bharath Rupireddy)
Список
Дерево обсуждения
Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Ajin Cherian <itsajin@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Chao Li <li.evan.chao@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Chao Li <li.evan.chao@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Chao Li <li.evan.chao@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE shveta malik <shveta.malik@gmail.com>
Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Hi, On Mon, Apr 27, 2026 at 01:36:00AM -0700, Bharath Rupireddy wrote: > Hi, > > On Sun, Apr 26, 2026 at 8:45 PM shveta malik wrote: > > > > > I prefer adding the new struct to carry both table_infos and the > > > current index into it with the current value-per-call SRF function, > > > unless others have better ideas. > > > > +1. It is simpler than the Materialization concept. > > > > > If okay, I will send a new patch > > > soon. Thank you! > > > > Sure, Thanks! > > Attached v2 patch. I also refactored the test a bit. Please review. Thank you! Thanks! I've 2 comments: 1/ What about having just one curr_idx increment? (right after list_nth(), before the skip checks). I think that would be less error-prone if new skip conditions are added later. 2/ I think that the test is racy and could also succeed even without the fixes. Indeed, I think that the drops can complete before any concurrent polling happens (I can see it by adding a pg_sleep(2) before the first poll in the DO block). What about using an injection point to ensure a relation is removed during the polling? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления
От: shveta malik
Дата: