On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
On 12.01.2011 06:21, Fujii Masao wrote:
On Sat, Dec 25, 2010 at 2:09 PM, Maxim Bogukwrote:
While I trying create reproducible test case for BUG #5798 I
encountered very strange effect on two of my servers (both servers
have same hardware platform/OS (freebsd 7.2) and PostgreSQL 8.4.4).

Very simple test table created as:
CREATE TABLE test (id integer);
INSERT INTO test select generate_series(0,10000);

And I trying repeateble vacuum of that table with script:
perl -e "foreach (1..100000) {system \"psql -d test -h -c 'vacuum
test'\";}"

And once per like an minute (really random intervals can be 5 minutes
without problems can be 3 vacuum in row show same error) I getting
next errors:
WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "test" page
1
...
WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation "test"
page 30 for all pages of the relation.
Oh, interesting. This is the first time anyone can reliably reproducible
that. I can't reproduce that on my laptop with that script, though, so
I'm going to need your help to debug this.

Can you compile PostgreSQL with the attached patch, and rerun the test?
It will dump the pages with incorrectly set flags to files in /tmp/, and
adds a bit more detail in the WARNING. Please run the test until you
get those warnings, and tar up the the created "/tmp/pageimage*" files,
and post them along with the warning generated.

We'll likely need to go back and forth a few times with various
debugging patches until we get to the heart of this..
Anything new on this? I'm seeing at on one of my clients production boxes.
Also, what is the significance, ie what is the risk or damage potential if
this flag is set incorrectly?

Thanks

-dg


--
David Gould daveg@sonic.net
If simplicity worked, the world would be overrun with insects.

Search Discussions

  • Heikki Linnakangas at Feb 28, 2011 at 10:01 pm

    On 28.02.2011 23:28, daveg wrote:
    On Wed, Jan 12, 2011 at 10:46:14AM +0200, Heikki Linnakangas wrote:
    We'll likely need to go back and forth a few times with various
    debugging patches until we get to the heart of this..
    Anything new on this? I'm seeing at on one of my clients production boxes.
    I haven't heard anything from the OP since.
    Also, what is the significance, ie what is the risk or damage potential if
    this flag is set incorrectly?
    Sequential scans will honor the flag, so you might see some dead rows
    incorrectly returned by a sequential scan. That's the only "damage", but
    an incorrectly set flag could be a sign of something more sinister, like
    corrupt tuple headers. The flag should never be set incorrectly, so if
    you see that message you have hit a bug in PostgreSQL, or you have bad
    hardware.

    This flag is quite new, so a bug in PostgreSQL is quite possible. If you
    still have a backup that contains those incorrectly set flags, I'd like
    to see what the page looks like.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 28, '11 at 10:01p
activeFeb 28, '11 at 10:10p
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Heikki Linnakangas: 1 post Daveg: 1 post

People

Translate

site design / logo © 2021 Grokbase