| 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: | 2009-03-31 15:31:18 |
| Message-ID: | 10580.1238513478@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2009-03-31 15:34:01 | Re: string_to_array with empty input |
| Previous Message | Heikki Linnakangas | 2009-03-31 14:57:35 | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2009-03-31 15:34:01 | Re: string_to_array with empty input |
| Previous Message | Jaime Casanova | 2009-03-31 15:21:01 | Re: Partitioning feature ... |