Skip site navigation (1) Skip section navigation (2)

Re: vacuumdb problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marcin Inkielman <marn(at)wsisiz(dot)edu(dot)pl>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuumdb problem
Date: 2000-07-02 16:47:55
Message-ID: 5322.962556475@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Marcin Inkielman <marn(at)wsisiz(dot)edu(dot)pl> writes:
> NOTICE:  FlushRelationBuffers(osoby, 228): block 223 is referenced
> (private 0, global 1)
> FATAL 1:  VACUUM (vc_repair_frag): FlushRelationBuffers returned -2

> this table is referenced in my db by a tree of FOREIGN KEYs. 

Hmm, I wonder whether there is a buffer-refcount leak in the foreign
key stuff.

> however my db seems to work and I am able to do pg_dump
> Rescently, I dumped and restored it and for a few days I was able to
> do vacuumdb. Today, the problem is here again.

You will probably find that stopping and restarting the postmaster
will make the problem go away (until it comes back again).  Might
be an acceptable workaround to let you vacuum, until we can find
the bug.

Do you think you can extract a reproducible example?  Short of that,
it'd be helpful to at least see the declarations of "osoby" and all
associated tables.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Marcin InkielmanDate: 2000-07-02 20:23:02
Subject: Re: [GENERAL] vacuumdb problem
Previous:From: Peter EisentrautDate: 2000-07-02 15:22:53
Subject: Re: 7.0.2 on Solaris

pgsql-general by date

Next:From: Leon ChiverDate: 2000-07-02 17:44:58
Subject: subqueries and stored procedures....
Previous:From: Jan WieckDate: 2000-07-02 16:34:00
Subject: Re: pg_dumpall and check constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group