| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Make unlogged table resets detectable |
| Date: | 2021-06-08 20:08:56 |
| Message-ID: | 1175595.1623182936@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2021-06-08 20:23:45 | Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command |
| Previous Message | David Christensen | 2021-06-08 19:29:28 | Re: DELETE CASCADE |