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

Re: BUG #1208: Invalid page header

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bruc(at)acm(dot)org
Cc: peter_e(at)gmx(dot)net, pgman(at)candle(dot)pha(dot)pa(dot)us,bruc(at)stone(dot)congenomics(dot)com, pgsql-bugs(at)postgresql(dot)org,hubert(dot)froehlich(at)bvv(dot)bayern(dot)de
Subject: Re: BUG #1208: Invalid page header
Date: 2004-08-17 00:01:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Robert E. Bruccoleri" <bruc(at)stone(dot)congenomics(dot)com> writes:
> 	Question: were there any significant changes made to the
> buffer management code between 7.4 and 8.0 that would explain the
> difference?

There are some nontrivial changes, but none that I would regard as
likely to cause a multiprocessing error to magically go away.  More
to the point, if there is such a bug in 7.4.3 there's no guarantee
it won't come back again.

> 	I haven't tried rerunning 7.4.3 without optimization to see if
> the problem disappears in that release. Since the 8.0beta1 release
> appears OK, and the test run takes about three days, so I'm reluctant
> to do it unless there's some value in performing test. Please tell me
> if there is.

If you believe this is not a hardware problem, you'd better keep
digging.  There is no known reason for 7.4 to fail like that.
It would be folly to assume that we've fixed the problem without
knowing it.

> 	Another question: on a machine which has this high level of
> parallelism, does it make sense to use a spinlock to control access to
> the buffer cache instead of a lightweight lock?

No.  The angst you've probably been reading is focused around the
spinlock part of the LWLock --- simplifying the LWLock to a bare
spinlock will not improve matters.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Theodore PetroskyDate: 2004-08-17 02:10:40
Subject: osx and thread safety?
Previous:From: Bruce MomjianDate: 2004-08-16 23:42:45
Subject: Re: [BUGS] 8.0.0beta1: -lpthread missing

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