From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [HACKERS] Potential vacuum bug? |
Date: | 2000-01-12 00:04:31 |
Message-ID: | 000001bf5c90$99983b80$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > I'm for your change.
> > However I could hardly find the case that would cause a trouble.
> > It may occur in the following rare cases though I'm not sure.
>
> > HEAP_MOVED_OFF and (neither HEAP_XMIN_COMMITTED nor
> > HEAP_XMIN_INVALID) and the tuple was recently delete/updated.
>
> I'm not sure if HEAP_MOVED_OFF is really dangerous, but I am sure
> that HEAP_MOVED_IN is dangerous --- vc_rpfheap will error out if
> it hits a tuple marked that way. So, if a VACUUM fails partway
> through vc_rpfheap (I guess this would have to happen after the
> internal commit), it'd be possible that later VACUUMs wouldn't
> work anymore.
>
IIRC,there's no HEAP_MOVED_INd and not HEAP_XMIN_COMMITTED
tuples when vc_rpfheap() is called because such tuples has already
been marked unsued in vc_scanheap().
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-12 00:09:00 | Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend |
Previous Message | Bruce Momjian | 2000-01-12 00:01:17 | Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend |