Re: Non-null values of recovery functions after promote or crash of primary

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Martín Marqués <martin(at)2ndquadrant(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Non-null values of recovery functions after promote or crash of primary
Date: 2019-10-08 18:03:02
Message-ID: 20191008180302.GP6962@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Greetings,

* Martín Marqués (martin(at)2ndquadrant(dot)com) wrote:
> pg_last_wal_receive_lsn()
> pg_last_wal_replay_lsn()
> pg_last_xact_replay_timestamp()
>
> Under normal circumstances we would expect to receive NULLs from all
> three functions on a primary node, and code comments back up my thoughts.

Agreed.

> The problem is, what if the node is a standby which was promoted without
> restarting, or that had to perform crash recovery?
>
> So during the time it's recovering the values in ` XLogCtl` are updated
> with recovery information, and once the recovery finishes, due to crash
> recovery reaching a consistent state, or a promotion of a standby
> happening, those values are not reset to startup defaults.
>
> That's when you start seeing non-null values returned by
> `pg_last_wal_replay_lsn()`and `pg_last_xact_replay_timestamp()`.
>
> Now, I don't know if we should call this a bug, or an undocumented
> anomaly. We could fix the bug by resetting the values from ` XLogCtl`
> after finishing recovery, or document that we might see non-NULL values
> in certain cases.

IMV, and not unlike other similar cases I've talked about on another
thread, these should be cleared when the system is promoted as they're
otherwise confusing and nonsensical.

Thanks,

Stephen

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Martín Marqués 2019-10-08 19:56:38 Re: Non-null values of recovery functions after promote or crash of primary
Previous Message PG Bug reporting form 2019-10-08 17:08:53 BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12

Browse pgsql-hackers by date

  From Date Subject
Next Message Anders Åstrand 2019-10-08 18:07:02 Re: PATCH: Add uri percent-encoding for binary data
Previous Message Stephen Frost 2019-10-08 17:55:56 Re: Transparent Data Encryption (TDE) and encrypted files