Re: Vacuuming leaked temp tables (once again)
От | Simon Riggs |
---|---|
Тема | Re: Vacuuming leaked temp tables (once again) |
Дата | |
Msg-id | 1215881227.4051.1788.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Vacuuming leaked temp tables (once again) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Vacuuming leaked temp tables (once again)
|
Список | pgsql-hackers |
On Sat, 2008-07-12 at 12:04 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Seems like it would be a fairly big patch. The temp-bootstrap process is > > still just hand-waving though. > > Yeah, and it seems fairly messy. The idea I'd had was that all the > catalog entries for (a single set of) inheritance child tables are Just > There in the output of initdb. Yeh, not having a temp-boostrap process at all is best. > The tricky part is that each session that > makes use of these tables needs to have its own copy of their contents. > I think that could be solved with > some magic that made their pg_class entries reflect a per-session > relfilenode value. This seems no worse than your proposed magic in > pg_inherit, and it eliminates the problem of needing to "bootstrap" > all the temp-file catalog infrastructure in every session. Agreed. Perhaps the magic would be to create sub-directories in the pg_temp namespace based upon backend pid. That way all relfilenode values would be the same, but would refer to different objects. Side thought... We can't generate Oids in Hot Standby mode, since they'll end up duplicating values from the primary. We probably need to reserve the top 16384 Oid values for use as temp object Oids. > (I note that this is real close to the SQL spec's notion of how a temp > table works --- maybe we could usefully combine this with a patch to > provide spec-compliant temp tables?) Yeh, I read that and thought something similar. But we're talking about temp additions to catalog tables, not all temp tables. If we tried to implement spec-compliant temp tables we would need to write to catalog tables again, which is what we are trying to avoid! -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: