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.
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 |