Обсуждение: serial type

Ummmm

Okee, this may be my setup being weird. I have been working on that
vacuum analyze bug and that may have killed something in the pg tables.

However, I am slightly concerned about this.

I am using 6.5.2 beta (the tarball on the ftp site)

-----------------------------

$ createdb games
% psql games
Welcome to the POSTGRESQL interactive sql monitor: Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.1 on i586-pc-linux-gnu, compiled by gcc -ggdb ]
  type \? for help on slash commands  type \q to quit  type \g or terminate with semicolon to execute queryYou are
currentlyconnected to the database: games
 

games=>  create table game (
games-> refnum serial
games-> );
NOTICE:  CREATE TABLE will create implicit sequence 'game_refnum_seq' for SERIAL column 'game.refnum'
NOTICE:  CREATE TABLE/UNIQUE will create implicit index 'game_refnum_key' for table 'game'
pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
  before or while processing the request.
 
We have lost the connection to the backend, so further processing is impossible.  Terminating.

--------------------------------------------

Having top running when I do this, the backend eats all of my
available memory in about 5 seconds, before crashing or just aborting
when it has no memory left to alloacte.

Now, I have realised a mistake I made. I set my postmaster to run at:

/usr/bin/postmaster -d 30 -S -N 128 -B 256 -D/var/lib/pgsql/data > /tmp/postmasterout 2> /tmp/postmastererr

I set the debug to be -30 instead of its maximum of -3

Oops, it works now, but surely setting the debug level too high by
accident shouldnt cause a loop that eats everything in sight?

I have tested this switching the debug value to be 30 or 3 and in all
instances the 30 crashes it and the 3 does not. I am just concerned
that this may be an indication of a real problem that may notjust be
something that happens when the commandline args are set wrongly.

Just something that might bear looking into
                ~Michael

Michael Simms <grim@argh.demon.co.uk> writes:
> games=>  create table game (
> games-> refnum serial
> games-> );
> NOTICE:  CREATE TABLE will create implicit sequence 'game_refnum_seq' for SERIAL column 'game.refnum'
> NOTICE:  CREATE TABLE/UNIQUE will create implicit index 'game_refnum_key' for table 'game'
> pqReadData() -- backend closed the channel unexpectedly.

> I set the debug to be -30 instead of its maximum of -3

Actually, 3 is not the maximum: 4 and 5 turn on dumping of parse and
plan trees.

What I find is that the parsetree dump attempt recurses infinitely,
because the parser is producing a parsetree with circular references.
The ColumnDef node for refnum has a list of constraints, and one of the
constraints is a CONSTR_UNIQUE node that has a keys list that points
right back at that same ColumnDef node.  Try to dump it, and presto:
infinite recursion in the node print functions.

I am not sure if this is a mistake in the construction of the parsetree
(Thomas, what do you think?) or if the node print functions need to be
modified.  I think it'd be easiest to alter the parsetree, though.
Perhaps the UNIQUE constraint ought to be attached somewhere else.
        regards, tom lane

> I am not sure if this is a mistake in the construction of the parsetree
> (Thomas, what do you think?) or if the node print functions need to be
> modified.  I think it'd be easiest to alter the parsetree, though.
> Perhaps the UNIQUE constraint ought to be attached somewhere else.

If I understand the problem correctly, the "column name" field in the
constraint clause attached to the column node is being used to look up
the column node, resulting in a recursive infinite loop. Or is
something else happening with direct pointers back to a parent node?

The CONSTR_UNIQUE node travels from gram.y to analyze.c attached to
the column node (it can also be specified as a table constraint, and
is attached elsewhere for that case). Within transformCreateStmt(), I
scan through these constraint nodes, filling in missing info, and
collecting them in a "deferred list" to look at later in the same
routine. I don't detach the constraint nodes from the column nodes at
that time, though it might be possible to do so.

Can you clarify the problem for me? I'm afraid that I didn't pay
enough attention to the thread :(
                      - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> I am not sure if this is a mistake in the construction of the parsetree
>> (Thomas, what do you think?) or if the node print functions need to be
>> modified.  I think it'd be easiest to alter the parsetree, though.
>> Perhaps the UNIQUE constraint ought to be attached somewhere else.

> If I understand the problem correctly, the "column name" field in the
> constraint clause attached to the column node is being used to look up
> the column node, resulting in a recursive infinite loop. Or is
> something else happening with direct pointers back to a parent node?

The problem is with direct pointers in the parse tree: the column
node has a list of constraint nodes attached to it, and the UNIQUE
node in that list has a keys field that points at the column node.
The node print routines try to recurse through this structure, and
of course it's a never-ending recursion.

BTW, it's not only SERIAL that causes the problem; plain oldcreate table z2 (f1 int4 unique);
will crash the backend if you start psql with PGOPTIONS="-d5".

As I said, I'm not sure if the answer is to change the parsetree
representation, or to try to make node print/read smarter about
this looping structure.  But I'd incline to the first --- the
looped structure puts all sorts of tree-traversal algorithms at
risk.
        regards, tom lane

> The problem is with direct pointers in the parse tree: the column
> node has a list of constraint nodes attached to it, and the UNIQUE
> node in that list has a keys field that points at the column node.
> The node print routines try to recurse through this structure, and
> of course it's a never-ending recursion.
> BTW, it's not only SERIAL that causes the problem; plain old
>         create table z2 (f1 int4 unique);
> will crash the backend if you start psql with PGOPTIONS="-d5".

Sure. The same structure is used to represent column *and* table
constraints; in the table case there is a need to refer to a column
from within the structure since there is not explicit column context
from a parent to use.

btw, the following *does* work wrt printing the parse tree:

postgres=> create table tc (i int, unique(i));
NOTICE:  CREATE TABLE/UNIQUE will create implicit index        'tc_i_key' for table 'tc'
CREATE

I suppose I could add code to explicitly unlink UNIQUE constraints
from the column-specific constraints, *or* we could change the
structure used for column constraints. I'd prefer mucking with the
parse tree as shipped from gram.y as little as possible, of course,
but your point about trouble lurking with recursive structures is well
taken.

Suggestions?
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California