Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741
От | Erik Rijkers |
---|---|
Тема | Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741 |
Дата | |
Msg-id | 5ad515455a937160b258f1b18fbc7642.squirrel@webmail.xs4all.nl обсуждение исходный текст |
Ответ на | Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File:
"bufmgr.c", Line: 1741
Re: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741 |
Список | pgsql-hackers |
On Thu, May 31, 2012 03:30, Robert Haas wrote: > On Wed, May 30, 2012 at 6:00 PM, Erik Rijkers <er@xs4all.nl> wrote: >> directory >> 2012-05-30 23:40:57.909 CEST 3909 CONTEXT: writing block 5152 of relation base/21268/26569 >> xlog redo multi-insert (init): rel 1663/21268/26581; blk 3852; 35 tuples >> TRAP: FailedAssertion("!(PrivateRefCount[i] == 0)", File: "bufmgr.c", Line: 1741) >> 2012-05-30 23:40:58.006 CEST 5331 FATAL: could not open file "base/21268/26569": No such file >> or >> directory >> 2012-05-30 23:40:58.006 CEST 5331 CONTEXT: writing block 5153 of relation base/21268/26569 >> 2012-05-30 23:40:59.661 CEST 3908 LOG: startup process (PID 3909) was terminated by signal 6: >> Aborted >> 2012-05-30 23:40:59.661 CEST 3908 LOG: terminating any other active server processes > > Hmm. I set up what I believe to be the same test case you were using, > and it's not crashing for me. In fact, with the latest code, I > haven't been able to produce any error at all. When I reverted my > last commit, I managed to get this: > > ERROR: could not open relation with OID 18229 > STATEMENT: select current_setting('port') port, count(*) from t > > ...but just once, and with no other error messages. So I'm either > missing a step somewhere, or something about your system just happens > to tickle this moreso than on mine. > In my test, I run the bash code (the bits that I posted earlier) in a while loop so that the table is CREATEd, COPYied into, and DROPped every few seconds -- perhaps that wasn't clear. That loop is necessary; a few iterations are often successful. I can test it today on a few other systems to see if it is reproducible. thanks, Erik Rijkers
В списке pgsql-hackers по дате отправления: