Re: Deleting a table file does not raise an error when the table is touched afterwards, why? - Mailing list pgsql-general

From Francisco Olarte
Subject Re: Deleting a table file does not raise an error when the table is touched afterwards, why?
Date
Msg-id CA+bJJbwxLd5HzF05Rte+_16ciyWQo_CE5vNn=c5MXGQjdr-Xvw@mail.gmail.com
Whole thread Raw
In response to Re: Deleting a table file does not raise an error when the table is touched afterwards, why?  (Daniel Westermann <daniel.westermann@dbi-services.com>)
List pgsql-general
Hi:

On Tue, May 31, 2016 at 8:58 AM, Daniel Westermann
<daniel.westermann@dbi-services.com> wrote:
> for completeness: same issue with data checksums enabled:
...
> => rm the table files
> => select count(*) still works

And ? I would vote for not doing anything on this, after all you are
working outside the 'envelope' on this. Is like saying 'I commit with
fsync enabled, but then I zero the disk and the data is lost'. As I
said is like undefined behaviour in C. Currently *0 tends to SIGSEGV
on both reads and writes, but I've worked in OSs where it did only on
writes, and where it worked fine ( like CP/M ). For you the correct
behaviour maybe to fail fast and loose a little speed, for others the
current one may be OK. Normally for this things you go for the path
with less code, as deleted code is bug free.

Francisco Olarte.


pgsql-general by date:

Previous
From: Andrej Vanek
Date:
Subject: Re: empty pg_stat_replication when replication works fine?
Next
From: Thalis Kalfigkopoulos
Date:
Subject: Drop/Re-Creating database extremely slow + doesn't lose data