Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?


  • From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
  • Cc: Stuart Bishop <stuart(at)stuartbishop(dot)net>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?
  • Date: Tue, 31 Mar 2009 11:31:18 -0400
  • Message-id: <10580.1238513478@sss.pgh.pa.us> <text/plain>

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group