Re: including backend ID in relpath of temp rels - updated patch
От | Alvaro Herrera |
---|---|
Тема | Re: including backend ID in relpath of temp rels - updated patch |
Дата | |
Msg-id | 1281648499-sup-6812@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: including backend ID in relpath of temp rels - updated patch (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: including backend ID in relpath of temp rels - updated patch
|
Список | 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@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: