Hi, we have a streaming replication running and kind of suspect that the slave contains dead files caused by an abort of a huge transaction. I'd like to ask how we can be sure that those files are dead.
The details are: * PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.6.real (Debian 4.6.2-9) 4.6.2, 64-bit * streaming replication with hot-standby * We moved a huge table from one tablespace to the other * Unfortunately the disk-space on the master host exceeded during the transaction, which caused a transaction abort and furthermore a server-crash because WAL files could not be written * We added more disk-space and restarted the master * After restarting the master, the slave continued to read the WAL until the transaction abort * Now we have files on the slave which we suspect to be dead: 332166.27 ... 332166.2 332166.1 * These files are located in the destination tablespace (where we tried to move the table to) I suspect those files to be dead since the following query returns 0 rows: # select * from pg_class where relfilenode=332166; Is this a sufficient condition to delete all files $relfilenode.* ? Is relfilenode unique per database or per cluster? Is there any explanation why this situation lead to dead files? Thank you! Regards, Andreas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
