Re: [HACKERS] tables > 1 gig - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] tables > 1 gig
Date
Msg-id 199906180401.AAA15528@candle.pha.pa.us
Whole thread Raw
In response to RE: [HACKERS] tables > 1 gig  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: [HACKERS] tables > 1 gig
List pgsql-hackers
> > What this does is to create a zero length file, and the rename unlinks
> > the tablename file, and puts the zero-length file in it's place.
> > rename() is atomic, so there is no time that the table file does not
> > exist.
> >
> 
> Let
>     i1 be the inode of zz
>     i2 be the inode of tablename
> before rename().
> 
> Does this mean
> 
>     New backends read/write i1 inode and
>     backends that have the table open read/write i2 inode ?
> 
> If so,it seems wrong.
> All backends should see same data.

Yes, I can see your point.  It would show them different views of the
table.

So, as you were saying, we have no way of invalidating file descriptors
of other backends for secondary segments.  Why does truncating the file
not work?  Any ideas?

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] tables > 1 gig
Next
From: Vadim Mikheev
Date:
Subject: Re: [HACKERS] Re: Apparent bug in _make_subplan