Re: It's past time to redo the smgr API
От | Marc G. Fournier |
---|---|
Тема | Re: It's past time to redo the smgr API |
Дата | |
Msg-id | 20040205195054.R4449@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: It's past time to redo the smgr API (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 5 Feb 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > k, but that would be a different scenario, no? As I mentioned in my > > original, a DROP TABLE would reset its timeout to -1, meaning to close it > > and drop it on the next checkpoint interval ... > > How would it do that? These structs are local to particular backends, > so there's no way for a DROP TABLE occurring in one backend to reach > over and reset the timeout in the bgwriter process. If we add > communication that lets the bgwriter know the table is being dropped, > then the problem is solved directly. D'oh, okay, took me a second to clue into what it was I wasn't cluing into ... got it now, thanks ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
В списке pgsql-hackers по дате отправления: