Re: [HACKERS] curious regression failures

2007-09-24 Thread Gregory Stark
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Idle thought here: did anything get done with the idea of decoupling main-table vacuum decisions from toast-table vacuum decisions? vacuum.c comments * Get a session-level lock too. This will protect our access to the *

Re: [HACKERS] curious regression failures

2007-09-23 Thread Alvaro Herrera
Tom Lane wrote: Idle thought here: did anything get done with the idea of decoupling main-table vacuum decisions from toast-table vacuum decisions? vacuum.c comments * Get a session-level lock too. This will protect our access to the * relation across multiple transactions, so

Re: [HACKERS] curious regression failures

2007-09-20 Thread Alvaro Herrera
Tom Lane wrote: There might be another way to manage this, but we're not inventing a new invalidation mechanism for 8.3. This patch will have to be reverted for the time being :-( Thanks. Seems it was a good judgement call to apply it only to HEAD, after all. In any case, at that point we

Re: [HACKERS] curious regression failures

2007-09-20 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: In any case, at that point we are mostly done with the expensive steps of vacuuming, so the transaction finishes not long after this. I don't think this issue is worth inventing a new invalidation mechanism. Yeah, I agree --- there are only a few

[HACKERS] curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)

2007-09-19 Thread Tom Lane
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: ! ERROR: could not read block 2 of relation 1663/16384/2606: read only 0 of 8192 bytes Is that repeatable? What sort of filesystem are you testing on? (soft-mounted NFS by any

Re: [HACKERS] curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)

2007-09-19 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: pgbfprod=# select sysname, stage, snapshot from build_status where log ~ $$read only \d+ of \d+ bytes$$; sysname |stage | snapshot ---+--+- zebra | InstallCheck | 2007-09-11

Re: [HACKERS] curious regression failures

2007-09-19 Thread Gregory Stark
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Andrew Dunstan wrote: pgbfprod=# select sysname, stage, snapshot from build_status where log ~ $$read only \d+ of \d+ bytes$$; sysname |stage | snapshot ---+--+- zebra |

Re: [HACKERS] curious regression failures

2007-09-19 Thread Andrew Dunstan
Gregory Stark wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Andrew Dunstan wrote: pgbfprod=# select sysname, stage, snapshot from build_status where log ~ $$read only \d+ of \d+ bytes$$; sysname |stage | snapshot

Re: [HACKERS] curious regression failures

2007-09-19 Thread Gregory Stark
Looking back, by far the largest change in the period Sep 1 - Sep 11 was the lazy xid calculation and read-only transactions. That seems like the most likely culprit. But given Tom's comments this commit stands out too: ---BeginMessage--- Log Message: --- Release the exclusive lock on

Re: [HACKERS] curious regression failures

2007-09-19 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: But given Tom's comments this commit stands out too: From: Alvaro Herrera [EMAIL PROTECTED] Log Message: --- Release the exclusive lock on the table early after truncating it in lazy vacuum, instead of waiting till commit. I had thought about