Thread: Pre-page images in WAL

I was wondering if we should disable the writing of pre-page images into
WAL if the user has turned off fsync?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I was wondering if we should disable the writing of pre-page images into
> > WAL if the user has turned off fsync?
> 
> I'm worried about what vulnerabilities that would create.
> 
> Historically we've always defined "fsync off" to mean "I trust my
> kernel, hardware, and power supply ... but not necessarily Postgres
> itself".  In a Postgres crash, even with fsync off, you are not supposed
> to lose any committed transactions, so long as the kernel and hardware
> stay up.
> 
> In the brave new world of WAL, Postgres does not flush dirty buffers to
> disk at transaction commit, relying on WAL to clean up if a database or
> system failure occurs.  If we don't log page images to WAL then I think
> there's a hole here wherein a Postgres crash can lose data even though
> no failure of the surrounding OS occurs.  Maybe it's safe, but I'm not
> convinced.

I understand.  The only reason I mentioned this is because I thought
pre-page WAL was only to cache partially written disk pages.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I was wondering if we should disable the writing of pre-page images into
> WAL if the user has turned off fsync?

I'm worried about what vulnerabilities that would create.

Historically we've always defined "fsync off" to mean "I trust my
kernel, hardware, and power supply ... but not necessarily Postgres
itself".  In a Postgres crash, even with fsync off, you are not supposed
to lose any committed transactions, so long as the kernel and hardware
stay up.

In the brave new world of WAL, Postgres does not flush dirty buffers to
disk at transaction commit, relying on WAL to clean up if a database or
system failure occurs.  If we don't log page images to WAL then I think
there's a hole here wherein a Postgres crash can lose data even though
no failure of the surrounding OS occurs.  Maybe it's safe, but I'm not
convinced.
        regards, tom lane

> In the brave new world of WAL, Postgres does not flush dirty buffers
to
> disk at transaction commit, relying on WAL to clean up if a database
or
> system failure occurs.  If we don't log page images to WAL then I
think
> there's a hole here wherein a Postgres crash can lose data even though
> no failure of the surrounding OS occurs.  Maybe it's safe, but I'm not
> convinced.

It should be (imho *is*) safe for heap pages, but not for index pages.
The reasoning for heap pages is, that the WAL code (pre page image)
already
coped with future heap page versions.

I would not expect it to work for index pages, since one "feature" of
the page images was to "undo" future index operations.

Andreas