Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? |
Дата | |
Msg-id | 10580.1238513478@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Tom Lane wrote: >> This isn't entirely trivial because it's presently expensive to >> determine whether a table is someone else's temp table: it takes a >> system catalog lookup. I'm not even sure that it'd be safe to have >> the relcache do it and cache the result --- it could lead to infinite >> recursion. (At the very least this would promote pg_namespace into >> the set of critical relcache entries.) > You could hard code that PG_CATALOG_NAMESPACE is not a temp namespace. I > believe that would stop the recursion. True. > Would that avoid promoting > pg_namespace to critical status, too? Not sure. It'd still be something you have to access while loading most relcache entries. On balance the extra pg_class column seems like a more robust and useful solution. I've wished for a clean way to see temp-table-ness at the SQL level before. And we've already changed pg_class's rowtype for 8.4, so it shouldn't pose any additional hardship from an application compatibility standpoint. regards, tom lane
В списке pgsql-hackers по дате отправления: