Re: including backend ID in relpath of temp rels - updated patch
От | Robert Haas |
---|---|
Тема | Re: including backend ID in relpath of temp rels - updated patch |
Дата | |
Msg-id | AANLkTikz4OTuihYJxdMR3Ge0MrHg4FLdVZd0-7J0LJxi@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: including backend ID in relpath of temp rels - updated patch (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: including backend ID in relpath of temp rels - updated patch
|
Список | pgsql-hackers |
On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > 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? I think that would be subject to race conditions. The current mechanism is actually pretty good, and I think we can build on it if we want to do more, rather than inventing something new. We just need to be specific about what problem we're trying to solve. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: