Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity - Mailing list pgsql-hackers

From Amit Langote
Subject Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity
Date
Msg-id CA+HiwqHE44q2=soXa=g823k6PK9oKRLtq-Q-Y4G+2Tn6f5-UWA@mail.gmail.com
Whole thread Raw
In response to Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity
List pgsql-hackers
On Mon, Sep 2, 2019 at 6:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
> > As far as 4) goes, I think the code in ExtractReplicaIdentity is pretty
> > duff anyway, because it doesn't bother to check for the defined failure
> > return for RelationIdGetRelation.  But if we're concerned about the
> > cost of recalculating this stuff per-row, couldn't we cache it a little
> > better?  It should be safe to assume the set of index columns isn't
> > changing intra-query.
> > ... in fact, isn't all the infrastructure for that present already?
> > Why is this code looking directly at the index at all, rather than
> > using the relcache's rd_idattr bitmap?
>
> Here's a proposed patch along those lines.  It fixes Hadi's original
> crash case and passes check-world.

Agree that this patch would be a better solution for Hadi's report,
although I also agree that the situation with index locking for DELETE
isn't perfect.

> I'm a bit suspicious of the exclusion for idattrs being empty, but
> if I remove that, some of the contrib/test_decoding test results
> change.  Anybody want to comment on that?  If that's actually an
> expected situation, why is there an elog(DEBUG) in that path?

ISTM that the exclusion case may occur with the table's replica
identity being REPLICA_IDENTITY_DEFAULT and there being no primary
index defined, in which case nothing needs to get logged.

The elog(DEBUG) may just be a remnant from the days when this was
being developed.  I couldn't find any notes on it though in the
archives [1] though.

Thanks,
Amit

[1] https://www.postgresql.org/message-id/flat/20131204155510.GO24801%40awork2.anarazel.de



pgsql-hackers by date:

Previous
From: "r.takahashi_2@fujitsu.com"
Date:
Subject: pg_basebackup -F t fails when fsync spends more time thantcp_user_timeout
Next
From: Alexander Korotkov
Date:
Subject: Bug in GiST paring heap comparator