A long time ago Vadim proposed that we should revise smgr.c's API so
that it does not depend on Relations (relcache entries); rather, only
a RelFileNode value should be needed to access a file in smgr and lower
levels. This would allow us to get rid of the concept of "blind
writes". As of CVS tip
On Thu, 5 Feb 2004, Tom Lane wrote:
> * Because we don't smgrclose after a write, it is possible to have
> "dangling" smgr entries that aren't useful any more, as well as open
> file descriptors underneath them. This isn't too big a deal on Unix
> but it will be fatal for the Windows port, since
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'k, only comment is on this one ... would it not be a bit more efficient
> to add a flag to the "SMgrRelation *" structure that acts as a timer?
Hm, we could try that, although I'm not sure it would help much. You'd
have to set the timeout to be lo
On Thu, Feb 05, 2004 at 02:05:46PM -0500, Tom Lane wrote:
> * smgrclose closes the md.c-level file and drops the hashtable entry.
> Hashtable entries remain valid unless explicitly closed (thus, multiple
> smgropens for the same file are legal).
So, will there be a refcount on each cache entry?
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Feb 05, 2004 at 02:05:46PM -0500, Tom Lane wrote:
>> * smgrclose closes the md.c-level file and drops the hashtable entry.
>> Hashtable entries remain valid unless explicitly closed (thus, multiple
>> smgropens for the same file are legal).
> So
On Thu, Feb 05, 2004 at 04:55:44PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Another way to do it would be keeping the list of files to delete along
> > with the deleting Xid, but that would also require keeping a list of
> > which xacts aborted and which ones didn't.
On Thu, 5 Feb 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > 'k, only comment is on this one ... would it not be a bit more efficient
> > to add a flag to the "SMgrRelation *" structure that acts as a timer?
>
> Hm, we could try that, although I'm not sure it would help
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Why? Setting it to the checkpoint interval itself should be sufficient,
> no? All you want to do is avoid closing any files that were used during
> that last checkpoint interval, since there is a good chance you'd have to
> once more reopen them in
On Thu, 5 Feb 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Why? Setting it to the checkpoint interval itself should be sufficient,
> > no? All you want to do is avoid closing any files that were used during
> > that last checkpoint interval, since there is a good ch
"Marc G. Fournier" <[EMAIL PROTECTED]> 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 part
On Thu, 5 Feb 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> 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 wo
* AFAICS the only downside of not having a Relation available in smgr.c
and md.c is that error messages could only refer to the RelFileNode
numbers and not to the relation name. I'm not sure this is bad, since
in my experience what you want to know about such errors is the actual
disk filename, wh
12 matches
Mail list logo
