Re: It's past time to redo the smgr API

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

In response to

Browse pgsql-hackers by date

  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