From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: It's past time to redo the smgr API |
Date: | 2004-02-05 23:54:17 |
Message-ID: | 20040205195054.R4449@ganymede.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 5 Feb 2004, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
From | Date | Subject | |
---|---|---|---|
Next Message | Slavisa Garic | 2004-02-06 00:46:57 | COPY with INDEXES question |
Previous Message | Tom Lane | 2004-02-05 23:33:56 | Re: It's past time to redo the smgr API |