On 17.11.2010 03:56, Robert Haas wrote:
On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Robert Haas<robertmh...@gmail.com> writes:
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank<marcin.m...@gmail.com> wrote:
Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
I don't think so. To make that work, you'd need to keep track of
every backing file that might contain pages not fsync()'d to disk, and
at shutdown time you'd need to fsync() them all before shutting down.
This is presuming that we want to guarantee the same level of safety for
unlogged tables as for regular. Which, it seems to me, is exactly what
people *aren't* asking for. Why not just write the data and shut down?
If you're unlucky enough to have a system crash immediately after that,
well, you might have corrupt data in the unlogged tables ... but that
doesn't seem real probable.
I have a hard time getting excited about a system that is designed to
ensure that we probably don't have data corruption. The whole point
of this feature is to relax the usual data integrity guarantees in a
controlled way. A small but uncertain risk of corruption is not an
improvement over a simple, predictable behavior.
I agree with Robert, the point of unlogged tables is that the system
knows to zap them away if there's any risk of having corruption in them.
A corrupt page can lead to all kinds of errors. We try to handle
corruption gracefully, but I wouldn't be surprised if you managed to
even get a segfault caused by a torn page if you're unlucky.
fsync()ing the file at shutdown doesn't seem too bad to me from
performance point of view, we tolerate that for all other tables. And
you can always truncate the table yourself before shutdown.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
