Horton

Thread

  1. problem with NOTICE: _outNode: don't know how to print type

    Ari Jolma <ajolma@water.hut.fi> — 2000-05-25T12:44:08Z

    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

  2. Re: problem with NOTICE: _outNode: don't know how to print type

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-25T15:18:26Z

    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

  3. Re: problem with NOTICE: _outNode: don't know how to print type

    Martijn van Oosterhout <kleptog@cupid.suninternet.com> — 2000-05-25T15:19:52Z

    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/

  4. Re: problem with NOTICE: _outNode: don't know how to print type

    Ari Jolma <ajolma@water.hut.fi> — 2000-05-25T18:24:28Z

    
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

  5. Re: problem with NOTICE: _outNode: don't know how to print type

    Joseph S <jks@selectacast.net> — 2000-05-25T21:05:48Z

    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)

  6. Re: problem with NOTICE: _outNode: don't know how to print type

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-25T22:49:03Z

    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

  7. PG 7.0 vacuum problem

    Marcin Inkielman <marn@wsisiz.edu.pl> — 2000-05-25T23:11:03Z

    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

  8. Re: PG 7.0 vacuum problem

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-25T23:49:00Z

    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

  9. Re: PG 7.0 vacuum problem

    Marcin Inkielman <marn@wsisiz.edu.pl> — 2000-05-26T00:06:07Z

    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

  10. Re: problem with NOTICE: _outNode: don't know how to print type

    Martijn van Oosterhout <kleptog@cupid.suninternet.com> — 2000-05-26T12:55:42Z

    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/

  11. Re: PG 7.0 vacuum problem

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-08-30T21:41:04Z

    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