Hi Daniel: On Mon, May 30, 2016 at 5:35 PM, Daniel Westermann <daniel.westermann@xxxxxxxxxxxxxxxx> wrote: > I get the file for that table: ... > Then I delete the file: Well, you corrupted the database and invoked undefined behaviour ( not exactly, but postgres is not designed for this ). > No issue in the log. This is probably coming from the cache, isn't it? Is > this intended and safe? It's probably not intended. It can come from the cache or it can arrive from the fact that you are running a unix flavour. In unix ( at the OS level, in the clasical filesystems ) you do not delete a file, you unlink it ( remove the pointer to it in the directory ), the file is removed by the OS when nobody can reach it, which means nobody has it open an no directory points to it ( so no one else can open it, is like reference counting ) ( In fact this behaviour is used on purpose for temporary files, you open it, unlink it and know when you exit, either normaly or crashing, the OS deletes it ). Postgres has the file open, and probably does not bother checking wether somebody removed it under from the directory, as there is no correct behaviour in this case, so no point in checking it. > Then I restart the instance and do the select again: > 2016-05-30 19:25:20.633 CEST - 9 - 2777 - - @ FATAL: could not open file > "base/16422/32809": No such file or directory As expected. > Can someone please tell me the intention behind that? From my point of view > this is dangerous. If nobody is monitoring the log (which sadly is the case > in reality) nobody will notice that only parts of the table are there. > Wouldn't it be much more safe to raise an error as soon as the table is > touched? If you are going to implement idealised behaviour, prohibiting people from deleting it would be better. Any user with minimu knwledge and enouugh privileges can put programs in states from which they cannot recover, there is not point in checking every corner case. In fact, if you can remove the file under the servers feet you can probably alter the running server memory, which would you think the correct behaviour would be for a 'poke rand(),rand()' in the server process? It could have triple redundancy copy of every page and try to vote and detect in each instruction, but is pointless. Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
