From: | Andreas Brandl <ml(at)3(dot)141592654(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Determine dead files |
Date: | 2012-03-05 10:58:20 |
Message-ID: | d59ce2a5-3d76-403f-bf2e-b5987842fb6a@store1.zcs.ext.wpsrv.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | r d | 2012-03-05 12:25:40 | Re: what Linux to run |
Previous Message | Tom Molesworth | 2012-03-05 09:30:06 | Re: atoi-like function: is there a better way to do this? |