On Thu, Feb 3, 2022 at 5:24 PM Amit Kapila wrote:
>
> On Thu, Feb 3, 2022 at 8:18 AM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Tom, is it okay for you if I go ahead with this patch after some testing?
> >
> > I've been too busy to get back to it, so sure.
> >
>
> Thanks. I have tested th
On Thu, Feb 3, 2022 at 8:18 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Tom, is it okay for you if I go ahead with this patch after some testing?
>
> I've been too busy to get back to it, so sure.
>
Thanks. I have tested the patch by generating an invalidation message
for table DDL before acc
Amit Kapila writes:
> Tom, is it okay for you if I go ahead with this patch after some testing?
I've been too busy to get back to it, so sure.
regards, tom lane
On Sat, Jan 29, 2022 at 8:32 AM Amit Kapila wrote:
>
> On Thu, Jan 6, 2022 at 3:42 AM Tom Lane 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 thin
On Thu, Jan 6, 2022 at 3:42 AM Tom Lane 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
On Fri, Jan 7, 2022 at 1:28 AM Tom Lane wrote:
>
> Amit Kapila writes:
>
> > + * *during* a callback if we do any syscache or table access in the
> > + * callback.
>
> > As we don't take locks on tables, can invalidation events be accepted
> > during table access? I could be missing something but
On Thu, Jan 6, 2022 at 2:58 PM Tom Lane wrote:
> That might be okay for the system catalog entries, but I don't see
> how it prevents some other session from dropping the table entirely,
> thereby causing the on-disk storage to go away. Is it guaranteed
> that logical decoding will never try to f
Amit Kapila writes:
> On Thu, Jan 6, 2022 at 3:42 AM Tom Lane wrote:
>> Also ... maybe I'm not looking in the right place, but I do not
>> see anything anywhere in logical decoding that is taking any lock
>> on the relation being processed. How can that be safe?
> We don't need to acquire a loc
On Thu, Jan 6, 2022 at 3:42 AM Tom Lane 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
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
10 matches
Mail list logo
