Re: Extra files in "base" dir not seen in relfilenodes
От | Tom Lane |
---|---|
Тема | Re: Extra files in "base" dir not seen in relfilenodes |
Дата | |
Msg-id | 1664.1516144703@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Extra files in "base" dir not seen in relfilenodes (Daniel Farina <daniel@fdr.io>) |
Ответы |
Re: Extra files in "base" dir not seen in relfilenodes
|
Список | pgsql-general |
Daniel Farina <daniel@fdr.io> writes: > On Tue, Jan 16, 2018 at 3:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Umm ... are you accounting for catalogs that have zeroes in >> pg_class.relfilenode? It's generally better to rely on the >> pg_relation_filenode(oid) function than the raw column contents. > Yeah, the catalogs are not considered here (oids < 10000). The oids in > question are rather high. Let me re-run the antijoin with the function > though.... > Indeed, same result. Hmm, you should have gotten a result that was different by the size of the bootstrap catalogs (pg_class, pg_attribute, pg_proc, pg_type, plus their indexes). I'm worried that you're going to accidentally delete those critical catalogs. However, assuming you've gotten that detail right, then any file you can't match up with a relfilenode value must be an orphan you can just "rm". Do you have any theories about how the DB got like this? Were there system crashes or anything like that recently? Is there any pattern to the file access or mod dates on the putatively-orphaned files? regards, tom lane
В списке pgsql-general по дате отправления: