Re: Deleting a table file does not raise an error when the table is touched afterwards, why?

From: David W Noon <david(dot)w(dot)noon(at)googlemail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Deleting a table file does not raise an error when the table is touched afterwards, why?
Date: 2016-05-30 17:02:47
Message-ID: 574C7237.8070106@googlemail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 May 2016 17:35:34 +0200 (CEST), Daniel Westermann
(daniel(dot)westermann(at)dbi-services(dot)com) wrote about "[GENERAL] Deleting a
table file does not raise an error when the table is touched
afterwards, why?" (in
<184509399(dot)5590018(dot)1464622534207(dot)JavaMail(dot)zimbra(at)dbi-services(dot)com>):

[snip]
> Then I delete the file:
>
> postgres(at)pg_essentials_p1:/u02/pgdata/PG1/base/16422/ [PG1] rm
> 32809

Actually, you are not deleting the file. You are asking the filesystem
driver to delete it when it has stopped being used. The directory
entry is removed immediately though, so that no other process can open i
t.

> When doing the count(*) on the table again:
>
> (postgres(at)[local]:5432) [sample] > select count(*) from t5; count
> --------- 1000000 (1 row)
>
> No issue in the log. This is probably coming from the cache, isn't
> it?

No, the file still exists because a PG back-end still has it open.

> Is this intended and safe?

It is standard UNIX behaviour. It is not safe because you are not
supposed to do things that way.
- --
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david(dot)w(dot)noon(at)googlemail(dot)com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAldMcjcACgkQogYgcI4W/5T/xgCfaQBh6g0WCBRkeNOlRK4Kbc43
Gs4An0UXb+piw+BQUGJupPtN+oHJZjVH
=td+i
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2016-05-30 17:12:17 Re: Silent data loss in its pure form
Previous Message Alex Ignatov 2016-05-30 16:57:49 Silent data loss in its pure form