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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: It's past time to redo the smgr API
Date: 2004-02-05 23:33:56
Message-ID: 17804.1076024036@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-02-05 23:54:17 Re: It's past time to redo the smgr API
Previous Message Hans-Jürgen Schönig 2004-02-05 23:28:19 Re: Recursive queries?