From: | Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc |
Date: | 2001-03-13 03:39:54 |
Message-ID: | Pine.LNX.4.21.0103122033180.12669-100000@excelsior.rkirkpat.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 12 Mar 2001, Tom Lane wrote:
> Ryan Kirkpatrick <pgsql(at)rkirkpat(dot)net> writes:
> > While testing some existing database applications on 7.1beta4 on
> > my Sparc 20 running Debian GNU/Linux 2.2, I got the following error on
> > attempting to do a vacuum of a table:
>
> > NOTICE: FlushRelationBuffers(jobs, 1399): block 953 is referenced (private 0, global 1)
> > ERROR! Can't vacuum table Jobs! ERROR: VACUUM (repair_frag): FlushRelationBuffers returned -2
>
> This is undoubtedly a backend bug. Can you generate a reproducible test
> case?
I will work on it... The code that eventually caused it does a lot
of different things so it will take me a little while to pair it down to
a small, self-contained test case. I should have it by this weekend.
Also, two other details I forgot to put in my first email:
a) Running 'vaccumdb -t Jobs {dbname}' about 24 hours after the error (the
backend had been completely idle during this time), ran successfully
without error.
b) The disk space where the pgsql database is located is NFS mounted from
my Alpha (running Linux of course :). [0] Might this cause the error?
[0] Yes, I know running pgsql on an NFS mount is probably not the greatest
idea, but the system only has 1GB of local disk space (almost all used for
the system) and is running as development server only. No valuable data is
entrusted to it. Hopefully I will have more local disk space in the near
future.
> Pg did get an ERROR from the vacuum command (note second line). Yes,
> there is paranoia right up the line here, but I think that's a good
> thing. Somewhere someone is failing to release a buffer refcount,
> and we don't know what other consequences that bug might have. Better
> to err on the side of caution.
A resonable amount of paranoia is indeed always healthy. :) Just
wanted to know if this might have been a known and harmless warning. I
guess not. I will work on a test case and get back hopefully by the
weekend. Thanks for your help.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-13 03:50:20 | xlog loose ends, continued |
Previous Message | Thomas Lockhart | 2001-03-13 02:46:11 | Re: Internationalized dates (was Internationalized error messages) |