| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Concurrent VACUUM: first results |
| Date: | 1999-11-26 06:42:07 |
| Message-ID: | 383E2BBF.4E11CA2D@krs.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> >> I wonder whether there isn't a cleaner way to do this.
>
> > I think there exists another reason.
> > We couldn't delete index tuples for deleted but not yet committed
> > heap tuples.
>
> My first thought was "Good point". But my second was "why should
> vacuum need to deal with that case?". If vacuum grabs an exclusive
> lock on a relation, it should *not* ever see tuples with uncertain
> commit status, no?
What if vacuum will crash after deleting index tuples pointing
to heap tuples in old places but before commit? Index will
be broken.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-11-26 06:52:32 | Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions |
| Previous Message | Vadim Mikheev | 1999-11-26 06:38:32 | Re: [HACKERS] Concurrent VACUUM: first results |