Thread: Large object corruption

Folks,

A client of mine has claimed to encounter the following:
When they have an unexpected power-out, large objects written to the databa=
se=20
but not checkpointed (i.e. in the middle of a transaction, and later than t=
he=20
checkpoint interval) will be corrupted, and not even the previous version o=
f=20
the LO is retrieveable.=20=20

Is this a know issue?  I couldn't find it in the list archives.

--=20
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Josh Berkus <josh@agliodbs.com> writes:
> A client of mine has claimed to encounter the following:
> When they have an unexpected power-out, large objects written to the database
> but not checkpointed (i.e. in the middle of a transaction, and later than the
> checkpoint interval) will be corrupted, and not even the previous version of
> the LO is retrieveable.

Not a known issue, and not a very credible report either.  LOs use the
same transaction mechanisms as everything else.

Is this the same client that apparently lost an index to a filesystem
failure earlier today?  I wonder just how extensive that failure was...
you might try looking for zeroed pages in pg_largeobject and its
index...

            regards, tom lane

Tom,

> Not a known issue, and not a very credible report either.  LOs use the
> same transaction mechanisms as everything else.
>
> Is this the same client that apparently lost an index to a filesystem
> failure earlier today?  I wonder just how extensive that failure was...
> you might try looking for zeroed pages in pg_largeobject and its
> index...

Not the same machine, but the same client.  I think a lot of their problems=
=20
devolve from running PostgreSQL on machines that consistently run out of RA=
M,=20
CPU and disk space, sometimes all at once.  Also they're in the habit of=20
turning the machines off while running.=20

It's actually sort of an interesting "destruction-test" environment for=20
PostgreSQL, and I really wish they'd give me publishable results, because=
=20
their testing, if anything, demonstrates how *indestructable* postgresql is=
.=20=20

I just wanted to make sure this was not a known, patchable issue.  Thanks!

--=20
Josh Berkus
Aglio Database Solutions
San Francisco