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
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 server
crashes, you'll be missing only one s
15 matches
Mail list logo
