This whole discussion left out the critical point of *how on earth did that file end up having zero bytes?*
There is the possibility that this is due to a bug in PostgreSQL. But over the 20+ years I've been using and hacking it, that has never happened. OP never told us what type of OS, hardware and specifically storage subsystem that "slave" was running on. Filesystems zapping files to zero after a catastrophic IO failure (no longer throwing them into lost+found) isn't unheard of. Regards, Jan On Fri, Dec 29, 2017 at 8:13 PM, Stephen Frost <sfr...@snowman.net> wrote: > Greetings, > > * Edson Carlos Ericksson Richter (rich...@simkorp.com.br) wrote: > > There should be a "catalog" that point where tables are stored in > physical > > files (I think, at least, because at some point PostgreSQL need to know > from > > where to read the data). > > Yes, it's pg_class. Specifically, the relfilenode. > > > Based on information from this catalog, would I have a tool (perhaps, a C > > function) that check that data is really there? > > You could write such a function, but it wouldn't be able to be general > purpose as a zero-byte file is, in fact, a valid file. You could just > as easily do a 'select 1 from table limit 1;' and make sure that you get > back a successful, single-row, result, if you wish to verify that certain > tables in your database always have at least 1 row. > > Thanks! > > Stephen > -- Jan Wieck Senior Postgres Architect http://pgblog.wi3ck.info
