Re: Make unlogged table resets detectable - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Make unlogged table resets detectable
Date
Msg-id 1175595.1623182936@sss.pgh.pa.us
Whole thread Raw
In response to Re: Make unlogged table resets detectable  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Make unlogged table resets detectable  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Tue, 2021-06-08 at 12:52 -0400, Tom Lane wrote:
>> Yeah.  If there are actually use-cases for knowing both things, then
>> we ought to record both.  However, it's not real clear to me why
>> LSN would be interesting.

> Let me expand on my use case: in a sharded environment, how do you
> figure out if you need to repopulate an UNLOGGED table?

Since we don't put LSNs into unlogged tables, nor would the different
shards be likely to have equivalent LSNs, I'm not seeing that LSN is
remarkably better for this than a timestamp.

> 1. Do we want a way to reset the counter? If so, should it be done with
> pg_resetwal or a superuser SQL function?

I'd be kind of inclined to say no, short of pg_resetwal, and maybe
not then.

> 2. It would be helpful to also know the last time a promotion happened,

I'm not following this either.  How do you unpromote a node?

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: DELETE CASCADE
Next
From: Jeff Davis
Date:
Subject: Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command