Thread: pg_dump seg fault on sequences

I've narrowed down the conditions under which pg_dump in 8.2.3 is creating a segmentation fault. 

It appears to happen only when dumping a sequence that is created for a serial data element.


uscf=> create table public.seqtest
uscf-> (field1 text,
uscf(> field2 serial);
create table public.seqtest
(field1 text,
field2 serial);
NOTICE:  CREATE TABLE will create implicit sequence "seqtest_field2_seq" for ser
ial column "seqtest.field2"
CREATE TABLE
Time: 222.913 ms
uscf=> insert into seqtest values ('x');
insert into seqtest values ('x');
INSERT 0 1
Time: 14.065 ms
uscf=> select * from seqtest;
select * from seqtest;
field1 | field2
--------+--------
x      |      1
(1 row)

[uscf@kingside testing]$ /usr/local/pgsql/bin/pg_dump -t seqtest_field2_seq -U uscf uscf
Password:
Segmentation fault
--
Mike Nolan

"Michael Nolan" <htfoot@gmail.com> writes:
> I've narrowed down the conditions under which pg_dump in 8.2.3 is creating a
> segmentation fault.
> It appears to happen only when dumping a sequence that is created for a
> serial data element.

Thanks for the test case --- I can reproduce this now on 8.2 and HEAD too.
Will take a look tomorrow if no one beats me to it.

            regards, tom lane

On Sat, Apr 14, 2007 at 06:26:22PM -0400, Tom Lane wrote:
> "Michael Nolan" <htfoot@gmail.com> writes:
> > I've narrowed down the conditions under which pg_dump in 8.2.3 is creating a
> > segmentation fault.
> > It appears to happen only when dumping a sequence that is created for a
> > serial data element.
>
> Thanks for the test case --- I can reproduce this now on 8.2 and HEAD too.
> Will take a look tomorrow if no one beats me to it.

(gdb) bt
#0  0x0001e500 in dumpTable (fout=0x53498, tbinfo=0x8c7e0) at pg_dump.c:8733
#1  0x0001f12c in dumpDumpableObject (fout=0x53498, dobj=0x8c7e0) at pg_dump.c:5009
#2  0x00020dd8 in main (argc=4, argv=0x6e) at pg_dump.c:691
(gdb) l 8733,+1
8733                    appendPQExpBuffer(query, ".%s;\n",
8734                            fmtId(owning_tab->attnames[tbinfo->owning_col - 1]));
(gdb) p owning_tab->attnames
$1 = (char **) 0x0

--
Michael Fuhr

I wrote:
> "Michael Nolan" <htfoot@gmail.com> writes:
>> I've narrowed down the conditions under which pg_dump in 8.2.3 is creating a
>> segmentation fault.
>> It appears to happen only when dumping a sequence that is created for a
>> serial data element.

> Thanks for the test case --- I can reproduce this now on 8.2 and HEAD too.
> Will take a look tomorrow if no one beats me to it.

The failure occurs while trying to emit an ALTER SEQUENCE OWNED BY
command to link the sequence to its owning serial column.  If we chose
not to dump the parent table then we won't have collected enough
information about it to create this command (specifically, we never
fetched its column names).

The definitional question is: if we selected only the sequence to dump,
do we want that ALTER command to appear in the output or not?  It's a
reasonably straightforward fix either way (a bit easier for "not"),
but I'm unsure which is the most useful behavior.

            regards, tom lane

It seems to me that the logical way to do this would be that when the underlying table is dumped the sequence is dumped with it, like indexes are. Otherwise if the table is restored from the dump file the sequence may be out of sync, or not present at all.

What happens when dumping a table with foreign key constraints? 

Dumping the sequence separately should also be permissable, but possibly with some kind of warning note in the dump output that the sequence is linked to a data field.
--
Mike Nolan

"Michael Nolan" <htfoot@gmail.com> writes:
> It seems to me that the logical way to do this would be that when the
> underlying table is dumped the sequence is dumped with it, like indexes are.

We do that.  The question is how to respond when the pg_dump user
specifically commands us to dump only the sequence, as you did.
Should it be dumped as if it were a standalone sequence, or not?

            regards, tom lane

I wrote:
> The definitional question is: if we selected only the sequence to dump,
> do we want that ALTER command to appear in the output or not?  It's a
> reasonably straightforward fix either way (a bit easier for "not"),
> but I'm unsure which is the most useful behavior.

There doesn't seem to be any strong opinion out there one way or the
other, so I'll fix it the easier way: the ALTER OWNED BY will only
appear if both the table and the sequence are selected to be dumped.

            regards, tom lane