Re: removal of dangling temp tables
От | Alvaro Herrera |
---|---|
Тема | Re: removal of dangling temp tables |
Дата | |
Msg-id | 20181215020632.5vlffyvfpn4k42cn@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: removal of dangling temp tables (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: removal of dangling temp tables
|
Список | pgsql-hackers |
On 2018-Dec-14, Robert Haas wrote: > On Fri, Dec 14, 2018 at 6:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Hm. It *could*, if we wanted it to run some transactions after > > finishing recovery. > > It'd have to launch a separate process per database. That would be > useful infrastructure for other things, too, like automatic catalog > upgrades in minor releases, but I'm not volunteering to write that > infrastructure right now. This looks like a major project. > > Alternatively, maybe we could have backends flag whether they've > > taken ownership of their temp schemas or not, and let autovacuum > > flush old temp tables if not? > > Yes, that seems like a possibly promising approach. I did propose in my OP the idea of a PGPROC boolean flag that indicates whether the temp namespace has been set up. If not, have autovac remove those tables. I like this option better, but I fear it adds more ProcArrayLock contention. Maybe I can just use a new LWLock to coordinate that particular member of the ProcGlobal array ... (but then it can no longer be a boolean.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: