On Sat, Apr 2, 2011 at 4:51 AM, Fujii Masao wrote:
> On Fri, Apr 1, 2011 at 11:11 PM, Robert Haas wrote:
>> On Thu, Mar 31, 2011 at 11:12 PM, Fujii Masao wrote:
>>> Another simple fix is to make walsender send SIGUSR1 to postmaster
>>> so that it calls PostmasterStateMachine() in sigusr1_handler
On Fri, Apr 1, 2011 at 11:11 PM, Robert Haas wrote:
> On Thu, Mar 31, 2011 at 11:12 PM, Fujii Masao wrote:
>> Another simple fix is to make walsender send SIGUSR1 to postmaster
>> so that it calls PostmasterStateMachine() in sigusr1_handler(), when it
>> marks itself as walsender. The attached pa
On Thu, Mar 31, 2011 at 11:12 PM, Fujii Masao wrote:
> Another simple fix is to make walsender send SIGUSR1 to postmaster
> so that it calls PostmasterStateMachine() in sigusr1_handler(), when it
> marks itself as walsender. The attached patch does this. Thought?
That looks OK to me. Have you te
On Fri, Apr 1, 2011 at 4:48 AM, Robert Haas wrote:
>> I think this problem is harmless in practice since it doesn't happen
>> too often. But
>> that can happen...
>>
>> The simple fix is to change ServerLoop() so that it periodically calls
>> PostmasterStateMachine() while shutdown is running.
>
>
[ sorry for not responding sooner ]
On Wed, Mar 23, 2011 at 9:46 AM, Fujii Masao wrote:
> When I read the shutdown code to create the smart shutdown patch for sync rep,
> I found the corner case where shutdown can get stuck infinitely. This happens
> when postmaster reaches PM_WAIT_BACKENDS state
Hi,
When I read the shutdown code to create the smart shutdown patch for sync rep,
I found the corner case where shutdown can get stuck infinitely. This happens
when postmaster reaches PM_WAIT_BACKENDS state before walsender marks
itself as WAL sender process for streaming WAL (i.e., before walsen
