Thread: Re: [HACKERS] v6.5 release ToDo
gjerde@icebox.org wrote (a couple weeks ago):
> While running postmaster at the command line like this:
> /home/postgres/bin/postmaster -B 1024 -D/home/postgres/data -d 9 -o "-S
> 4096 -s -d 9 -A"
> the current backend for the following CREATE TABLE would
> die(consistently):
> CREATE TABLE oletest (
> id serial,
> number int,
> string varchar(255)
> );
Are you still seeing this with current sources? I'm not able to
replicate it here...
regards, tom lane
On Sun, 16 May 1999, Tom Lane wrote:
> gjerde@icebox.org wrote (a couple weeks ago):
> > While running postmaster at the command line like this:
> > /home/postgres/bin/postmaster -B 1024 -D/home/postgres/data -d 9 -o "-S
> > 4096 -s -d 9 -A"
> Are you still seeing this with current sources? I'm not able to
> replicate it here...
Yep..
It appears to die while making the index for serial.
Postmaster keeps running, but the current backend dies in pqReadData().
gdb and postmaster output below.
Ole Gjerde
gdb of core:
#0 0x4013a30a in _IO_default_xsputn (f=0xbf8006f4, data=0x81377e0, n=20) at genops.c:382
#1 0x40129980 in _IO_vfprintf (s=0xbf8006f4, format=0x81377e0 " COLUMNDEF :colname %s :typename ", ap=0xbf800c08)
atvfprintf.c:1048
#2 0x40137d16 in _IO_vsnprintf (string=0xbf8007f8 "", maxlen=1024, format=0x81377e0 " COLUMNDEF :colname %s
:typename", args=0xbf800c08) at vsnprintf.c:129
#3 0x809ccfb in appendStringInfo ()
#4 0x80b637b in _outColumnDef ()
#5 0x80b8107 in _outNode ()
#6 0x80b7d79 in _outNode ()
#7 0x80b7cab in _outConstraint ()
#8 0x80b84b7 in _outNode ()
#9 0x80b7d79 in _outNode ()
#10 0x80b63bb in _outColumnDef ()
#11 0x80b8107 in _outNode ()
#12 0x80b7d79 in _outNode ()
And this keeps going and going and going..
---------------------------------------------
postmaster log:
StartTransactionCommand
query: create table oletest (
id serial,
number int,
string varchar(255)
);
NOTICE: CREATE TABLE will create implicit sequence 'oletest_id_seq' for SERIAL column 'oletest.id'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'oletest_id_key' for table 'oletest'
parser outputs:
{ QUERY :command 5 :utility ? :resultRelation 0 :into <> :isPortal false :isBinary false :isTemp false
:unionall false :unique <> :sortClause <> :rtable <> :targetlist <> :qual <> :groupClause <> :havingQual
<> :hasAggs false :hasSubLinks false :unionClause <> :intersectClause <> :limitOffset <> :limitCount <>
:rowMark<> }
parser outputs:
bin/postmaster: reaping dead processes...
bin/postmaster: CleanupProc: pid 593 exited with status 139
bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
shmem_exit(0) [#0]
binding ShmemCreate(key=52e325, size=9343632)
Ole Gjerde <gjerde@icebox.org> writes:
> gdb of core:
> #0 0x4013a30a in _IO_default_xsputn (f=0xbf8006f4, data=0x81377e0, n=20)
> at genops.c:382
> #1 0x40129980 in _IO_vfprintf (s=0xbf8006f4,
> format=0x81377e0 " COLUMNDEF :colname %s :typename ", ap=0xbf800c08)
> at vfprintf.c:1048
> #2 0x40137d16 in _IO_vsnprintf (string=0xbf8007f8 "", maxlen=1024,
> format=0x81377e0 " COLUMNDEF :colname %s :typename ", args=0xbf800c08)
> at vsnprintf.c:129
> #3 0x809ccfb in appendStringInfo ()
> #4 0x80b637b in _outColumnDef ()
> #5 0x80b8107 in _outNode ()
> #6 0x80b7d79 in _outNode ()
> #7 0x80b7cab in _outConstraint ()
> #8 0x80b84b7 in _outNode ()
> #9 0x80b7d79 in _outNode ()
> #10 0x80b63bb in _outColumnDef ()
> #11 0x80b8107 in _outNode ()
> #12 0x80b7d79 in _outNode ()
> And this keeps going and going and going..
Hmm, that looks like a column constraint has somehow gotten recursively
linked back to its parent column definition node.
I poked around in the code for serial-column constraints, and found that
Lockhart's last patch had a subtle bug --- he wrote more characters in
the constraint text without increasing the space palloc'd for the
string. That could maybe cause such a problem, depending on what
happened to be living next door to the string... But I don't really
think this explains your complaint, because according to the cvs log
that change was made on 5/13, and you reported a problem quite some time
before that. Still, please fetch the current cvs sources or apply this
patch:
*** src/backend/parser/analyze.c.orig Sun May 16 10:29:33 1999
--- src/backend/parser/analyze.c Mon May 17 00:50:07 1999
***************
*** 545,551 **** constraint = makeNode(Constraint); constraint->contype =
CONSTR_DEFAULT; constraint->name = sname;
! cstring = palloc(9 + strlen(constraint->name) + 2 + 1); strcpy(cstring,
"nextval('\""); strcat(cstring, constraint->name); strcat(cstring, "\"')");
--- 545,551 ---- constraint = makeNode(Constraint); constraint->contype =
CONSTR_DEFAULT; constraint->name = sname;
! cstring = palloc(10 + strlen(constraint->name) + 3 + 1); strcpy(cstring,
"nextval('\""); strcat(cstring, constraint->name); strcat(cstring, "\"')");
and let us know if anything changes...
regards, tom lane
On Mon, 17 May 1999, Tom Lane wrote: > I poked around in the code for serial-column constraints, and found that > Lockhart's last patch had a subtle bug --- he wrote more characters in > the constraint text without increasing the space palloc'd for the > string. That could maybe cause such a problem, depending on what > happened to be living next door to the string... But I don't really > think this explains your complaint, because according to the cvs log > that change was made on 5/13, and you reported a problem quite some time > before that. Still, please fetch the current cvs sources or apply this > patch: [snip] > and let us know if anything changes... Yep, that takes care of it! Thanks Ole Gjerde
> Lockhart's last patch had a subtle bug
:( Thanks for fixing it...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California