Re: Bugs in pgoutput.c

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com>
Subject: Re: Bugs in pgoutput.c
Date: 2022-02-03 02:45:16
Message-ID: CAA4eK1+uJZ6qYcZxp_A19ZCByhdhui3T3PZ2_ipnJDpwuuzo-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 29, 2022 at 8:32 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jan 6, 2022 at 3:42 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Commit 6ce16088b caused me to look at pgoutput.c's handling of
> > cache invalidations, and I was pretty appalled by what I found.
> >
> > * rel_sync_cache_relation_cb does the wrong thing when called for
> > a cache flush (i.e., relid == 0). Instead of invalidating all
> > RelationSyncCache entries as it should, it will do nothing.
> >
> > * When rel_sync_cache_relation_cb does invalidate an entry,
> > it immediately zaps the entry->map structure, even though that
> > might still be in use (as per the adjacent comment that carefully
> > explains why this isn't safe). I'm not sure if this could lead
> > to a dangling-pointer core dump, but it sure seems like it could
> > lead to failing to translate tuples that are about to be sent.
> >
> > * Similarly, rel_sync_cache_publication_cb is way too eager to
> > reset the pubactions flags, which would likely lead to failing
> > to transmit changes that we should transmit.
> >
>
> Are you planning to proceed with this patch?
>

Tom, is it okay for you if I go ahead with this patch after some testing?

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-03 02:48:18 Re: Bugs in pgoutput.c
Previous Message Andres Freund 2022-02-03 02:38:00 Re: Windows crash / abort handling