On Thu, Apr 11, 2019 at 10:33:13AM +0200, Magnus Hagander wrote:
> And I think it would make sense to wait by default, but we could then also
> have a commandline parameter that says "don't wait, instead error out in
> case the checkpoint isn't done".
>
> Or something like that?
Yes, that would b
On Mon, Apr 8, 2019 at 8:17 AM Michael Paquier wrote:
> On Sun, Apr 07, 2019 at 03:06:56PM +0200, Magnus Hagander wrote:
> > So can we *detect* that this is the case? Because if so, we could perhaps
> > just wait for it to be done? Because there will always be one?
>
> Yes, this one is technicall
On Tue, Apr 09, 2019 at 10:38:19AM +0900, Michael Paquier wrote:
> Sure. With something like the attached? I don't think that there is
> much point to complicate the test code with multiple roles if the
> default is a superuser.
As this topic differs from the original thread, I haev started a ne
On Mon, Apr 08, 2019 at 10:03:48AM +0200, Peter Eisentraut wrote:
> How about some tests to show that this is actually true?
Sure. With something like the attached? I don't think that there is
much point to complicate the test code with multiple roles if the
default is a superuser.
--
Michael
di
On 2019-04-04 12:43, Michael Paquier wrote:
> I would like to apply this down to 9.5 for the checkpoint part and
> down to 11 for the role part, so if anybody has any comments, please
> feel free.
How about some tests to show that this is actually true?
--
Peter Eisentraut http://ww
At Mon, 8 Apr 2019 15:17:25 +0900, Michael Paquier wrote
in <20190408061725.gf2...@paquier.xyz>
> On Sun, Apr 07, 2019 at 03:06:56PM +0200, Magnus Hagander wrote:
> > So can we *detect* that this is the case? Because if so, we could perhaps
> > just wait for it to be done? Because there will alwa
On Sun, Apr 07, 2019 at 03:06:56PM +0200, Magnus Hagander wrote:
> So can we *detect* that this is the case? Because if so, we could perhaps
> just wait for it to be done? Because there will always be one?
Yes, this one is technically possible. We could add a timeout option
which checks each N se
On Fri, Apr 5, 2019 at 1:05 PM Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 10:39:26AM +0200, Michael Banck wrote:
> > Ok, so the problem is that that checkpoint might be still ongoing when
> > you quickly issue a pg_rewind from the other side?
>
> The end-of-recovery checkpoint may not have
On Fri, Apr 05, 2019 at 10:39:26AM +0200, Michael Banck wrote:
> Ok, so the problem is that that checkpoint might be still ongoing when
> you quickly issue a pg_rewind from the other side?
The end-of-recovery checkpoint may not have even begun.
> I think it might be useful to specify more exactly
On Fri, Apr 05, 2019 at 10:11:22AM +0200, Magnus Hagander wrote:
> If that is the case, would running a CHECKPOINT actually cause a problem?
If you exclude the point that it may not be necessary and the
potential extra I/O, no. However we would come back to the point of
pg_rewind requiring a supe
Hi,
On Fri, Apr 05, 2019 at 04:56:32PM +0900, Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> > Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> > after promote itself? After all, this seems to be about making the
> > control file havi
On Fri, Apr 5, 2019 at 10:06 AM Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:59:29AM +0200, Magnus Hagander wrote:
> > A related question is, could we (for 12+) actually make the problem go
> > away? As in, can we detect the state and just have pg_rewind issue the
> > checkpoint as needed?
On Fri, Apr 05, 2019 at 09:59:29AM +0200, Magnus Hagander wrote:
> A related question is, could we (for 12+) actually make the problem go
> away? As in, can we detect the state and just have pg_rewind issue the
> checkpoint as needed?
I am not sure as you can still bump into the legit case where o
On Fri, Apr 5, 2019 at 9:56 AM Michael Paquier wrote:
> On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> > Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> > after promote itself? After all, this seems to be about making the
> > control file having the proper
On Fri, Apr 05, 2019 at 09:41:58AM +0200, Michael Banck wrote:
> Is there a good reason why Postgres doesn't just issue a CHECKPOINT
> after promote itself? After all, this seems to be about making the
> control file having the proper content, which sounds like a good thing
> to have in general.
T
Hi,
On Thu, Apr 04, 2019 at 01:11:29PM +0900, Michael Paquier wrote:
> At the same time, let's also document that we need to use a checkpoint
> on the promoted standby so as the control file gets a refresh and
> pg_rewind is able to work properly. I promised that some time ago and
> got reminded
On Thu, Apr 04, 2019 at 01:19:44PM +0200, Magnus Hagander wrote:
> All of it, or just the checkpoint part? I assume just the checkpoint part?
> AFAIK it does require superuser in those earlier versions?
I meant of course the checkpoint part down to 9.5, and the rest down
to 11, so done this way.
-
On Thu, Apr 4, 2019 at 12:43 PM Michael Paquier wrote:
> On Thu, Apr 04, 2019 at 10:18:45AM +0200, Magnus Hagander wrote:
> > Looks good. Maybe we should list the "role having sufficient permissions"
> > before superuser, "just because", but not something I feel strongly
> about.
>
> Listing the
On Thu, Apr 04, 2019 at 10:18:45AM +0200, Magnus Hagander wrote:
> Looks good. Maybe we should list the "role having sufficient permissions"
> before superuser, "just because", but not something I feel strongly about.
Listing the superuser after sounds fine to me.
> The part about CHECKPOINT also
On Thu, Apr 4, 2019 at 6:11 AM Michael Paquier wrote:
> On Wed, Apr 03, 2019 at 11:28:50AM +0200, Magnus Hagander wrote:
> > As pointed out by Michael Banck as a comment on my blogpost, the
> pg_rewind
> > documentation says it requires superuser permissions on the remote
> server.
> >
> > Is tha
On Wed, Apr 03, 2019 at 11:28:50AM +0200, Magnus Hagander wrote:
> As pointed out by Michael Banck as a comment on my blogpost, the pg_rewind
> documentation says it requires superuser permissions on the remote server.
>
> Is that really so, though? I haven't tested it, but from a quick look at
>
21 matches
Mail list logo
