RE: Notice in logg file

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

Browse pgsql-hackers by date

  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? :)