Re: [HACKERS] select * from ..;vacuum crashes - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: [HACKERS] select * from ..;vacuum crashes
Date
Msg-id Pine.GSO.3.96.SK.981012102552.23556A-100000@ra
Whole thread Raw
In response to Re: [HACKERS] select * from ..;vacuum crashes  (Bruce Momjian <maillist@candle.pha.pa.us>)
List 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@candle.pha.pa.us>
> To: t-ishii@sra.co.jp
> Cc: t-ishii@sra.co.jp, pgsql-hackers@postgreSQL.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@candle.pha.pa.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@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: Frank Ridderbusch
Date:
Subject: Re: [HACKERS] Minor problem with Solaris 2.7beta
Next
From: "Gene Selkov Jr."
Date:
Subject: Re: yet another problem in recent builds, GIST this time