On Fri, Mar 04, 2022 at 10:12:27AM -0600, Justin Pryzby wrote:
> Is this patch targetting pg15 ?
> There's no discussion since June.
>
> Latest at 2021-06-08 21:29:25 by Jeff Davis
This is too long, so let's discard this patch for now.
--
Michael
signature.asc
Description: PGP signature
Is this patch targetting pg15 ?
There's no discussion since June.
Latest at 2021-06-08 21:29:25 by Jeff Davis
2022-02-02 16:37:58 Julien Rouhaud (rjuju) Closed in commitfest 2022-01
with status: Moved to next CF
2021-12-03 06:18:05 Michael Paquier (michael-kun) Closed in commitfest
On Tue, 2021-06-08 at 16:08 -0400, Tom Lane wrote:
> 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.
It requires some other bookkeeping on the part of the sha
Jeff Davis 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
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
Robert Haas writes:
> On Mon, Jun 7, 2021 at 11:46 PM Michael Paquier wrote:
>> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
>>> +1. I'd support recording the time of the last crash recovery, as
>>> well as having a counter. I think an LSN would not be as useful
>>> as a timestamp.
On Mon, Jun 7, 2021 at 11:46 PM Michael Paquier wrote:
> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> > +1. I'd support recording the time of the last crash recovery, as
> > well as having a counter. I think an LSN would not be as useful
> > as a timestamp.
>
> One could guess a t
On Tue, Jun 08, 2021 at 12:46:05PM +0900, Michael Paquier wrote:
> On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> > +1. I'd support recording the time of the last crash recovery, as
> > well as having a counter. I think an LSN would not be as useful
> > as a timestamp.
>
> One could
On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> +1. I'd support recording the time of the last crash recovery, as
> well as having a counter. I think an LSN would not be as useful
> as a timestamp.
One could guess a timestamp based on a LSN, no? So I'd like to think
the opposite act
On Mon, Jun 07, 2021 at 02:56:57PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
> >> 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 incr
Robert Haas writes:
> On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
>> 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
>>
On Fri, Jun 4, 2021 at 8:41 PM Jeff Davis wrote:
> 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 numbe
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.
Stepp
On 03/06/2021 23:04, Jeff Davis wrote:
One problem with unlogged tables is that the application has no way to
tell if they were reset, or they just happen to be empty.
This can be a problem with sharding, where you might have different
shards of an unlogged table on different servers. If one ser
14 matches
Mail list logo
