Re: pg_basebackup caused FailedAssertion

On Thu, Feb 28, 2013 at 2:29 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 26.02.2013 19:42, Tom Lane wrote:
>>
>> Fujii Masao<masao(dot)fujii(at)gmail(dot)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