DROP TABLE can crash the replication sync worker

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: DROP TABLE can crash the replication sync worker
Date: 2021-02-03 09:23:20
Message-ID: CAHut+Pu7Z4a=omo+TvK5Gub2hxcJ7-3+Bu1FO_++fpFTW0oQfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hackers.

As discovered in another thread [master] there is an *existing* bug in
the PG HEAD code which can happen if a DROP TABLE is done at same time
a replication tablesync worker is running.

It seems the table's relid that the sync worker is using gets ripped
out from underneath it and is invalidated by the DROP TABLE. Any
subsequent use of that relid will go wrong. In the particular test
case which found this, the result was a stack trace when a LOG message
tried to display the table name of the bad relid.

PSA the patch code to fix this. The patch disallows DROP TABLE while
any associated tablesync worker is still running. This fix was already
confirmed OK in the other thread [v25]

----
[master] https://www.postgresql.org/message-id/CAHut%2BPtSO4WsZwx8z%3D%2BYp_OWpxFmmFi5WX6OmYJzULNa2NV89g%40mail.gmail.com
[v25] https://www.postgresql.org/message-id/CAHut%2BPtAKP1FoHbUEWN%2Ba%3D8Pg_njsJKc9Zoz05A_ewJSvjX2MQ%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

Attachment Content-Type Size
v1-0001-DROP-TABLE-breaks-sync-worker-relid.patch application/octet-stream 2.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-02-03 09:54:20 Re: Printing backtrace of postgres processes
Previous Message Dilip Kumar 2021-02-03 09:17:56 Re: Correct comment in StartupXLOG().