On Thursday, May 26, 2022 11:37 AM Amit Kapila wrote:
> On Wed, May 25, 2022 at 6:54 PM Tomas Vondra
> wrote:
> >
> > On 5/25/22 13:26, Amit Kapila wrote:
> > > On Wed, May 25, 2022 at 8:16 AM Kyotaro Horiguchi
> > > wrote:
> > >>
> > >> It does "fix" the case of [1]. But AFAIS
> > >> RelationS
On Wed, May 25, 2022 at 6:54 PM Tomas Vondra
wrote:
>
> On 5/25/22 13:26, Amit Kapila wrote:
> > On Wed, May 25, 2022 at 8:16 AM Kyotaro Horiguchi
> > wrote:
> >>
> >> It does "fix" the case of [1]. But AFAIS
> >> RelationSyncEntry.replicate_valid is only used to inhibit repeated
> >> loading in
Tomas Vondra writes:
> The other aspect I dislike is that we just stop caching publication
> info, forcing us to reload it for every replicated change/row.
Ouch --- that seems likely to be completely horrid. At the very least
I'd want to see some benchmark numbers before concluding we could
live
On 5/25/22 13:26, Amit Kapila wrote:
> On Wed, May 25, 2022 at 8:16 AM Kyotaro Horiguchi
> wrote:
>>
>> It does "fix" the case of [1]. But AFAIS
>> RelationSyncEntry.replicate_valid is only used to inhibit repeated
>> loading in get_rel_sync_entry and the function doesn't seem to be
>> assumed to
On Wed, May 25, 2022 at 8:16 AM Kyotaro Horiguchi
wrote:
>
> It does "fix" the case of [1]. But AFAIS
> RelationSyncEntry.replicate_valid is only used to inhibit repeated
> loading in get_rel_sync_entry and the function doesn't seem to be
> assumed to return a invalid entry. (Since the flag is no
At Tue, 24 May 2022 18:19:45 +0530, Amit Kapila wrote
in
> On Sat, May 21, 2022 at 9:03 AM Amit Kapila wrote:
> >
> > On Fri, May 20, 2022 at 4:01 PM Tomas Vondra
> > wrote:
> >
> > > Also, we'd probably have to ignore RelationSyncEntry for a while, which
> > > seems quite expensive.
> > >
> >
On Tuesday, May 24, 2022 9:50 PM Amit Kapila wrote:
> On Sat, May 21, 2022 at 9:03 AM Amit Kapila
> wrote:
> >
> > On Fri, May 20, 2022 at 4:01 PM Tomas Vondra
> > wrote:
> >
> > > Also, we'd probably have to ignore RelationSyncEntry for a while,
> > > which seems quite expensive.
> > >
> >
> >
On Sat, May 21, 2022 at 9:03 AM Amit Kapila wrote:
>
> On Fri, May 20, 2022 at 4:01 PM Tomas Vondra
> wrote:
>
> > Also, we'd probably have to ignore RelationSyncEntry for a while, which
> > seems quite expensive.
> >
>
> Yet another option could be that we continue using a historic snapshot
> bu
On Fri, May 20, 2022 at 4:01 PM Tomas Vondra
wrote:
>
> On 5/20/22 05:58, Amit Kapila wrote:
>
> Are we really querying the publications (in get_rel_sync_entry) using
> the historical snapshot?
>
Yes.
> I haven't really realized this, but yeah, that
> might explain the issue.
>
> The new TAP tes
On Thursday, May 19, 2022 8:13 PM Amit Kapila wrote:
> On Thu, May 19, 2022 at 3:16 PM Amit Kapila
> wrote:
> >
> > On Thu, May 19, 2022 at 12:28 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Thu, 19 May 2022 14:26:56 +1000, Peter Smith
> > > wrote in
> > > > Hi hackers.
> > > >
> > > > FYI, I
On 5/20/22 05:58, Amit Kapila wrote:
> On Fri, May 20, 2022 at 6:58 AM Kyotaro Horiguchi
> wrote:
>>
the apply worker will use the existing slot and replication origin
corresponding to the subscription. Now, it is possible that before
restart the origin has not been updated and t
On Fri, May 20, 2022 at 6:58 AM Kyotaro Horiguchi
wrote:
>
> > > the apply worker will use the existing slot and replication origin
> > > corresponding to the subscription. Now, it is possible that before
> > > restart the origin has not been updated and the WAL start location
> > > points to a lo
At Thu, 19 May 2022 16:42:31 +0530, Amit Kapila wrote
in
> On Thu, May 19, 2022 at 3:16 PM Amit Kapila wrote:
> >
> > This happens after "ALTER SUBSCRIPTION sub1 SET PUBLICATION pub9". The
> > probable theory is that ALTER SUBSCRIPTION will lead to restarting of
> > apply worker (which we can s
On Thu, May 19, 2022 at 3:16 PM Amit Kapila wrote:
>
> On Thu, May 19, 2022 at 12:28 PM Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 19 May 2022 14:26:56 +1000, Peter Smith
> > wrote in
> > > Hi hackers.
> > >
> > > FYI, I saw that there was a recent Build-farm error on the "grison"
> > > machin
On Thu, May 19, 2022 at 12:28 PM Kyotaro Horiguchi
wrote:
>
> At Thu, 19 May 2022 14:26:56 +1000, Peter Smith wrote
> in
> > Hi hackers.
> >
> > FYI, I saw that there was a recent Build-farm error on the "grison" machine
> > [1]
> > [1]
> > https://buildfarm.postgresql.org/cgi-bin/show_history
At Thu, 19 May 2022 14:26:56 +1000, Peter Smith wrote
in
> Hi hackers.
>
> FYI, I saw that there was a recent Build-farm error on the "grison" machine
> [1]
> [1] https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=grison&br=HEAD
>
> The error happened during "subscriptionCheck" phase
16 matches
Mail list logo
