Re: pg_basebackup caused FailedAssertion - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: pg_basebackup caused FailedAssertion
Date
Msg-id CAHGQGwEg9xFmhL6YRPesrUsjEBCz7wsZ8khhWOAWGYQ8HUGOiQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup caused FailedAssertion  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Thu, Feb 28, 2013 at 2:29 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 26.02.2013 19:42, Tom Lane wrote:
>>
>> Fujii Masao<masao.fujii@gmail.com>  writes:
>>>
>>> In HEAD, when I ran "pg_basebackup -D hoge -X stream",
>>> I got the following FailedAssertion error:
>>
>>
>>> TRAP: FailedAssertion("!((wakeEvents&  ((1<<  1) | (1<<  2))) != (1<<
>>>
>>> 2))", File: "pg_latch.c", Line: 234)
>>
>>
>>> This error happens after the commit
>>> 0b6329130e8e4576e97ff763f0e773347e1a88af.
>>
>>
>>> This assertion error happens when WL_SOCKET_WRITEABLE without
>>> WL_SOCKET_READABLE is specified in WaitLatchOrSocket(). This
>>> condition is met when walsender has received CopyDone from the client,
>>> but the output buffer is not empty. If reaching such condition is
>>> legitimate,
>>> I think that we should get rid of the Assertion check which caused the
>>> above
>>> FailedAssertion error. Thought?
>>
>>
>> The reason for the assertion is that that case doesn't actually work.
>> The code that is passing that combination of flags needs to be changed.
>> Or else you can try to implement the ability to support READABLE only.

Yeah, right.

> Right. I fixed that by adding WL_SOCKET_READABLE, and handling any messages
> that might arrive after the frontend already sent CopyEnd. The frontend
> shouldn't send any messages after CopyEnd, until it receives a CopyEnd from
> the backend.
>
> In theory, the frontend could already send the next query before receiving
> the CopyEnd, but libpq doesn't currently allow that. Until someone writes a
> client that actually tries to do that, I'm not going to try to support that
> in the backend. It would be a lot more work, and likely be broken anyway,
> without any way to test it.
>
> Thanks for the report!

Thanks!

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Next
From: Fujii Masao
Date:
Subject: Re: Support for REINDEX CONCURRENTLY