RE: [HACKERS] vacuum of permanently updating database - Mailing list pgsql-hackers

From Oleg Bartunov
Subject RE: [HACKERS] vacuum of permanently updating database
Date
Msg-id Pine.GSO.3.96.SK.991016182220.11898s-100000@ra
Whole thread Raw
In response to RE: [HACKERS] vacuum of permanently updating database  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses RE: [HACKERS] vacuum of permanently updating database  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi,

thank you for the message. I'll try current tree but if
it's a bug (probable ?) why don't try to fix it for 6.5.3 ?
Regards,
   Oleg


On Sat, 16 Oct 1999, Hiroshi Inoue wrote:

> Date: Sat, 16 Oct 1999 10:06:36 +0900
> From: Hiroshi Inoue <Inoue@tpf.co.jp>
> To: Oleg Bartunov <oleg@sai.msu.su>
> Cc: hackers@postgreSQL.org
> Subject: RE: [HACKERS] vacuum of permanently updating database 
> 
> Hi
> 
> Could you try the current tree ?
> 
> As far as I see,there are 2 possibilities.
> 
> 1. Relation cache invalidation mechanism is much improved
>     by Tom in the current tree.
>     In your case,index tuples may be inserted into invalid index
>     relation and vanish.
> 
> 2. If vacuum aborts after the internal commit,the transaction
>     status is changed to be ABORT. This causes inconsistency.
>     I have changed not to do so in the current tree.
> 
> 
> In CURRENT tree,you may have to change vacuum_hits.sql
> as follows.
> 
>     drop index hits_pkey;
>     vacuum analyze hits(msg_id);
>     create unique index hits_pkey on hits(msg_id);
> 
> Probably DROP INDEX couldn't be executed inside transactions.
> 
> Regards.
> 
> Hiroshi Inoue
> Inoue@tpf.co.jp
> 
> >
> > I've already posted my question about NOTICE message I'm getting
> > from vacuum but didn't get any response :-(
> >
> > Today I decided to do some experiments to reproduce my problem.
> >
> > I run two independent processes:
> >
> > 1. send parallel requests to apache server in loop. On this request server
> >    does following:
> >
> >    LOCK TABLE hits IN SHARE ROW EXCLUSIVE MODE
> >    UPDATE hits SET count=count+1,last_access=now() WHERE msg_id=1468
> >
> > 2. vacuum table hits in shell scripts
> >
> > #!/bin/sh
> > while true ;do
> > /usr/local/pgsql/bin/psql -tq discovery <vacuum_hits.sql
> >  rc=$?
> >  i=$((i+1))
> >  echo Vaccuming: $i, RC=$rc
> >  sleep 10;
> > done
> >
> > where vacuum_hits.sql:
> >
> > begin work;
> > drop index hits_pkey;
> > create unique index hits_pkey on hits(msg_id);
> > end work;
> > vacuum analyze hits(msg_id);
> >
> >
> > Sometimes I get the message:
> >
> > NOTICE:  Index hits_pkey: NUMBER OF INDEX' TUPLES (173) IS NOT
> > THE SAME AS HEAP' (174)
> >
> > also several times I get:
> > ERROR:  Can't create lock file.  Is another vacuum cleaner running?
> >         If not, you may remove the pg_vlock file in the
> > /usr/local/pgsql/data//base/discovery
> >         directory
> >
> > I had to remove this file by hand.
> >
> >
> > I understand that experiment is a little bit artificial but I'd like
> > to know what I'm doing wrong and what's the safest way to vacuum
> > table which is permanently updating. Actually, I got about
> > 12 requests/sec on my home P166, 64Mb, Linux 2.2.12 - each request is a
> > plenty of database work.  I have to vacuum table because at this rate
> > I got very quick performance degradation.
> >
> > This is 6.5.2, Linux
> >
> >     Regards,
> >
> >         Oleg
> >
> > _____________________________________________________________
> > Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> > Sternberg Astronomical Institute, Moscow University (Russia)
> > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> > phone: +007(095)939-16-83, +007(095)939-23-83
> >
> >
> > ************
> >
> 
> 
> ************
> 

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83



pgsql-hackers by date:

Previous
From: Zakkr
Date:
Subject: to_char(), md5() (long)
Next
From: "Oliver Elphick"
Date:
Subject: Re: [HACKERS] to_char(), md5() (long)