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

Re: postmaster segfault when using SELECT on a table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karsten Desler <kd(at)link11(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: postmaster segfault when using SELECT on a table
Date: 2008-04-26 19:29:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Karsten Desler <kd(at)link11(dot)de> writes:
> I don't know much about the postgres architecture and I don't know if bounds
> checking on-disk values on a read makes a lot of sense since usually one
> should be able to assume that there are no randomly flipped bits; but it
> would've been nice to have a sensible log entry as to what really
> happened.

FWIW, there is code in CVS HEAD that detects simple cases of corrupt
compressed data, though it's anyone's guess if it would've caught your
example here.

> Anyway, for future reference: Assuming that this is the only corruption,
> can I just UPDATE (or DELETE and reINSERT) the offending entry (maybe with a
> following REINDEX/VACUUM?) or do I need to restore a backup?

If only the one row is clobbered, you should be able to just delete and
re-insert it, assuming you can identify it in a way that doesn't crash
in itself (ctid is probably about the safest).  Not sure if an UPDATE
would be safe.

My suspicion though is that you'll find that a large portion of that
page is damaged; that's usually what we've seen in such cases in the

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: valgogDate: 2008-04-28 06:07:39
Subject: Re: BUG #4123: Statement.setQueryTimeout does not work with Postgres Java Driver
Previous:From: Karsten DeslerDate: 2008-04-26 18:20:03
Subject: Re: postmaster segfault when using SELECT on a table

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