On Thu, Jul 29, 2021 at 3:16 PM Andres Freund wrote:
> Not sure there's enough concensus on the idea for that. I personally
> think that's a good approach at reducing relevant complexity, but I
> don't know if anybody agrees...
There does seem to be agreement on the proposed patch, so I have comm
Hi,
On 2021-07-29 12:49:19 +0800, Julien Rouhaud wrote:
> On Thu, Jul 29, 2021 at 3:28 AM Andres Freund wrote:
> >
> > [1] I really wish somebody had the energy to just remove single user and
> > bootstrap modes. The degree to which they increase complexity in the rest of
> > the system is entire
On Thu, Jul 29, 2021 at 1:47 AM Amul Sul wrote:
> Can we have an elog() fatal error or warning to make sure that the
> last checkpoint is still readable? Since the case where the user
> (knowingly or unknowingly) or some buggy code has removed the WAL file
> containing the last checkpoint could be
On Wed, Jul 28, 2021 at 3:28 PM Andres Freund wrote:
> > Imagine if instead of
> > all the hairy logic we have now we just replaced this whole if
> > (IsInRecovery) stanza with this:
> >
> > if (InRecovery)
> > CreateEndOfRecoveryRecord();
> >
> > That would be WAY easier to reason about than
On Mon, Jul 26, 2021 at 9:43 PM Robert Haas wrote:
>
> StartupXLOG() has code beginning around line 7900 of xlog.c that
> decides, at the end of recovery, between four possible courses of
> action. It either writes an end-of-recovery record, or requests a
> checkpoint, or creates a checkpoint, or
On Thu, Jul 29, 2021 at 3:28 AM Andres Freund wrote:
>
> [1] I really wish somebody had the energy to just remove single user and
> bootstrap modes. The degree to which they increase complexity in the rest of
> the system is entirely unreasonable. There's not actually any reason
> bootstrapping ca
Hi,
On 2021-07-26 12:12:53 -0400, Robert Haas wrote:
> My first thought was that we should do the check unconditionally,
> rather than just when bgwriterLaunched && LocalPromoteIsTriggered, and
> ERROR if it fails. But then I wondered what the point of that would be
> exactly. If we have such a bu
At Tue, 27 Jul 2021 11:03:14 -0400, Robert Haas wrote
in
> On Tue, Jul 27, 2021 at 9:18 AM Kyotaro Horiguchi
> wrote:
> > FWIW, by the way, I complained that the variable name "promoted" is a
> > bit confusing. It's old name was fast_promoted, which means that fast
> > promotion is being *requ
On Tue, Jul 27, 2021 at 9:18 AM Kyotaro Horiguchi
wrote:
> FWIW, by the way, I complained that the variable name "promoted" is a
> bit confusing. It's old name was fast_promoted, which means that fast
> promotion is being *requsted* and ongoing. On the other hand the
> current name "promoted" st
At Mon, 26 Jul 2021 16:15:23 -0400, Stephen Frost wrote in
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote:
> > > Yeah, tend to agree with this too ... but something I find a bit curious
> > > is the comment:
> > >
> > > * In
On Mon, Jul 26, 2021 at 4:15 PM Stephen Frost wrote:
> All I was really trying to point out above was that the comment might be
> improved upon, just so someone understands that we aren't doing a
> checkpoint at this particular place, but one will be done later due to
> the promotion. Maybe I'm b
On Mon, Jul 26, 2021 at 03:53:20PM -0400, Robert Haas wrote:
> Yeah, and there again, it's a lot easier to test if we don't have as
> many cases. Now no single change is going to fix that, but the number
> of flag variables in xlog.c is simply bonkers. This particular stretch
> of code uses 3 of th
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote:
> > Yeah, tend to agree with this too ... but something I find a bit curious
> > is the comment:
> >
> > * Insert a special WAL record to mark the end of
> > * recovery, since we aren't
On Mon, Jul 26, 2021 at 1:32 PM Stephen Frost wrote:
> Yeah, tend to agree with this too ... but something I find a bit curious
> is the comment:
>
> * Insert a special WAL record to mark the end of
> * recovery, since we aren't doing a checkpoint.
>
> ... immediately after setting promoted = true
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> So at the moment I am leaning toward the view that we should just
> remove this check entirely, as in the attached, proposed patch.
Haven't dug in deeply but at least following your explanation and
reading over the patch and the code a bit
StartupXLOG() has code beginning around line 7900 of xlog.c that
decides, at the end of recovery, between four possible courses of
action. It either writes an end-of-recovery record, or requests a
checkpoint, or creates a checkpoint, or does nothing, depending on the
value of 3 flag variables, and
16 matches
Mail list logo
