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: Notice in logg file |
Date: | 2000-05-09 05:07:35 |
Message-ID: | 000401bfb974$7d03a900$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:
> >>>> Apr 28 03:06:05 ziutek logger: NOTICE: Index
> >>>> tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (10652)
> >>>> IS NOT THE SAME AS HEAP' (10634)
> >>
> >> This can happen if there are other transactions open while the VACUUM
> >> runs.
>
> > Really ?
> > If I remember correctly,your sample cases have CREATE INDEX
> > and NUMBER OF INDEX TUPLES was not greater than HEAP.
>
> Hmm, good point --- maybe this is something different.
>
As to this INDEX TUPLES > HEAP phenomenon in VACUUM.
The delay of WriteBuffer(cur_buffer) in vc_repair_frag() of
VACUUM may be one of the cause. cur_buffer is a buffer page
where new MOVED_IN tuples are inserted. It is dirtied when
another cur_buffer page is needed or tuple moving was finished.
OTOH newly inserted index tuples are dirtied immediately.
If VACUUM crashes before the cur_buffer is dirtied,the buffer
may be discarded without writing to disk. This may result that
some index tuples would point to UNUSED blocks.
Though it isn't a problem at the moment,updation of tuples
of the page would replace UNUSED blocks.
I'm not sure my guess is right or not.
Comments ?
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-05-09 05:30:10 | Re: 7.0 key features |
Previous Message | Lamar Owen | 2000-05-09 00:23:08 | Re: USE_SYSLOG ... useless? :) |