Re: pg_basebackup caused FailedAssertion
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_basebackup caused FailedAssertion |
Дата | |
Msg-id | 512E427B.9090308@vmware.com обсуждение исходный текст |
Ответ на | Re: pg_basebackup caused FailedAssertion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_basebackup caused FailedAssertion
Re: pg_basebackup caused FailedAssertion |
Список | pgsql-hackers |
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. 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! - Heikki
В списке pgsql-hackers по дате отправления: