Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc

Поиск
Список
Период
Сортировка
От Ryan Kirkpatrick
Тема Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc
Дата
Msg-id Pine.LNX.4.21.0103122033180.12669-100000@excelsior.rkirkpat.net
обсуждение исходный текст
Ответ на Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, 12 Mar 2001, Tom Lane wrote:

> Ryan Kirkpatrick <pgsql@rkirkpat.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/   |
---------------------------------------------------------------------------



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: Internationalized dates (was Internationalized error messages)
Следующее
От: Tom Lane
Дата:
Сообщение: xlog loose ends, continued