Thread: problem with NOTICE: _outNode: don't know how to print type
Hello, I know (reading an older post) that this kind of message from postgres should indicate a problem with system tables: NOTICE: _outNode: don't know how to print type 1862286908 but I do not know how to proceed debugging/correcting this. I get this message from commands \l and vacuum. The SQL call which seems to cause the problem can be demonstrated like this: template1=> create table a (a int); CREATE template1=> select a from a union select a from a where a in (select a from a); NOTICE: _outNode: don't know how to print type 1044119613 NOTICE: _outNode: don't know how to print type 1044119613 a - (0 rows) template1=> The 'union' is essential for this problem to show. I have installed postgresql 7.0 on three different machines and only one of them does not give me this notice: all Linuxes one 5.1 (not ok), one 6.2 manually updated from 5.1 (not ok) and one 6.2 new installation (ok). So it seems that the problem may not be system tables. The type number is exactly the same in those two machines in similar test. Besides, the psql prompt is different in these installations but does not correlate with this problem. I ran regression tests on one of these installations giving this problem but everything was ok by it. I know that probably I could get rid of this problem by re-installing redhat 6.2 on the two other machines but that would be an overkill. Ari Jolma
Ari Jolma <ajolma@water.hut.fi> writes:
> template1=> create table a (a int);
> CREATE
> template1=> select a from a union select a from a where a in (select a from
> a);
> NOTICE: _outNode: don't know how to print type 1044119613
> NOTICE: _outNode: don't know how to print type 1044119613
Interesting. I take it you have a fairly high -d level enabled (high
enough to make parse/plan trees be dumped to the postmaster log). These
notices are pretty harmless, since they just indicate that the dumper
routine found something it couldn't deal with, but perhaps there is a
more serious problem lurking underneath. Will look.
regards, tom lane
Ari Jolma wrote: > template1=> select a from a union select a from a where a in (select a from > a); > NOTICE: _outNode: don't know how to print type 1044119613 > NOTICE: _outNode: don't know how to print type 1044119613 > a > - > (0 rows) Hmm, I may be missing something, but "select a from a" is not a legal statement. As the message suggests, a is not a printable type. Maybe you meant a.* ? -- Martijn van Oosterhout <kleptog@cupid.suninternet.com> http://cupid.suninternet.com/~kleptog/
On Fri, 26 May 2000, Martijn van Oosterhout wrote: > Ari Jolma wrote: > > template1=> select a from a union select a from a where a in (select a from > > a); > > NOTICE: _outNode: don't know how to print type 1044119613 > > NOTICE: _outNode: don't know how to print type 1044119613 > > a > > - > > (0 rows) > > Hmm, I may be missing something, but "select a from a" is not > a legal statement. As the message suggests, a is not a > printable type. Maybe you meant a.* ? The SQL statement above is just for showing what kind of statement causes the problem. I originally noticed the problem when I gave \l and then did a little research and found out that actually \l is implemented as something resembling what I wrote above. I was just trying to write the simplest SQL statement I could to generate the problem. It seems that there needs to be a union and a subselect. And the really curious thing is that this problem seems to depend on which redhat version there is! Ari Jolma
Martijn van Oosterhout wrote: > > Ari Jolma wrote: > > template1=> select a from a union select a from a where a in (select a from > > a); > > NOTICE: _outNode: don't know how to print type 1044119613 > > NOTICE: _outNode: don't know how to print type 1044119613 > > a > > - > > (0 rows) > > Hmm, I may be missing something, but "select a from a" is not > a legal statement. Why not? playpen=> create table a ( a int ) ; CREATE playpen=> insert into a values(1); INSERT 28310 1 playpen=> insert into a values(2); INSERT 28311 1 playpen=> select a from a union select a from a where a in (select a from a); a - 1 2 (2 rows)
Ari Jolma <ajolma@water.hut.fi> writes:
> It seems that there needs to be a union and a subselect.
Yes.
> And the really curious thing is that this problem seems
> to depend on which redhat version there is!
It was trying to interpret a pointer-to-character-string as
a pointer to a Node, so the results would be quite machine-
dependent. This didn't have any effect on execution of the
query, only on display of the parsetree in the postmaster log;
but in the worst-case scenario you could see a coredump from
the printout routine following a nonaligned pointer or some such.
Fixed for 7.0.1.
regards, tom lane
HI!
i rescently upgraded my system from PG6.53 to PG7.0. after a few days of
work i am unable to do a vacuum on one of tables:
nat=# VACUUM verbose analyze osoby;
NOTICE: --Relation osoby--
NOTICE: Pages 189: Changed 0, reaped 24, Empty 0, New 0; Tup 3436: Vac
29, Keep/VTL 0/0, Crash 0, UnUsed 180, MinLen 68, MaxLen
608; Re-using: Free/Avail. Space 67568/4196; EndEmpty/Avail. Pages
7/14. CPU 0.01s/0.95u sec.
NOTICE: Index osoby_Imię_key: Pages 33; Tuples 3436: Deleted 0. CPU
0.00s/0.01u sec.
NOTICE: Index osoby_pkey: Pages 12; Tuples 3436: Deleted 0. CPU
0.00s/0.01u sec.
NOTICE: Rel osoby: Pages: 189 --> 182; Tuple(s) moved: 0. CPU 0.00s/0.00u
sec.
NOTICE: FlushRelationBuffers(osoby, 182): block 186 is referenced
(private 0, global 3)
FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
everything other (including pg_dump) work fine
any ideas anybody?
do i risk anything if i do:
pg_dump nat> tmp
dropdb nat
createdb nat
psql nat <tmp
???
thanks in advance!
Marcin Inkielman
Marcin Inkielman <marn@wsisiz.edu.pl> writes:
> i rescently upgraded my system from PG6.53 to PG7.0. after a few days of
> work i am unable to do a vacuum on one of tables:
> nat=# VACUUM verbose analyze osoby;
> NOTICE: FlushRelationBuffers(osoby, 182): block 186 is referenced
> (private 0, global 3)
> FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
Hmm. Have you had any backend crashes? What seems to be happening here
is that there are some leftover reference counts on one of the shared
disk buffers for that relation. That should never be true while VACUUM
is running, because no other backend is supposed to be referencing that
table.
> do i risk anything if i do:
> pg_dump nat> tmp
> dropdb nat
> createdb nat
> psql nat <tmp
Probably won't work either. Instead, try stopping and restarting the
postmaster --- if my theory is right, that should get rid of the
leftover reference counts. But the real question is how did it get
into this state in the first place...
regards, tom lane
On Thu, 25 May 2000, Tom Lane wrote: > Date: Thu, 25 May 2000 19:49:00 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Marcin Inkielman <marn@wsisiz.edu.pl> > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] PG 7.0 vacuum problem > > Marcin Inkielman <marn@wsisiz.edu.pl> writes: > > i rescently upgraded my system from PG6.53 to PG7.0. after a few days of > > work i am unable to do a vacuum on one of tables: > > > nat=# VACUUM verbose analyze osoby; > > NOTICE: FlushRelationBuffers(osoby, 182): block 186 is referenced > > (private 0, global 3) > > FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2 > > Hmm. Have you had any backend crashes? What seems to be happening here > is that there are some leftover reference counts on one of the shared > disk buffers for that relation. That should never be true while VACUUM > is running, because no other backend is supposed to be referencing that > table. > > > do i risk anything if i do: > > > pg_dump nat> tmp > > dropdb nat > > createdb nat > > psql nat <tmp > > Probably won't work either. Instead, try stopping and restarting the > postmaster --- if my theory is right, that should get rid of the > leftover reference counts. But the real question is how did it get > into this state in the first place... thanks, it worked! before this, i tried to recreate my database using another name (and without destroying the old one) - it worked too! -- mi
Joseph Shraibman wrote: > > Martijn van Oosterhout wrote: > > > > Ari Jolma wrote: > > > template1=> select a from a union select a from a where a in (select a from > > > a); > > > NOTICE: _outNode: don't know how to print type 1044119613 > > > NOTICE: _outNode: don't know how to print type 1044119613 > > > a > > > - > > > (0 rows) > > > > Hmm, I may be missing something, but "select a from a" is not > > a legal statement. > > Why not? > playpen=> create table a ( a int ) ; > CREATE > playpen=> insert into a values(1); > INSERT 28310 1 > playpen=> insert into a values(2); > INSERT 28311 1 > playpen=> select a from a union select a from a where a in (select a > from a); > a > - > 1 > 2 > (2 rows) Yikes! I didn't see that you had a field and a table with the same name. Seems to me to be a bad combination. I answered because the only time I've seen those obscure error messages was when I accedently put a table name in the select part of a SELECT query..... -- Martijn van Oosterhout <kleptog@cupid.suninternet.com> http://cupid.suninternet.com/~kleptog/
Marcin Inkielman <marn@wsisiz.edu.pl> writes:
> NOTICE: FlushRelationBuffers(osoby, 182): block 186 is referenced
> (private 0, global 3)
> FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
(and similar reports from other people)
I think the source of this problem has finally been identified.
See the patch I just posted on pgsql-patches.
regards, tom lane