Re: logical replication worker accesses catalogs in error context callback
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter_e@gmx.net>, Petr Jelinek <petr@2ndquadrant.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Date: 2021-01-06T02:42:39Z
Lists: pgsql-hackers
On Wed, Jan 6, 2021 at 11:02 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> Due to a debug ereport I just noticed that worker.c's
> slot_store_error_callback is doing something quite dangerous:
>
> static void
> slot_store_error_callback(void *arg)
> {
> SlotErrCallbackArg *errarg = (SlotErrCallbackArg *) arg;
> LogicalRepRelMapEntry *rel;
> char *remotetypname;
> Oid remotetypoid,
> localtypoid;
>
> /* Nothing to do if remote attribute number is not set */
> if (errarg->remote_attnum < 0)
> return;
>
> rel = errarg->rel;
> remotetypoid = rel->remoterel.atttyps[errarg->remote_attnum];
>
> /* Fetch remote type name from the LogicalRepTypMap cache */
> remotetypname = logicalrep_typmap_gettypname(remotetypoid);
>
> /* Fetch local type OID from the local sys cache */
> localtypoid = get_atttype(rel->localreloid, errarg->local_attnum + 1);
>
> errcontext("processing remote data for replication target relation \"%s.%s\" column \"%s\", "
> "remote type %s, local type %s",
> rel->remoterel.nspname, rel->remoterel.relname,
> rel->remoterel.attnames[errarg->remote_attnum],
> remotetypname,
> format_type_be(localtypoid));
> }
>
>
> that's not code that can run in an error context callback. It's
> theoretically possible (but unlikely) that
> logicalrep_typmap_gettypname() is safe to run in an error context
> callback. But get_atttype() definitely isn't.
>
> get_attype() may do catalog accesses. That definitely can't happen
> inside an error context callback - the entire transaction might be
> borked at this point!
You're right. Perhaps calling to format_type_be() is also dangerous
since it does catalog access. We should have added the local type
names to SlotErrCallbackArg so we avoid catalog access in the error
context.
I'll try to fix this.
Regards,
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
Commits
-
Avoid doing catalog lookups in postgres_fdw's conversion_error_callback.
- bee18616a650 13.4 landed
- bd2e68d0bf94 12.8 landed
- b23ac5aefae4 10.18 landed
- a9460dbf1577 11.13 landed
- 67f925bbd9de 9.6.23 landed
- c7b7311f6177 15.0 landed
- 86d4914210e9 14.0 landed
-
Don't try to print data type names in slot_store_error_callback().
- 63a952167092 14.0 landed
- feff6155734e 12.8 landed
- 7fc97752d566 13.4 landed
- 50371df266d4 15.0 landed
- 32d50b895217 11.13 landed
- 0b5089e8c979 10.18 landed
-
logical replication: fix OID type mapping mechanism
- 24c0a6c64976 11.0 cited
-
Improve sys/catcache performance.
- 141fd1b66ce6 11.0 cited
-
Logical replication
- 665d1fad99e7 10.0 cited