From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Open 6.5 items |
Date: | 1999-05-31 05:59:33 |
Message-ID: | 001601beab2a$c12d4c20$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> > > I thought we decided that file descriptors are kept by
> backends, and are
> > > still accessable while new backends don't see the files. Correct?
> > >
> >
> > Yes,other backends could write to unliked files which would be
> > vanished before long.
> > I think it's more secure to truncate useless segments to size 0
> > than unlinking the segments though vacuum would never remove
> > useless segments.
>
> If you truncate, other backends will see the data gone, and will be
> writing into the middle of an empty file. Better to remove.
>
I couldn't explain more because of my poor English,sorry.
But my test case usually causes backend abort.
My test case is
While 1 or more sessions frequently insert/update a table,
vacuum the table.
After vacuum, those sessions abort with message
ERROR: cannot open segment .. of relation ...
This ERROR finally causes spinlock freeze as I reported in a posting
[HACKERS] spinlock freeze ?(Re: INSERT/UPDATE waiting (another
example)).
Comments ?
Thanks.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-31 06:14:42 | Re: [HACKERS] Open 6.5 items |
Previous Message | Bruce Momjian | 1999-05-31 03:40:10 | Re: [HACKERS] Open 6.5 items |