Re: Make unlogged table resets detectable

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Make unlogged table resets detectable
Date: 2021-06-05 00:41:24
Message-ID: 666c2599a07addea00ae2d0af96192def8441974.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2021-06-05 01:32:36 Re: A new function to wait for the backend exit after termination
Previous Message Jeff Davis 2021-06-05 00:34:36 Re: alter table set TABLE ACCESS METHOD