Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] select * from ..;vacuum crashes

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: t-ishii(at)sra(dot)co(dot)jp, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] select * from ..;vacuum crashes
Date: 1998-10-12 07:28:44
Message-ID: Pine.GSO.3.96.SK.981012102552.23556A-100000@ra (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce,

I was hoping this will fix 'vacuum analyze' problem on
my Linux box when I run postmaster with -B 1024 option, but it doesn't :-(
After clean reinstalling I still get error message:
psg post
 9080  p1 S    0:00 ssh dv -l postgres 
13916  ?  S    0:00 /usr/local/pgsql/bin/postmaster -i -B 1024 -S -D/usr/local/p
dv:~$ !psq

regression=> vacuum analyze;
NOTICE:  AbortTransaction and not in in-progress state 
NOTICE:  AbortTransaction and not in in-progress state 
regression=> \q


	Regards,

		Oleg


On Sun, 11 Oct 1998, Bruce Momjian wrote:

> Date: Sun, 11 Oct 1998 21:16:10 -0400 (EDT)
> From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> To: t-ishii(at)sra(dot)co(dot)jp
> Cc: t-ishii(at)sra(dot)co(dot)jp, pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] select * from ..;vacuum crashes
> 
> > >You must enable Assert to see the crash.
> > 
> > I saw the crash without assertion enabled? This is FreeBSD 2.2.6.
> > 
> > >The cause may be because you are doing a vacuum INSIDE a transaction.  I
> > >think that also explains the psql -e thing, because that does both
> > >commands in the same transaction.
> > >
> > >Perhaps we need to disable vacuum inside transactions.  Vadim?
> > 
> > FYI, it is reported that 6.3.2 does not have the crash.
> 
> OK, this is fixed now.  The problem is that my new cache-use code finds
> tuples by looking in the cache, getting the t_ctid value, and using
> heap_fetch to get the tuple, rather than the older sequential
> scan/ScanKey method.
> 
> However, when you vacuum a table, as the rows are moved, the t_ctid
> changes, but there was no call to invalidate the system cache for the
> row, so when you vacuum pg_class, and later use the cache to look up
> something, the cache points to an old tuple.
> 
> This is fixed now, along with a little cache code cleanup that removes
> some unused code that was confusing things.
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> 

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


In response to

pgsql-hackers by date

Next:From: Tom Ivar HelbekkmoDate: 1998-10-12 08:01:31
Subject: Re: [HACKERS] Error messages crash backend
Previous:From: Frank RidderbuschDate: 1998-10-12 06:53:49
Subject: Re: [HACKERS] Minor problem with Solaris 2.7beta

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group