Re: Make unlogged table resets detectable
От | Jeff Davis |
---|---|
Тема | Re: Make unlogged table resets detectable |
Дата | |
Msg-id | 666c2599a07addea00ae2d0af96192def8441974.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Make unlogged table resets detectable (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Make unlogged table resets detectable
|
Список | 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
В списке pgsql-hackers по дате отправления: