On Fri, 2021-06-04 at 09:42 +0300, Heikki Linnakangas wrote:
> I'd suggest using a counter rather than a flag. With a flag, if one
> client clears the flag to acknowledge that a truncation happened,
> others
> might miss it. See also ABA problem.
This feels like it's getting more complex.
Stepping back, maybe unlogged tables are the wrong level to solve this
problem. We could just have a "crash counter" in pg_control that would
be incremented every time a crash happened (and all unlogged tables are
reset). It might be a number or maybe the LSN of the startup checkpoint
after the most recent crash.
A SQL function could read the value. Perhaps we'd also have a SQL
function to reset it, but I don't see a use case for it.
Then, it's up to the client to check it against a stored value, and
clear/repopulate unlogged tables as necessary.
Regards,
Jeff Davis
