From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: including backend ID in relpath of temp rels - updated patch |
Date: | 2010-08-12 21:29:25 |
Message-ID: | 1281648499-sup-6812@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Robert Haas's message of jue ago 12 13:29:57 -0400 2010:
> We have two existing mechanisms for removing the catalog entries: when
> a backend is first asked to access a temporary file, it does a DROP
> SCHEMA ... CASCADE on any pre-existing temp schema. And a table is in
> wraparound trouble and the owning backend is no longer running,
> autovacuum will drop it. Improving on this seems difficult: if you
> wanted to *guarantee* that the catalog entries were removed before we
> started letting in connections, you'd need to fork a backend per
> database and have each one iterate through all the temp schemas and
> drop them. Considering that the existing code seems to have been
> pretty careful about how this stuff gets handled, I don't think it's
> worth making the whole startup sequence slower for it. What might be
> worth considering is changing the autovacuum policy to eliminate the
> wraparound check, and just have it drop temp table catalog entries for
> any backend not currently running, period.
What about having autovacuum silenty drop the catalog entry if it's a
temp entry for which the underlying file does not exist?
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-12 21:40:20 | Re: [HACKERS] postgres 9.0 crash when bringing up hot standby |
Previous Message | Tom Lane | 2010-08-12 21:19:00 | Re: Patch to show individual statement latencies in pgbench output |