Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc -- FALSE ALARM - Mailing list pgsql-hackers

From Ryan Kirkpatrick
Subject Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc -- FALSE ALARM
Date
Msg-id Pine.LNX.4.21.0103251643080.12181-100000@excelsior.rkirkpat.net
Whole thread Raw
In response to Vaccuum Failure w/7.1beta4 on Linux/Sparc  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Responses Re: Re: Vaccuum Failure w/7.1beta4 on Linux/Sparc -- FALSE ALARM  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 12 Mar 2001, Ryan Kirkpatrick wrote:

>     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
I moved the data directory to a local parition (from the NFS
mounted one it was on) and reran my application. It worked fine this time,
vaccuming tables with out errors and the above error was never seen. Looks
like pgsql is not NFS safe, or at least with Linux's implementation. This is good news in that it is not a serious
issue,but bad news
 
in that now I really do have to hurry up and get more local space for this
box to do anything useful with it. :)Thanks for everyone's help. TTYL.

---------------------------------------------------------------------------
|   "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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: More bogus alignment assumptions
Next
From: Larry Rosenman
Date:
Subject: docs toolchain appears broke?