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

Hi,

Thanks for the reviews.

On Sun, Nov 1, 2026 at 4:27 PM Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> wrote:

> == GUC name (bikeshedding) ==
> I don't think we should spend too much time on this right now, but I
> thought I should mention it for later.
>
I agree, we can change it later.

> == wal_level minimal ==
>
> The lsn is being logged also when the cluster is set to wal_level =
> minimal. The docs say "The minimal level generates the least WAL volume.
> It logs no row information for permanent relations in transactions that
> create or rewrite them." [1]
>
I added an XLogIsNeeded() check to RegisterDropOrTruncateTable, so
nothing is logged when wal_level is minimal. I also added your test
and a note in the docs.

> == errhint in AtEOXact_DropOrTruncateTable (nit) ==
>
> The two branches in "if (info->is_truncate) can be simplified into a
> single ereport call, e.g.
>
Done.

On Thu, Nov 5, 2026 at 12:17 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> 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)
>
Yes, I was able to reproduce this.

> Logging in RecordTransactionCommit right after END_CRIT_SECTION could
> be a better choice that would fix this, and could work without
> XactLastCommitStart?
>
I moved the logging into RecordTransactionCommit, right after
END_CRIT_SECTION. It uses a local commit_lsn, so XactLastCommitStart
is removed, and AtEOXact_DropOrTruncateTable now only frees the list.

With this change, the LSN is logged before the kill in your scenario,
and recovering to that LSN brings the table back.

v13 attached.

Thanks,
Salma Elsayed