Re: pgstattuple triggered checkpoint failure and database outage?
От | Stuart Bishop |
---|---|
Тема | Re: pgstattuple triggered checkpoint failure and database outage? |
Дата | |
Msg-id | fsy1drpem87smw0e9bUYAxe124vaj_firegpg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgstattuple triggered checkpoint failure and database outage? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgstattuple triggered checkpoint failure and database outage?
|
Список | pgsql-general |
On Tue, Mar 31, 2009 at 8:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Stuart Bishop <stuart@stuartbishop.net> writes: >> I just had a brief outage on a production server running 8.3.6, which >> I suspect was triggered by me running a table bloat report making lots >> of pgstattuple calls. > >> The first I got of it was the script I'd just kicked off died: > >> could not open segment 1 of relation 1663/16409/11088101 (target block >> 131292): No such file or directory >> CONTEXT: writing block 131292 of relation 1663/16409/11088101 >> ... >> Doing an immediate shutdown and restart seems to have brought >> everything back online. > > What's the actual size of that relation now? Is it growing rapidly? > (I'm trying to figure out whether those writes *should* have succeeded, > or whether the block numbers were corrupt in memory.) I can't seem to find a file on disk named 11088101 or an entry in pg_class where relfilenode = 11088101. Are the allocated table oids always increasing? If so, I can pretty much guarantee that the missing relation was a temporarytable or the index on the temporary table. It had a single integer column and maybe 50million rows. -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
Вложения
В списке pgsql-general по дате отправления: