Pre-page images in WAL

Started by Bruce Momjianabout 24 years ago4 messages
#1Bruce Momjian
pgman@candle.pha.pa.us

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, Pennsylvania 19026
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#1)
Re: Pre-page images in WAL

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

#3Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Tom Lane (#2)
Re: Pre-page images in WAL

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, Pennsylvania 19026
#4Zeugswetter Andreas SB SD
ZeugswetterA@spardat.at
In reply to: Bruce Momjian (#3)
Re: Pre-page images in WAL

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