On Fri, Mar 31, 2017 at 4:46 PM, Tsunakawa, Takayuki
wrote:
> Thank you, but did you remove WL_LATCH_SET from WaitLatch() intentionally? I
> understood you added it for startup process to respond quickly to events
> other than the postmaster death. Why don't we
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> Oops, sorry for that, I quite mess up with this patch. The WaitLatch() call
> should still have WL_POSTMASTER_DEATH so as it can leave earlier, but yes
> I agree with your analysis that HandleStartupProcInterrupts() as this is
> part of
On Thu, Mar 30, 2017 at 4:02 PM, Tsunakawa, Takayuki
wrote:
> I think you can call HandleStartupProcInterrupts() here, instead of checking
> postmaster death.
Oops, sorry for that, I quite mess up with this patch. The WaitLatch()
call should still have
Hi Michael, Simon,
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> > Oh, I see. But how does the startup process respond quickly? It seems
> that you need to call HandleStartupProcInterrupts() instead of
>
On Thu, Mar 30, 2017 at 1:52 PM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> > (2) standby.c
>> > Do we need to specify WL_LATCH_SET? Who can set the latch? Do the
>> backends who ended the conflict set the latch?
>>
>> This makes the
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> > By the way, doesn't this wait event belong to IPC wait event type, because
> the process is waiting for other conflicting processes to terminate the
> conflict conditions? Did
On Wed, Mar 29, 2017 at 5:04 PM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
>> What do you think about the updated version attached?
> I reviewed this patch.
(4) standby.c
> The latch is not reset when the wait timed out. The next WaitLatch() would
> return immediately.
Sorry, let me withdraw this. This is my misunderstanding.
OTOH, when is the latch reset before the wait? Is there an assumption that
MyLatch has been in reset state since it was
Hi, Michael,
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> What do you think about the updated version attached?
I reviewed this patch. Here are some comments and questions:
(1) monitoring.sgml
The new row needs to be
On Sun, Mar 19, 2017 at 5:14 AM, Tom Lane wrote:
> Couple of thoughts on this patch ---
Thanks!
> 1. Shouldn't WaitExceedsMaxStandbyDelay's CHECK_FOR_INTERRUPTS be moved to
> after the WaitLatch call? Not much point in being woken immediately by
> an interrupt if you're not
Michael Paquier writes:
> Both things are fixed in the new version attached. I have added as
> well this patch to the next commit fest:
> https://commitfest.postgresql.org/13/977/
Couple of thoughts on this patch ---
1. Shouldn't WaitExceedsMaxStandbyDelay's
On Wed, Mar 8, 2017 at 5:45 AM, Peter Eisentraut
wrote:
> On 1/30/17 20:34, Michael Paquier wrote:
>> Both things are fixed in the new version attached. I have added as
>> well this patch to the next commit fest:
>> https://commitfest.postgresql.org/13/977/
>
>
On 1/30/17 20:34, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier
> wrote:
>> Two things I forgot in this patch:
>> - documentation for the new wait event
>> - the string for the wait event or this would show up as "???" in
>>
On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier
wrote:
> Two things I forgot in this patch:
> - documentation for the new wait event
> - the string for the wait event or this would show up as "???" in
> pg_stat_activity.
> There are no default clauses in the
On Sat, Jan 28, 2017 at 2:18 AM, Robert Haas wrote:
> On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier
> wrote:
>> There are no default clauses in the pgstat_get_wait_* routines so my
>> compiler is actually complaining...
>
> That's exactly WHY
On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier
wrote:
> There are no default clauses in the pgstat_get_wait_* routines so my
> compiler is actually complaining...
That's exactly WHY there are no default clauses there. :-)
--
Robert Haas
EnterpriseDB:
On Fri, Jan 27, 2017 at 10:35 AM, Michael Paquier
wrote:
> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>>> On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
On
On Fri, Jan 27, 2017 at 9:23 PM, Simon Riggs wrote:
> On 27 January 2017 at 01:35, Michael Paquier
> wrote:
>> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>>> On 26 January 2017 at 19:20, Andres Freund
On 27 January 2017 at 01:35, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>>> I'm personally fine with going with a CHECK_FOR_INTERRUPTS
On 26 January 2017 at 20:36, Alvaro Herrera wrote:
> Simon Riggs wrote:
>> On 26 January 2017 at 19:20, Andres Freund wrote:
>
>> > I'm personally fine with going with a CHECK_FOR_INTERRUPTS
>> > for now, but I think it'd better to replace it with a
On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote:
> On 26 January 2017 at 19:20, Andres Freund wrote:
>> On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
>>> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
>>> > Currently a
Simon Riggs wrote:
> On 26 January 2017 at 19:20, Andres Freund wrote:
> > I'm personally fine with going with a CHECK_FOR_INTERRUPTS
> > for now, but I think it'd better to replace it with a latch.
>
> I have waited, so not sure what you mean. Tomorrow is too late.
>
>
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-01-26 19:36:11 +, Simon Riggs wrote:
> > Tomorrow is too late.
>
> Huh? We're not wrapping today/tomorrow, are we? If I missed something
> and we are, then sure, it makes sense to push ahead.
I haven't seen anyone suggest that we're
On 2017-01-26 19:36:11 +, Simon Riggs wrote:
> On 26 January 2017 at 19:20, Andres Freund wrote:
> > On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
> >> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> >> > Currently a waiting standby doesn't
On 26 January 2017 at 19:20, Andres Freund wrote:
> On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
>> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
>> > Currently a waiting standby doesn't allow interrupts.
>> >
>> > Patch implements that.
>> >
On 2017-01-26 12:24:44 -0500, Robert Haas wrote:
> On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> > Currently a waiting standby doesn't allow interrupts.
> >
> > Patch implements that.
> >
> > Barring objection, patching today with backpatches.
>
> "today" is a
On Thu, Jan 26, 2017 at 7:18 AM, Simon Riggs wrote:
> Currently a waiting standby doesn't allow interrupts.
>
> Patch implements that.
>
> Barring objection, patching today with backpatches.
"today" is a little quick, but the patch looks fine. I doubt anyone's
going to
Currently a waiting standby doesn't allow interrupts.
Patch implements that.
Barring objection, patching today with backpatches.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
interrupt_waiting_standby.v1.patch
28 matches
Mail list logo