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 по дате отправления: