On Tue, Aug 31, 2021 at 6:13 PM Ajin Cherian wrote:
>
> On Tue, Aug 31, 2021 at 3:47 PM Masahiko Sawada wrote:
>
> Thanks Masahiko-san. I have included this change and made a new patch-set.
>
> Hi Amit,
>
> I have included your comments as well and also attached the patches
> for the
On Tue, Aug 31, 2021 at 3:47 PM Masahiko Sawada wrote:
>
> On Tue, Aug 31, 2021 at 12:11 PM Amit Kapila wrote:
> >
> > On Mon, Aug 30, 2021 at 5:48 PM Ajin Cherian wrote:
> > >
> > > On Mon, Aug 30, 2021 at 7:52 PM Amit Kapila
> > > wrote:
> > >
> > > I have made the above changes on HEAD.
>
On Tue, Aug 31, 2021 at 12:11 PM Amit Kapila wrote:
>
> On Mon, Aug 30, 2021 at 5:48 PM Ajin Cherian wrote:
> >
> > On Mon, Aug 30, 2021 at 7:52 PM Amit Kapila wrote:
> >
> > I have made the above changes on HEAD.
> >
>
> Thanks, this looks mostly good to me. I'll push and backpatch this
>
On Mon, Aug 30, 2021 at 5:48 PM Ajin Cherian wrote:
>
> On Mon, Aug 30, 2021 at 7:52 PM Amit Kapila wrote:
>
> I have made the above changes on HEAD.
>
Thanks, this looks mostly good to me. I'll push and backpatch this
tomorrow unless you or someone else thinks otherwise.
Minor comments
On Mon, Aug 30, 2021 at 7:52 PM Amit Kapila wrote:
> Isn't it better to check the streaming state when we are fetching
> oldpid? If we don't add, then I suspect that the next time someone
> adding tests on similar lines might get confused about where to check
> the state and where not. Also, if
On Fri, Aug 27, 2021 at 4:33 PM Ajin Cherian wrote:
>
> On Fri, Aug 27, 2021 at 3:29 PM Amit Kapila wrote:
> >
> >
> > I think the fix is correct but similar changes are required in
> > 022_twophase_cascade.pl as well (search for $oldpid in tests). I am
> > not completely sure but I think it is
On Fri, Aug 27, 2021 at 3:29 PM Amit Kapila wrote:
>
>
> I think the fix is correct but similar changes are required in
> 022_twophase_cascade.pl as well (search for $oldpid in tests). I am
> not completely sure but I think it is better to make this test change
> in back branches as well to make
On Thu, Aug 26, 2021 at 4:28 PM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 2:45 PM Masahiko Sawada wrote:
>
> Attaching a patch on head that modifies this particular script to also
> consider the state of the walsender.
>
I think the fix is correct but similar changes are required in
On Thu, Aug 26, 2021 at 2:45 PM Masahiko Sawada wrote:
> I think that it’s possible that the orders of the process writing
> disconnections logs and setting 0 to walsender's pid are mismatched.
> We set 0 to walsender's pid in WalSndKill() that is called during
> on_shmem_exit callback. Once we
On Thu, Aug 26, 2021 at 12:59 PM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 1:54 PM Amit Kapila wrote:
> >
> > On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
> > >
> > > On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila
> > > wrote:
> > >
> > > >
> > > > You have a point but if we see the
On Thu, Aug 26, 2021 at 1:54 PM Amit Kapila wrote:
>
> On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
> >
> > On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
> >
> > >
> > > You have a point but if we see the below logs, it seems the second
> > > walsender (#step6) seemed to exited
On Thu, Aug 26, 2021 at 9:21 AM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
>
> >
> > You have a point but if we see the below logs, it seems the second
> > walsender (#step6) seemed to exited before the first walsender
> > (#step4).
> >
> > 2021-08-15 18:44:38.041
On Thu, Aug 26, 2021 at 1:06 PM Amit Kapila wrote:
>
> You have a point but if we see the below logs, it seems the second
> walsender (#step6) seemed to exited before the first walsender
> (#step4).
>
> 2021-08-15 18:44:38.041 CEST [16475:10] tap_sub LOG: disconnection:
> session time:
On Thu, Aug 26, 2021 at 7:38 AM Ajin Cherian wrote:
>
> On Thu, Aug 26, 2021 at 11:02 AM Masahiko Sawada
> wrote:
> >
>
> Luckily these logs have the disconnection times of the tap test client
> sessions as well. (not sure why I don't see these when I run these
> tests).
>
> Step 5 could have
On Thu, Aug 26, 2021 at 11:02 AM Masahiko Sawada wrote:
>
> On Wed, Aug 25, 2021 at 11:04 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila
> > wrote:
> > >
> > > On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > I did a quick check with
On Wed, Aug 25, 2021 at 11:04 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila wrote:
> >
> > On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada
> > wrote:
> > >
> > > I did a quick check with the following tap test code:
> > >
> > >
On Wed, Aug 25, 2021 at 11:17 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada wrote:
> >
> > I did a quick check with the following tap test code:
> >
> > $node_publisher->poll_query_until('postgres',
> > qq(
> > select 1 != foo.column1
On Wed, Aug 25, 2021 at 6:10 PM Masahiko Sawada wrote:
>
> I did a quick check with the following tap test code:
>
> $node_publisher->poll_query_until('postgres',
> qq(
> select 1 != foo.column1 from (values(0), (1)) as foo;
> ));
>
> The query returns {t, f} but
On Wed, Aug 25, 2021 at 5:54 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 9:32 PM Masahiko Sawada wrote:
>
> >
> > IIUC the query[1] used for polling returns two rows in this case: {t,
> > f} or {f, t}. But did poll_query_until() returned OK in this case even
> > if we expected one row of
On Wed, Aug 25, 2021 at 9:23 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 5:02 PM Masahiko Sawada wrote:
> >
> > On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
> > >
> > > On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila
On Wed, Aug 25, 2021 at 9:32 PM Masahiko Sawada wrote:
>
> IIUC the query[1] used for polling returns two rows in this case: {t,
> f} or {f, t}. But did poll_query_until() returned OK in this case even
> if we expected one row of 't'? My guess of how this issue happened is:
>
> 1. the first
On Wed, Aug 25, 2021 at 5:02 PM Masahiko Sawada wrote:
>
> On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> > >
> > > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Wed, Aug 25, 2021 at 8:00 AM Ajin
On Wed, Aug 25, 2021 at 6:53 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
> >
> > On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
> > >
> > > On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> > > >
> > > > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
On Wed, Aug 25, 2021 at 5:43 PM Ajin Cherian wrote:
>
> On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
> >
> > On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> > >
> > > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
> > > wrote:
> > >
> > > > But will poll function still poll or exit?
On Wed, Aug 25, 2021 at 4:22 PM Amit Kapila wrote:
>
> On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
> >
> > On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila
> > wrote:
> >
> > > But will poll function still poll or exit? Have you tried that?
> >
> > I have forced that condition with a
On Wed, Aug 25, 2021 at 8:00 AM Ajin Cherian wrote:
>
> On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila wrote:
>
> > But will poll function still poll or exit? Have you tried that?
>
> I have forced that condition with a changed query and found that the
> poll will not exit in case of a NULL
On Tue, Aug 24, 2021 at 11:12 PM Amit Kapila wrote:
> But will poll function still poll or exit? Have you tried that?
I have forced that condition with a changed query and found that the
poll will not exit in case of a NULL return.
> Because it is not clear from your explanation how in the
On Tue, Aug 24, 2021 at 6:28 PM Ajin Cherian wrote:
>
> On Tue, Aug 24, 2021 at 9:08 PM Amit Kapila wrote:
>
> > What happens when there is neither a new walsender nor an old
> > walsender is present? It means to run the above statement when a new
> > walsender is exited due to error "... slot
On Tue, Aug 24, 2021 at 9:08 PM Amit Kapila wrote:
> What happens when there is neither a new walsender nor an old
> walsender is present? It means to run the above statement when a new
> walsender is exited due to error "... slot is active ..." and before a
> new walsender could start. Also,
On Tue, Aug 24, 2021 at 11:04 AM Ajin Cherian wrote:
>
> On Mon, Aug 16, 2021 at 6:33 PM Amit Kapila wrote:
>
> > The "ALTER SUBSCRIPTION tap_sub CONNECTION" would lead to restart the
> > walsender process. Now, here the problem seems to be that the previous
> > walsender process (16336) didn't
On Mon, Aug 16, 2021 at 6:33 PM Amit Kapila wrote:
> The "ALTER SUBSCRIPTION tap_sub CONNECTION" would lead to restart the
> walsender process. Now, here the problem seems to be that the previous
> walsender process (16336) didn't exit and the new process started to
> use the slot which leads to
On Mon, Aug 16, 2021 at 9:24 AM Michael Paquier wrote:
>
> Hi all,
>
> topminnow has just failed in a weird fashion:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=topminnow=2021-08-15%2013%3A24%3A58
> # SELECT pid != FROM pg_stat_replication WHERE application_name = 'tap_sub';
> #
Hi all,
topminnow has just failed in a weird fashion:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=topminnow=2021-08-15%2013%3A24%3A58
# SELECT pid != FROM pg_stat_replication WHERE application_name = 'tap_sub';
# expecting this output:
# t
# last actual query output:
#
# with stderr:
33 matches
Mail list logo
