From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Andreas Zeugswetter <Andreas(dot)Zeugswetter(at)telecom(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Open 6.5 items |
Date: | 1999-06-07 14:15:51 |
Message-ID: | Pine.BSF.4.05.9906071114110.413-100000@thelab.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 7 Jun 1999, Bruce Momjian wrote:
> > > What is it on the backend that causes some backend to think there is
> > > another segment. Does it just go off the end of the max segment size
> > > and try to open another, or do we store the number of segments
> > > somewhere. I thought it was the former in sgml() area. I honestly don't
> > > care if the segment files stay around if that is going to be a reliable
> > > solution.
> >
> > Other then the inode being used, what is wrong with a zero-length segment
> > file?
>
> Nothing is wrong with it. I just thought it would be more reliable to
> unlink it, but now am considering I was wrong.
Just a thought, but if you left it zero length, the dba could use it as a
means for estimating disk space requirements? :) buff.0 buff.1 is zero
lenght, but buff.2 isn't, we know that we've filled 2x1gig buffers plus a
little bit, so can allocate space accordingly? :)
I'm groping here, help me out ... :)
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-06-07 14:26:30 | Re: [HACKERS] Bug in LIKE ? |
Previous Message | Vadim Mikheev | 1999-06-07 14:14:25 | deadlock in btree... |