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

Hi Jim,

Thanks for your response.

>
> postgres=# create table t (g int, pad text);
> CREATE TABLE
> postgres=# insert into t select g, repeat('x', 100) from
> generate_series(1, 600000) g;
> INSERT 0 600000
> postgres=# create database db;
> CREATE DATABASE
> postgres=# update t set g = g + 1;
> UPDATE 600000
> postgres=# set log_object_drops to on;
> SET
> postgres=# set statement_timeout = '20ms';
> SET
> postgres=# drop database db;
> ERROR: canceling statement due to statement timeout
>
> postgres=# select oid,datname from pg_database where datname = 'db';
> oid | datname
> -------+---------
> 16414 | db
> (1 row)
>
>
> .. but the logs show:
>
> LOG: database "db" (OID 16414) dropped, lsn=0/47AAC7E0
>

But in this exact scenario, didn't the database become invalid?
postgres=# \c db
connection to server on socket "/tmp/.s.PGSQL.5435" failed: FATAL:
cannot connect to invalid database "db"
HINT: Use DROP DATABASE to drop invalid databases.

The LSN value itself is fine to recover to. The problem is the word
"dropped," since the drop did not actually complete.

I tested with injection points. If an error occurs after v9's logging
point, we get the same situation again: the log assumes the database
was dropped when it was not. I moved the LSN registration earlier in
dropdb(), so that a failure after that point still has something to
log.

I am now using a callback, similar to how we handle DROP TABLE. On
commit, we log the LSN as before. On abort, we still log a message,
but state the drop did not complete instead of saying it dropped. If
"drop database db;" is retried on an already invalid database, we
still log a message, but without a recovery_target_lsn, and we state
that the original recovery point is not known to this session.

Attached is v10 with 0002 for the callback implementation. Let me know
what you think.
It still needs more testing.

Best regards,
Salma Elsayed