On 1/23/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Steven Flatt" <[EMAIL PROTECTED]> writes:
> > I noticed that the Postgres autovacuum process was vacuuming some tables
> > that had enabled = false in pg_autovacuum.
>
> I thin
The following bug has been logged online:
Bug reference: 3898
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Postgres autovacuum not respecting pg_autovacuum.enabled
= false
Details:
I
On Jan 21, 2008 3:33 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I think we need to make some fixes here, but the fixes would mainly
> consist of complaining about the first approach ;-). The second one
> is a much safer way to do it.
>
Second approach looks good. Thanks for all your help!
Steve
On Jan 21, 2008 1:24 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, there's our problem: for some reason PID 7908 has this buffer
> pinned, which is blocking the vacuum. That seems pretty darn odd for
> a process that is about to (try to) truncate the table. The only way
> I can imagine is that
On Jan 18, 2008 10:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hm, PIN_COUNT_WAITER flag is still set, and refcount = 2 saying there is
> still someone else pinning the buffer, so nothing evidently wrong here.
>
> Could you check PrivateRefCount[14407] in both cores?
>
Okay, got two new hung proc
On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Do you still have the hung processes available? It would be really
> useful to take a look at the buffer header that the autovac process's
> LockBufferForCleanup() is working on. (In gdb, "f 3" then "p *bufHdr")
Well I just lost the hung processe
On 1/17/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, that's not what the backtraces say. The autovac process is trying
> to get super-exclusive lock on a buffer (apparently in relation 16783
> --- what is that?). There's no evidence in the stack trace that the
> TRUNCATE process has any conflict
On 1/17/08, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > This isn't a postgres deadlock per se, but the end result is that two
> > postgres backends are stuck, each waiting on a PGSemaphoreLock that the
> > other presumably has. The processes have been stuck for hours.
>
> Can you reproduce this
The following bug has been logged online:
Bug reference: 3883
Logged by: Steven Flatt
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.1
Description:Autovacuum deadlock with truncate?
Details:
This isn't a postgres deadloc
Postgres 8.2.4.
Would this be considered a bug or is the tablespace info excluded for
a particular reason?
# CREATE TABLESPACE foo_space LOCATION '/some/dir';
# CREATE TABLE foo (a int);
# CREATE INDEX foo_idx ON foo(a) TABLESPACE foo_space;
# SELECT pg_get_indexdef(oid) FROM pg_class WHERE reln
10 matches
Mail list logo
