Re: segmentation fault when cassert enabled
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>,
Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-11-06T13:34:38Z
Lists: pgsql-hackers
On 2019-11-05 17:29, Jehan-Guillaume de Rorthais wrote: > My best bet so far is that logicalrep_relmap_invalidate_cb is not called after > the DDL on the subscriber so the relmap cache is not invalidated. So we end up > with slot->tts_tupleDescriptor->natts superior than rel->remoterel->natts in > slot_store_cstrings, leading to the overflow on attrmap and the sigsev. It looks like something like that is happening. But it shouldn't. Different table schemas on publisher and subscriber are well supported, so this must be an edge case of some kind. Please continue investigating. > By the way, I noticed attrmap is declared as AttrNumber * in struct > LogicalRepRelMapEntry, AttrNumber being typedef'd as an int16. However, attrmap > is allocated based on sizeof(int) in logicalrep_rel_open: > > entry->attrmap = palloc(desc->natts * sizeof(int)); > > It doesn't look like a major problem, it just allocates more memory than > needed. Right. I have committed a fix for this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix subscriber invalid memory access on DDL.
- d6eca4958d78 10.12 landed
- 046830164ee4 11.7 landed
- c74111d8bd68 12.2 landed
- 04c8a69c0ccc 13.0 landed
-
Fix memory allocation mistake
- a5b95016af91 10.11 landed
- d213f3114d99 11.6 landed
- 39a6210f9e0f 12.1 landed
- d40abd5fcfb2 13.0 landed