"ERROR: could not read block 6 ...: read only 0 of 8192 bytes" after autovacuum cancelled
in [PgSql]
|
Prev: [HACKERS] "ERROR: could not read block 6 ...: read only 0 of 8192 bytes"after autovacuum cancelled
Next: broadcom
From: Tom Lane on 4 Nov 2009 15:21 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > What I thought could have happened is that the table was truncated, and > then the sinval message telling that to other backends was not sent due > to the rollback. Hmm. > So far as I can see, what we need is to make sure the sinval message is > sent regardless of transaction commit/abort. How can that be done? I would argue that once we've truncated, it's too late to abort. The interrupt facility should be disabled from just before issuing the truncate till after commit. It would probably be relatively painless to do that with some manipulation of the interrupt holdoff stuff. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Nov 2009 10:13 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Tom Lane wrote: >> I would argue that once we've truncated, it's too late to abort. The >> interrupt facility should be disabled from just before issuing the >> truncate till after commit. It would probably be relatively painless to >> do that with some manipulation of the interrupt holdoff stuff. > That cures my (admittedly simplistic) testcase. The patch is a bit ugly > because the interrupts are held off in lazy_vacuum_rel and need to be > released by its caller. I don't see any other way around the problem > though. I wonder whether we shouldn't extend this into VACUUM FULL too, to prevent cancel once it's done that internal commit. It would fix the "PANIC: can't abort a committed transaction" problem V.F. has. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Nov 2009 12:36 Alvaro Herrera <alvherre(a)commandprompt.com> writes: > Tom Lane wrote: >> I wonder whether we shouldn't extend this into VACUUM FULL too, to >> prevent cancel once it's done that internal commit. It would fix >> the "PANIC: can't abort a committed transaction" problem V.F. has. > Hmm, it seems to work. The attached is for 8.1. Looks OK, but please update the comment right before the RecordTransactionCommit, along the lines of "We prevent cancel interrupts after this point to mitigate the problem that you can't abort the transaction now". regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 6 Nov 2009 19:54 Alvaro Herrera <alvherre(a)commandprompt.com> writes: >> Looks OK, but please update the comment right before the >> RecordTransactionCommit, along the lines of "We prevent cancel >> interrupts after this point to mitigate the problem that you >> can't abort the transaction now". > BTW I'm thinking in backpatching this all the way back to 7.4 -- are > we agreed on that? Yeah, I would think the problems can manifest all the way back. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 10 Nov 2009 14:04
2009/11/10 Alvaro Herrera <alvherre(a)commandprompt.com>: > Tom Lane wrote: >> Alvaro Herrera <alvherre(a)commandprompt.com> writes: >> >> Looks OK, but please update the comment right before the >> >> RecordTransactionCommit, along the lines of "We prevent cancel >> >> interrupts after this point to mitigate the problem that you >> >> can't abort the transaction now". >> >> > BTW I'm thinking in backpatching this all the way back to 7.4 -- are >> > we agreed on that? >> >> Yeah, I would think the problems can manifest all the way back. > > Done, thanks for the discussion. Hello do you have a idea abou lazy vacuum lockinkg problem? any plans? Regards Pavel Stehule > > -- > Alvaro Herrera                 http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |