NOTICE from the backend

Ulf Mehlig wrote:

Hello PostgreSQL specialists! Short Question: What does the message

"NOTICE: Rel li64_dkopf: TID 1/7: TID IN TUPLEHEADER 4/2 IS NOT THE
SAME. TUPGONE 0."

mean? Anything dangerous? (it appeared with lots of others of the same

^^^^^^^^^^^^^^^^^^
Yes.

type after a "vacuum analyze").

As result of attempt to update 7th tuple in 1st block 2nd tuple
in 4th block will be updated. Dump/reload this table...

Seems that when I added this check I should add code to
set TID in header to valid value... -:(

Unfortunately, I don't know from where this TID difference comes
and this is very important to find it. After what operations/
assertions/FATALs you got this vacuum NOTICE?

Vadim

Vadim Mikheev <vadim@krs.ru> wrote:

Unfortunately, I don't know from where this TID difference comes
and this is very important to find it. After what operations/
assertions/FATALs you got this vacuum NOTICE?

Hello Vadim,

since last vacuum without that error message I did several things, but
I think the "guilty" operations were performed immediately before that
"vacuum analyze". I just constructed some indexes on that table (and
other tables connected by triggers to it to fake referential
integrity, like in contrib/spi). Afterwards I tried to cluster the
indexes. The clustering didn't work (I posted a report on that to
pgsql-general yesterday, too. Message included below! Probably the
very last thing I did before the "vacuum" was dropping the tables
"temp_66c31" etc. from the error message cited in that posting).

Are you interested in details about table structure etc.? BTW, as I
recognize now, I can't even drop that table, and dumping makes
postgreSQL try to fill my harddisk with more data than ever was in
that table (it only had 186 records). Fortunately, I did a general
pg_dump yesterday before the problem occurred ... o.k., I destroyed
the db, reloaded everything, vacuum works now. Unfortunately, I didn't
activate any logging, so I can't tell you exactly, what happend. And I
maybe shouldn't have destroyed the broken db without makeing a backup
copy to analyze it :-( I am sorry for being so unprofessional in
providing help to find the error (but it was the first +-severe
postgreSQL failure I ever had, so I'm not used to that situation ;-)

Please, tell me if you need more information!
Thanks for your help,
Ulf

----------------------------------------------------------------------
message about "cluster" failure:
================================

Could there be a bug in the 'cluster' command in postgreSQL 6.4? If I
try to cluster a table with a name with more than 8 characters, psql
says:

xxx=> create table x123456789 (xxx text);
CREATE
xxx=> create index x123 on x123456789 (xxx);
CREATE
xxx=> cluster x123 on x123456789;
ERROR: Relation x1234567 Does Not Exist!

If I try this repeatedly, I get:

xxx=> cluster x123 on x123456789;
ERROR: temp_66c31 relation already exists

I'm running PostgreSQL 6.4(.0) on i386 Linux (2.2.6). Please excuse if
I overlooked something in the docs!

Bye, Ulf
----------------------------------------------------------------------

--
======================================================================
Ulf Mehlig <umehlig@zmt.uni-bremen.de>
Center for Tropical Marine Ecology/ZMT, Bremen, Germany
----------------------------------------------------------------------