Re: PoC: Simplify recovery after dropping a table by LOGGING the restore LSN

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Salma Elsayed <salmasayed182003(at)gmail(dot)com>, Kirk Wolak <wolakk(at)gmail(dot)com>
Subject: Re: PoC: Simplify recovery after dropping a table by LOGGING the restore LSN
Date: 2026-11-04 22:17:18
Message-ID: CAN4CZFOe2Ujm7ZhUmAh3=n=7MxkqQY=eH8Ds_dJTT7E8P-O30A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

DROP TABLE also has a similar loss window as DROP DATABASE: if the
backend dies with kill -9 / immediate shutdown with a committed DROP
TABLE waiting for synchronous replication.
(create table; alter system set
synchronous_standby_names='nosuchstandby'; drop table; kill)

Logging in RecordTransactionCommit right after END_CRIT_SECTION could
be a better choice that would fix this, and could work without
XactLastCommitStart?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-11-04 22:22:03 Re: Fix cumulative WAL statistics double-counting from parallel workers
Previous Message Michael Paquier 2026-11-04 22:16:45 Re: Track skipped tables during autovacuum and autoanalyze