vacuum analyze problem

Hi,

cvs still has problem with vacuum analyze on my Linux machine:
after completion of regression test which passed fine I tried
vacuum analyze on regression db and got

NOTICE: AbortTransaction and not in in-progress state
NOTICE: AbortTransaction and not in in-progress state

in regress.log there were following messages:
......skipped....
ages 0/0. Elapsed 0/0 sec.
DEBUG: --Relation lseg_tbl--
DEBUG: Pages 1: Changed 0, Reapped 0, Empty 0, New 0; Tup 5: Vac 0, Crash 0, UnUsed 0, MinLen 72, MaxLen 72; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
ERROR: cannot write block 0 of pkeys [regression] blind
NOTICE: AbortTransaction and not in in-progress state
ERROR: cannot write block 0 of pkeys [regression] blind
NOTICE: AbortTransaction and not in in-progress state
ERROR: cannot write block 0 of pkeys [regression] blind
NOTICE: AbortTransaction and not in in-progress state

Earlier this happened only if I run postmaster with number of buffers > 128
and never happens when I run regression test following procedure
described in INSTALL.

Just tested on BSDI, and I can't reproduce the problem here.

-- 
  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

cvs still has problem with vacuum analyze on my Linux machine:
after completion of regression test which passed fine I tried
vacuum analyze on regression db and got
NOTICE: AbortTransaction and not in in-progress state
NOTICE: AbortTransaction and not in in-progress state

*snip*

Earlier this happened only if I run postmaster with number of buffers > 128 and never happens when I run regression test following procedure
described in INSTALL.

I'm not seeing this problem on my Linux machine (2.0.30 kernel) so it
probably isn't a general problem with Linux. I haven't done a completely
new refresh of my sources for at least a few days, though I don't think
this is the problem because you've been seeing something like this on
your machine for a while.

Your problem would be easier to diagnose if someone could reproduce it
on another machine, but if the test is as simple as trying a vacuum on
the regression database then it's easy to test and we aren't finding it
happening everywhere :(

Keep plugging away at it though because there's always a chance that
your particular machine is uncovering an obscure feature of the code...

- Tom

Just did full and clean cvs'ing, cleaning, recompiling on 2 Linux
machines.
The problem with vacuum analyze on regression db dissapears, but it's
still exists when I run postmaster with -B 1024 option.
usually I start postmaster as

/usr/local/pgsql/bin/postmaster -i -B 1024
-S -D/usr/local/pgsql/data/ -o '-Fe'

and 6.3.2 is rock solid, no problem at all with vacuuming.

Your problem would be easier to diagnose if someone could reproduce
it on another machine, but if the test is as simple as trying a
vacuum on the regression database then it's easy to test and we
aren't finding it happening everywhere :(

I could reproduce the problem myself :-) on 3 Linux machines, running
different kernels, different compilers etc. This is an excerption from
debug messages:
il. Pages 0/0. Elapsed 0/0 sec.
DEBUG: Index bt_txt_index: Pages 27; Tuples 10000. Elapsed 0/0 sec.
ERROR: cannot write block -1 of [] blind
AbortCurrentTransaction
NOTICE: AbortTransaction and not in in-progress state

Keep plugging away at it though because there's always a chance that
your particular machine is uncovering an obscure feature of the
code...

3 particular machines and all I managed to install software, so
problem could be in me :=)
What could you suggest I do to track the problem ?

Well there is something about your installations which is different. The
only one I know about is that at least one of your machines is running
the 2.1.xxx kernels, which I don't have any experience with. If we can
confirm that this is then only difference between your machines and
mine, then it is something which we should understand and report as a
new kernel problem. If that isn't the common element, then I'm at a loss
as to why your machines and mine differ in behavior.

I'll interpret the lack of "hey, I'm having trouble too!" messages from
other people running Linux/iX86 as meaning that others aren't seeing
trouble, but it could just be that others aren't trying it yet. Does
anyone else on Linux see this problem? Does anyone on Linux _not_ see
this problem?

- Tom