Re: logical replication worker accesses catalogs in error context callback - Mailing list pgsql-hackers

From Tom Lane
Subject Re: logical replication worker accesses catalogs in error context callback
Date
Msg-id 1130414.1625256448@sss.pgh.pa.us
Whole thread Raw
In response to Re: logical replication worker accesses catalogs in error context callback  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: logical replication worker accesses catalogs in error context callback  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: logical replication worker accesses catalogs in error context callback  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
>> << Attaching v5-0001 here again for completion >>
>> I'm attaching v5-0001 patch that avoids printing the column type names
>> in the context message thus no cache lookups have to be done in the
>> error context callback. I think the column name is enough to know on
>> which column the error occurred and if required it's type can be known
>> by the user. This patch gets rid of printing local and remote type
>> names in slot_store_error_callback and also
>> logicalrep_typmap_gettypname because it's unnecessary. Thoughts?

I've now pushed this patch.  I noted that once we drop
logicalrep_typmap_gettypname, there's really nothing using
the LogicalRepTypMap table at all, so I nuked that too.
(We can always recover the code from the git archives if
some reason to use it emerges.)

Didn't look at 0002 yet.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: psql - factor out echo code
Next
From: Jeff Davis
Date:
Subject: Re: Synchronous commit behavior during network outage