Make unlogged table resets detectable - Mailing list pgsql-hackers

From Jeff Davis
Subject Make unlogged table resets detectable
Date
Msg-id 62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel@j-davis.com
Whole thread Raw
Responses Re: Make unlogged table resets detectable  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
One problem with unlogged tables is that the application has no way to
tell if they were reset, or they just happen to be empty.

This can be a problem with sharding, where you might have different
shards of an unlogged table on different servers. If one server
crashes, you'll be missing only one shard of the data, which may appear
inconsistent. In that case, you'd like the application (or sharding
solution) to be able to detect that one shard was lost, and TRUNCATE
those that remain to get back to a reasonable state.

It would be easy enough for the init fork to have a single page with a
flag set. That way, when the main fork is replaced with the init fork,
other code could detect that a reset happened.

When detected, depending on a GUC, the behavior could be to auto-
truncate it (to get the current silent behavior), or refuse to perform
the operation (except an explicit TRUNCATE), or issue a
warning/log/notice.

The biggest challenge would be: when should we detect that the reset
has happened? There might be a lot of entry points. Another idea would
be to just have a SQL function that the application could call whenever
it needs to know.

Thoughts?

    Jeff Davis





pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Jeff Davis
Date:
Subject: Re: Support for NSS as a libpq TLS backend