Re: It's past time to redo the smgr API - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: It's past time to redo the smgr API
Date
Msg-id 20040205195054.R4449@ganymede.hub.org
Whole thread Raw
In response to Re: It's past time to redo the smgr API  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: It's past time to redo the smgr API
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: It's past time to redo the smgr API