| From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
|---|---|
| To: | Daniel Westermann <daniel(dot)westermann(at)dbi-services(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Subject: | Re: Deleting a table file does not raise an error when the table is touched afterwards, why? |
| Date: | 2016-05-31 13:41:47 |
| Message-ID: | CA+bJJbwxLd5HzF05Rte+_16ciyWQo_CE5vNn=c5MXGQjdr-Xvw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi:
On Tue, May 31, 2016 at 8:58 AM, Daniel Westermann
<daniel(dot)westermann(at)dbi-services(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thalis Kalfigkopoulos | 2016-05-31 13:49:26 | Drop/Re-Creating database extremely slow + doesn't lose data |
| Previous Message | Andrej Vanek | 2016-05-31 11:41:32 | Re: empty pg_stat_replication when replication works fine? |