From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Make unlogged table resets detectable |
Date: | 2021-06-03 20:04:43 |
Message-ID: | 62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2021-06-03 20:14:15 | Re: Support for NSS as a libpq TLS backend |
Previous Message | Andrew Dunstan | 2021-06-03 19:53:59 | Re: Support for NSS as a libpq TLS backend |