| 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: | Whole Thread | Raw Message | 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... |