PG Bug reporting form <noreply@postgresql.org> writes:
> I'm getting a segfault when trying to pg_dump a database containing the
> postgis extension, but only when excluding the spatial_ref_sys table.
Yeah, I can reproduce this here. You don't really need postgis.
What I did was
1. Install the src/test/modules/test_pg_dump module into an
empty database.
2. alter table regress_table_dumpable add check(col1 > 0);
3. pg_dump -T regress_table_dumpable d1
While I haven't traced through it in complete detail, what seems to
be happening is
A. checkExtensionMembership sees that the table belongs to an extension,
hence marks it
dobj->dump = ext->dobj.dump_contains & (DUMP_COMPONENT_ACL |
DUMP_COMPONENT_SECLABEL |
DUMP_COMPONENT_POLICY);
(This ends up setting only the SECLABEL and POLICY bits, I didn't
check why.)
B. processExtensionTables sees that the table is excluded by an exclusion
switch, so it sets configtbl->interesting = false.
(I've not verified whether B happens before or after A. But we definitely
end up with a TableInfo having dobj.dump = 40, interesting = false.)
C. getTableAttrs sees that the table is marked interesting = false,
so it doesn't bother loading any subsidiary data; particularly not
the checkexprs[] array. But ncheck is positive because getTables filled
it.
D. Since dobj.dump is non-zero, we eventually wind up at dumpTableSchema,
which crashes because checkexprs is NULL. It's a bit surprising that
it doesn't crash sooner, but whatever. We should absolutely not be in
that code at all for a table we didn't load all the subsidiary data for.
So I think the basic problem here is that checkExtensionMembership and
processExtensionTables are not on the same page. We can't have
interesting = false for a table that any of the dobj.dump bits are set
for.
Arguably, we should get rid of the "interesting" flag entirely now that
we have dobj.dump. I can't see that it's anything but a foot-gun.
Stephen, I think you touched this code last; any thoughts?
regards, tom lane