On Wed, Nov 28, 2018 at 10:06:34AM +0900, Ian Barwick wrote:
> Thanks, looks good (and apologies for the delay in responding from my
> side).
Thanks for double-checking, Ian. I took my time as well ;)
(Hope to see you face-to-face in a couple of days around Akihabara.)
--
Michael
signature.asc
On 11/19/2018 01:22 PM, Michael Paquier wrote:
On Fri, Oct 26, 2018 at 01:51:24PM +0900, Michael Paquier wrote:
Or we could use "the function returns true immediately after initiating
the promotion by sending the promotion signal to the postmaster"? As a
native speaker which one feels more natu
On Fri, Oct 26, 2018 at 01:51:24PM +0900, Michael Paquier wrote:
> Or we could use "the function returns true immediately after initiating
> the promotion by sending the promotion signal to the postmaster"? As a
> native speaker which one feels more natural to you?
Sorry for the time it took. Af
On Fri, Oct 26, 2018 at 11:36:00AM +0900, Ian Barwick wrote:
> Documentation for this [*] says "Returns true if promotion is
> successful and false otherwise", which is not correct if "wait" is
> false, as it will always return TRUE.
Yes, in the case where the promotion has been initiated.
> +
Hi
On 10/25/2018 09:47 AM, Michael Paquier wrote:
And committed. I double-checked the code, and tweaked a bit the tests
so as the test using wait_mode = false is removed as it did not seem
worth the extra cycles. I also added a check on the return value of
pg_promote when using the wait mode.
Hi
On 10/25/2018 09:47 AM, Michael Paquier wrote:
And committed. I double-checked the code, and tweaked a bit the tests
so as the test using wait_mode = false is removed as it did not seem
worth the extra cycles. I also added a check on the return value of
pg_promote when using the wait mode.
On Wed, Oct 24, 2018 at 08:50:43AM +0900, Michael Paquier wrote:
> On Tue, Oct 23, 2018 at 09:42:16AM +0200, Laurenz Albe wrote:
> > No objections from me; on the contrary, I would like to thank you for
> > your effort here. I appreciate that you probably spent more time
> > tutoring me than it wo
On Tue, Oct 23, 2018 at 09:42:16AM +0200, Laurenz Albe wrote:
> No objections from me; on the contrary, I would like to thank you for
> your effort here. I appreciate that you probably spent more time
> tutoring me than it would have taken you to write this yourself.
You're welcome. Happy that i
Michael Paquier wrote:
> If there are no
> objections, I'll look at this patch again by the end of this week in
> order to get it committed.
No objections from me; on the contrary, I would like to thank you for
your effort here. I appreciate that you probably spent more time
tutoring me than it w
On Mon, Oct 22, 2018 at 11:45:30AM +0200, Laurenz Albe wrote:
> Masahiko Sawada wrote:
>> Thank you for workig on this. There is one review comment for the latest
>> patch.
>>
>> + if (FreeFile(promote_file))
>> + ereport(ERROR,
>> + (errcode_for_fi
Masahiko Sawada wrote:
> On Mon, Oct 22, 2018 at 3:01 PM Michael Paquier wrote:
> > Regarding the documentation, wouldn't it be more adapted to list the new
> > function under the section "Recovery Control Functions"? Not only does
> > the new function signal the postmaster, but it also creates t
On Mon, Oct 22, 2018 at 3:01 PM Michael Paquier wrote:
>
> On Sat, Oct 20, 2018 at 01:48:56PM +0900, Michael Paquier wrote:
> > On Sat, Oct 20, 2018 at 06:24:28AM +0200, Laurenz Albe wrote:
> >> Here is another version, with a fix in pg_proc.dat, an improved comment
> >> and "wait_seconds" exercis
On Sat, Oct 20, 2018 at 01:48:56PM +0900, Michael Paquier wrote:
> On Sat, Oct 20, 2018 at 06:24:28AM +0200, Laurenz Albe wrote:
>> Here is another version, with a fix in pg_proc.dat, an improved comment
>> and "wait_seconds" exercised in the regression test.
>
> Thanks for the new version. This
On Sat, Oct 20, 2018 at 06:24:28AM +0200, Laurenz Albe wrote:
> Here is another version, with a fix in pg_proc.dat, an improved comment
> and "wait_seconds" exercised in the regression test.
Thanks for the new version. This looks pretty good to me. I'll see if
I can review it once and then commi
I wrote:
> Fixed.
Here is another version, with a fix in pg_proc.dat, an improved comment
and "wait_seconds" exercised in the regression test.
Yours,
Laurenz Albe
From a2a7f9fd1b23ad102d11992b22158dab8b5451d5 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Oct 2018 06:21:00 +0200
Subje
Michael Paquier wrote:
> + /* wait for up to a minute for promotion */
> + for (i = 0; i < WAITS_PER_SECOND * WAIT_SECONDS; ++i)
> + {
> + if (!RecoveryInProgress())
> + PG_RETURN_BOOL(true);
> +
> + pg_usleep(100L / WAITS_PER_
On Mon, Oct 15, 2018 at 04:16:02PM +0200, Laurenz Albe wrote:
> Michael Paquier wrote:
>> Let's remove this restriction at code level, and instead use
>> function-level ACLs so as it is possible to allow non-superusers to
>> trigger a promotion as well, say a dedicated role. We could add a
>> syst
On Tue, Oct 16, 2018 at 09:49:20AM +0200, Laurenz Albe wrote:
> Only for hot standby - how do you want to execute a function on a standby
> server that doesn't allow connections?
In most deployments hot standby will be enabled, and wal_level uses the
same value for archive and hot_standby for some
Ashwin Agrawal wrote:
> Just curious to know, is promotion via function only allowed for
> hot-standby or works for any standby?
Only for hot standby - how do you want to execute a function on a standby
server that doesn't allow connections?
Yours,
Laurenz Albe
Just curious to know, is promotion via function only allowed for
hot-standby or works for any standby?
On Mon, Oct 15, 2018 at 7:16 AM Laurenz Albe
wrote:
> Michael Paquier wrote:
> > > diff --git a/src/backend/access/transam/xlog.c
> b/src/backend/access/transam/xlog.c
> > > index 7375a78ffc..3
Michael Paquier wrote:
> > diff --git a/src/backend/access/transam/xlog.c
> > b/src/backend/access/transam/xlog.c
> > index 7375a78ffc..3a1f49e83a 100644
> > --- a/src/backend/access/transam/xlog.c
> > +++ b/src/backend/access/transam/xlog.c
> > @@ -81,8 +81,6 @@ extern uint32 bootstrap_data_check
On Mon, Oct 08, 2018 at 07:36:50PM +0200, Laurenz Albe wrote:
> The attached patch has regression tests - I though it would be good
> to change some of the existing tests that run standby promotion to
> use the SQL function instead of pg_ctl.
>
> I have left the name though -- as far as I can tell
Masahiko Sawada wrote:
> Maybe the patch needs regression tests for the new function. And I'd
> suggest to make the function name more clear by changing to
> pg_promote_server(), pg_promote_standby() and so on.
Thanks for the review.
The attached patch has regression tests - I though it would be
On Thu, Oct 4, 2018 at 8:26 PM Laurenz Albe wrote:
>
> Michael Paquier wrote:
> > > In that vein, I propose a function pg_promote() to promote
> > > physical standby servers.
+1
> >
> > No fundamental issues from me regarding the concept of being able to
> > trigger a promotion remotely, so +1.
Michael Paquier wrote:
> > In that vein, I propose a function pg_promote() to promote
> > physical standby servers.
>
> No fundamental issues from me regarding the concept of being able to
> trigger a promotion remotely, so +1. Do we want this capability as well
> for fallback_promote? My gut te
On Thu, Sep 20, 2018 at 07:59:02AM +0200, Laurenz Albe wrote:
> Providing SQL access for administrative tasks seems to be a
> good thing, see ALTER SYSTEM and pg_reload_conf().
>
> In that vein, I propose a function pg_promote() to promote
> physical standby servers.
No fundamental issues from me
Providing SQL access for administrative tasks seems to be a
good thing, see ALTER SYSTEM and pg_reload_conf().
In that vein, I propose a function pg_promote() to promote
physical standby servers.
If there are no fundamental objections, I'll add it to the
next commitfest.
Yours,
Laurenz Albe
From
27 matches
Mail list logo
