On Tue, Jun 1, 2021 at 6:56 PM Amit Kapila wrote:
> On Mon, May 31, 2021 at 8:51 AM Amit Langote wrote:
> > On Thu, May 27, 2021 at 3:36 PM Amit Kapila wrote:
> > > Why do we need to move send_relation_and_attrs() call? I think it
> > > doesn't matter much either way but OTOH, in the existing co
On Mon, May 31, 2021 at 8:51 AM Amit Langote wrote:
>
> On Thu, May 27, 2021 at 3:36 PM Amit Kapila wrote:
> > On Fri, May 21, 2021 at 1:12 PM Amit Langote
> > wrote:
> > >
> >
> > Why do we need to move send_relation_and_attrs() call? I think it
> > doesn't matter much either way but OTOH, in
On Thu, May 27, 2021 at 3:36 PM Amit Kapila wrote:
> On Fri, May 21, 2021 at 1:12 PM Amit Langote wrote:
> >
> > Hmm, maybe get_rel_syn_entry() should explicitly set map to NULL when
> > first initializing an entry. It's possible that without doing so, the
> > map remains set to a garbage value,
On Fri, May 21, 2021 at 1:12 PM Amit Langote wrote:
>
> Hmm, maybe get_rel_syn_entry() should explicitly set map to NULL when
> first initializing an entry. It's possible that without doing so, the
> map remains set to a garbage value, which causes the invalidation
> callback that runs into such
On Monday, May 24, 2021 12:57 PM I wrote:
> On Monday, May 24, 2021 12:23 PM Amit Langote
> wrote:
> > On Mon, May 24, 2021 at 12:16 PM osumi.takami...@fujitsu.com
> > wrote:
> > > When I execute make check-world with v6 additionally, I've gotten
> > > another failure. I get this about once in
>
On Monday, May 24, 2021 12:23 PM Amit Langote wrote:
> On Mon, May 24, 2021 at 12:16 PM osumi.takami...@fujitsu.com
> wrote:
> > When I execute make check-world with v6 additionally, I've gotten
> > another failure. I get this about once in
> > 20 times of make check-world with v6.
> Hmm, I doubt
On Mon, May 24, 2021 at 12:16 PM osumi.takami...@fujitsu.com
wrote:
> On Saturday, May 22, 2021 11:58 AM Amit Langote
> wrote:
> > On Sat, May 22, 2021 at 11:00 AM osumi.takami...@fujitsu.com
> > wrote:
> > > I've checked the core file of v3's failure core and printed the entry
> > > to get mor
On Saturday, May 22, 2021 11:58 AM Amit Langote wrote:
> On Sat, May 22, 2021 at 11:00 AM osumi.takami...@fujitsu.com
> wrote:
> > I've checked the core file of v3's failure core and printed the entry
> > to get more confidence. Sorry for inappropriate measure to verify the
> solution.
> >
> > $1
On Sat, May 22, 2021 at 11:00 AM osumi.takami...@fujitsu.com
wrote:
> On Friday, May 21, 2021 9:45 PM I worte:
> > On Friday, May 21, 2021 4:43 PM Amit Langote
> > wrote:
> > > On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > > But, I've detected segmentation faults
On Friday, May 21, 2021 9:45 PM I worte:
> On Friday, May 21, 2021 4:43 PM Amit Langote
> wrote:
> > On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> > wrote:
> > > But, I've detected segmentation faults caused by the patch, which
> > > can happen during 100_bugs.pl in src/test/subsc
On Friday, May 21, 2021 4:43 PM Amit Langote wrote:
> On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
> wrote:
> > But, I've detected segmentation faults caused by the patch, which can
> > happen during 100_bugs.pl in src/test/subscription.
> > This happens more than one in ten times.
On Fri, May 21, 2021 at 3:55 PM osumi.takami...@fujitsu.com
wrote:
> On Thursday, May 20, 2021 9:59 PM Amit Langote
> wrote:
> > Here are updated/divided patches.
> Thanks for your updates.
>
> But, I've detected segmentation faults caused by the patch,
> which can happen during 100_bugs.pl in s
On Friday, May 21, 2021 3:55 PM I wrote:
> On Thursday, May 20, 2021 9:59 PM Amit Langote
> wrote:
> > Here are updated/divided patches.
> Thanks for your updates.
>
> But, I've detected segmentation faults caused by the patch, which can
> happen during 100_bugs.pl in src/test/subscription.
> Thi
On Thursday, May 20, 2021 9:59 PM Amit Langote wrote:
> Here are updated/divided patches.
Thanks for your updates.
But, I've detected segmentation faults caused by the patch,
which can happen during 100_bugs.pl in src/test/subscription.
This happens more than one in ten times.
This problem would
On Thu, May 20, 2021 at 5:59 PM osumi.takami...@fujitsu.com
wrote:
> On Tuesday, May 18, 2021 3:30 PM Amit Langote wrote:
> > While doing so, it occurred to me (maybe not for the first time) that we are
> > *unnecessarily* doing send_relation_and_attrs() for a relation if the
> > changes
> > wil
On Tuesday, May 18, 2021 3:30 PM Amit Langote wrote:
> On Mon, May 17, 2021 at 9:45 PM osumi.takami...@fujitsu.com
> wrote:
> > On Monday, May 17, 2021 6:52 PM Amit Langote
> wrote:
> > > Both patches are attached.
> > The patch for PG13 can be applied to it cleanly and the RT succeeded.
> >
>
On Tuesday, May 18, 2021 3:30 PM Amit Langote wrote:
> While doing so, it occurred to me (maybe not for the first time) that we are
> *unnecessarily* doing send_relation_and_attrs() for a relation if the changes
> will be published using an ancestor's schema. In that case, sending only the
> ance
On Wednesday, May 19, 2021 1:52 PM Amit Kapila wrote:
> > > I am not sure but I
> > > > think we should prohibit truncate on user_catalog_tables as we
> > > > prohibit truncate on system catalog tables (see below [1]) if we
> > > > want plugin to lock them, otherwise, as you said it might lead to
On Wed, May 19, 2021 at 8:28 AM osumi.takami...@fujitsu.com
wrote:
>
> On Wednesday, May 19, 2021 11:33 AM Amit Kapila
> wrote:
> > On Wed, May 19, 2021 at 7:59 AM Amit Kapila
> > wrote:
> > >
> > > On Tue, May 18, 2021 at 5:29 PM Amit Kapila
> > wrote:
> > > >
> > > > On Tue, May 18, 2021 at
On Wednesday, May 19, 2021 11:33 AM Amit Kapila wrote:
> On Wed, May 19, 2021 at 7:59 AM Amit Kapila
> wrote:
> >
> > On Tue, May 18, 2021 at 5:29 PM Amit Kapila
> wrote:
> > >
> > > On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> > > wrote:
> > > >
> > > > On Monday, May 17, 2021
On Wed, May 19, 2021 at 7:59 AM Amit Kapila wrote:
>
> On Tue, May 18, 2021 at 5:29 PM Amit Kapila wrote:
> >
> > On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Monday, May 17, 2021 6:45 PM Amit Kapila
> > > wrote:
> > > >
> > > > We allow taking locks on
On Tue, May 18, 2021 at 5:29 PM Amit Kapila wrote:
>
> On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> > >
> > > We allow taking locks on system catalogs, so why prohibit
> > > user_catalog_tables? However, I agree
On Tue, May 18, 2021 at 1:29 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> >
> > We allow taking locks on system catalogs, so why prohibit
> > user_catalog_tables? However, I agree that if we want plugins to acquire the
> > lock on user_catalog_tab
On Monday, May 17, 2021 6:45 PM Amit Kapila wrote:
> On Fri, May 14, 2021 at 2:20 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Thursday, May 13, 2021 7:21 PM Amit Kapila
> wrote:
> > > I don't think we can reproduce it with core plugins as they don't
> > > lock user catalog tables.
> > OK.
On Mon, May 17, 2021 at 9:45 PM osumi.takami...@fujitsu.com
wrote:
> On Monday, May 17, 2021 6:52 PM Amit Langote wrote:
> > Both patches are attached.
> The patch for PG13 can be applied to it cleanly and the RT succeeded.
>
> I have few really minor comments on your comments in the patch.
>
> (
On Monday, May 17, 2021 6:52 PM Amit Langote wrote:
> On Mon, May 17, 2021 at 6:13 PM Amit Kapila
> wrote:
> > On Fri, May 14, 2021 at 12:44 PM Amit Langote
> wrote:
> > > On Thu, May 13, 2021 at 7:43 PM Amit Kapila
> wrote:
> > >
> > > > Also, don't we need to free the
> > > > entire map as su
On Mon, May 17, 2021 at 6:13 PM Amit Kapila wrote:
> On Fri, May 14, 2021 at 12:44 PM Amit Langote wrote:
> > On Thu, May 13, 2021 at 7:43 PM Amit Kapila wrote:
> >
> > > Also, don't we need to free the
> > > entire map as suggested by me?
> >
> > Yes, I had missed that too. Addressed in the up
On Fri, May 14, 2021 at 2:20 PM osumi.takami...@fujitsu.com
wrote:
>
> On Thursday, May 13, 2021 7:21 PM Amit Kapila wrote:
> > I don't think we can reproduce it with core plugins as they don't lock user
> > catalog tables.
> OK. My current understanding about how the deadlock happens is below.
>
On Fri, May 14, 2021 at 12:44 PM Amit Langote wrote:
>
> On Thu, May 13, 2021 at 7:43 PM Amit Kapila wrote:
>
> > Also, don't we need to free the
> > entire map as suggested by me?
>
> Yes, I had missed that too. Addressed in the updated patch.
>
+ relentry->map = convert_tuples_by_name(indesc,
On Thursday, May 13, 2021 7:21 PM Amit Kapila wrote:
> On Thu, May 13, 2021 at 11:15 AM osumi.takami...@fujitsu.com
> wrote:
> >
> > I tried the following scenarios for trying to reproduce this.
> > Scenario2:
> > (1) set up 1 publisher and 1 subscriber
> > (2) create table with user_catalog_tabl
Takamichi-san,
On Fri, May 14, 2021 at 11:19 AM osumi.takami...@fujitsu.com
wrote:
> On Thursday, May 13, 2021 7:43 PM Amit Kapila wrote:
> > On Tue, Apr 20, 2021 at 8:36 AM Amit Langote
> > wrote:
> > > Back in:
> > https://www.postgresql.org/message-id/CA%2BHiwqEeU19iQgjN6HF1HTP
> > U0L5%2
>
On Thu, May 13, 2021 at 7:43 PM Amit Kapila wrote:
> On Tue, Apr 20, 2021 at 8:36 AM Amit Langote wrote:
> > On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila wrote:
> > > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund
> > > wrote:> > This made me take a brief look at pgoutput.c - maybe I am
> > >
On Thursday, May 13, 2021 7:43 PM Amit Kapila wrote:
> On Tue, Apr 20, 2021 at 8:36 AM Amit Langote
> wrote:
> > Back in:
> https://www.postgresql.org/message-id/CA%2BHiwqEeU19iQgjN6HF1HTP
> U0L5%2
> > BJxyS5CmxaOVGNXBAfUY06Q%40mail.gmail.com
> >
> > I had proposed to move the map creation from m
On Tue, Apr 20, 2021 at 8:36 AM Amit Langote wrote:
>
> On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila wrote:
> > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:>
> > > This made me take a brief look at pgoutput.c - maybe I am missing
> > > something, but how is the following not a memory le
On Thu, May 13, 2021 at 11:15 AM osumi.takami...@fujitsu.com
wrote:
>
> On Thursday, April 29, 2021 2:31 PM Amit Kapila
> wrote:
> > I am not so sure about it because I think we don't have any example of
> > user_catalog_tables in the core code. This is the reason I was kind of
> > looking
> >
On Thursday, April 29, 2021 2:31 PM Amit Kapila wrote:
> I am not so sure about it because I think we don't have any example of
> user_catalog_tables in the core code. This is the reason I was kind of looking
> towards Andres to clarify this. Right now, if the user performs TRUNCATE on
> user_cata
Takamichi-san,
On Tue, Apr 27, 2021 at 9:37 PM osumi.takami...@fujitsu.com
wrote:
> On Tuesday, April 20, 2021 12:07 PM Amit Langote
> wrote:
> > On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila
> > wrote:
> > > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund
> > > wrote:> > This made me take a bri
On Wed, Apr 28, 2021 at 5:36 PM osumi.takami...@fujitsu.com
wrote:
>
> On Monday, April 26, 2021 2:05 PM Amit Kapila wrote:
> > On Fri, Apr 23, 2021 at 8:03 PM osumi.takami...@fujitsu.com
> > wrote:
> > I think we are allowed to decode the operations on user catalog tables
> > because we are usi
On Monday, April 26, 2021 2:05 PM Amit Kapila wrote:
> On Fri, Apr 23, 2021 at 8:03 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Saturday, April 17, 2021 4:13 PM Amit Kapila
> wrote:
> > > > I also don't find a test for this. It is introduced in
> > > > 5dfd1e5a6696, wrote by Simon Riggs,
On Tuesday, April 20, 2021 12:07 PM Amit Langote
wrote:
> On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila
> wrote:
> > On Fri, Apr 16, 2021 at 11:24 PM Andres Freund
> > wrote:> > This made me take a brief look at pgoutput.c - maybe I am
> > missing
> > > something, but how is the following not a m
On Fri, Apr 23, 2021 at 8:03 PM osumi.takami...@fujitsu.com
wrote:
>
> On Saturday, April 17, 2021 4:13 PM Amit Kapila
> wrote:
> > > I also don't find a test for this. It is introduced in 5dfd1e5a6696,
> > > wrote by Simon Riggs, Marco Nenciarini and Peter Eisentraut. Maybe
> > > they can exp
On Fri, 23 Apr 2021 at 22:33, osumi.takami...@fujitsu.com
wrote:
> On Saturday, April 17, 2021 4:13 PM Amit Kapila
> wrote:
>> On Sat, Apr 17, 2021 at 12:05 PM Japin Li wrote:
>> >
>> > On Sat, 17 Apr 2021 at 14:09, Amit Kapila
>> wrote:
>> > > On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila
>
On Saturday, April 17, 2021 4:13 PM Amit Kapila wrote:
> On Sat, Apr 17, 2021 at 12:05 PM Japin Li wrote:
> >
> > On Sat, 17 Apr 2021 at 14:09, Amit Kapila
> wrote:
> > > On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila
> wrote:
> > >>
> > >> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
> > >> >
On Sat, Apr 17, 2021 at 1:30 PM Amit Kapila wrote:
> On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:> >
> This made me take a brief look at pgoutput.c - maybe I am missing
> > something, but how is the following not a memory leak?
> >
> > static void
> > maybe_send_schema(LogicalDecodingCo
On Sat, Apr 17, 2021 at 12:01 PM Amit Kapila wrote:
>
> On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:
> >
> >
> > > I think it is also important to *not* acquire any lock on relation
> > > otherwise it can lead to some sort of deadlock or infinite wait in the
> > > decoding process. Consi
On Sat, Apr 17, 2021 at 12:05 PM Japin Li wrote:
>
> On Sat, 17 Apr 2021 at 14:09, Amit Kapila wrote:
> > On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila wrote:
> >>
> >> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
> >> >
> >> > The RelationIdGetRelation() comment says:
> >> >
> >> > > Caller s
On Sat, 17 Apr 2021 at 14:09, Amit Kapila wrote:
> On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila wrote:
>>
>> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
>> >
>> > The RelationIdGetRelation() comment says:
>> >
>> > > Caller should eventually decrement count. (Usually,
>> > > that happens by
On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:
>
>
> > I think it is also important to *not* acquire any lock on relation
> > otherwise it can lead to some sort of deadlock or infinite wait in the
> > decoding process. Consider a case for operations like Truncate (or if
> > the user has acq
On Thu, Apr 15, 2021 at 4:53 PM Amit Kapila wrote:
>
> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
> >
> > The RelationIdGetRelation() comment says:
> >
> > > Caller should eventually decrement count. (Usually,
> > > that happens by calling RelationClose().)
> >
> > However, it doesn't do it
On Fri, Apr 16, 2021 at 11:24 PM Andres Freund wrote:
>
> > I think it is also important to *not* acquire any lock on relation
> > otherwise it can lead to some sort of deadlock or infinite wait in the
> > decoding process. Consider a case for operations like Truncate (or if
> > the user has acqui
Hi,
On 2021-04-16 08:42:40 +0530, Amit Kapila wrote:
> I think it is because relation_open expects either caller to have a
> lock on the relation or don't use 'NoLock' lockmode. AFAIU, we don't
> need to acquire a lock on relation while decoding changes from WAL
> because it uses a historic snapsh
On Thu, Apr 15, 2021 at 10:56 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
> >>
> >> The RelationIdGetRelation() comment says:
> >>
> > Caller should eventually decrement count. (Usually,
> > that happens by calling RelationClose().)
> >>
> >> Ho
Amit Kapila writes:
> On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
>>
>> The RelationIdGetRelation() comment says:
>>
> Caller should eventually decrement count. (Usually,
> that happens by calling RelationClose().)
>>
>> However, it doesn't do it in ReorderBufferProcessTXN().
>> I think we
On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote:
>
> The RelationIdGetRelation() comment says:
>
> > Caller should eventually decrement count. (Usually,
> > that happens by calling RelationClose().)
>
> However, it doesn't do it in ReorderBufferProcessTXN().
> I think we should close it, here is a
54 matches
Mail list logo
