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
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 |