At Fri, 21 Jun 2024 11:48:22 +0530, Amit Kapila wrote
in
> On Wed, Jun 19, 2024 at 10:44 AM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > Dear Horiguchi-san,
> >
> > Thanks for sharing the patch! I agree this approach (ensure WAL records are
> > flushed)
> > Is more proper than others.
> >
> > I
On Wed, Jun 19, 2024 at 10:44 AM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Horiguchi-san,
>
> Thanks for sharing the patch! I agree this approach (ensure WAL records are
> flushed)
> Is more proper than others.
>
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
>
On Wed, Jun 19, 2024 at 05:14:50AM +, Hayato Kuroda (Fujitsu) wrote:
> I have an unclear point. According to the comment atop GetInsertRecPtr(), it
> just
> returns the approximated value - the position of the last full WAL page [1].
> If there is a continuation WAL record which across a
FYI - I applied this latest patch and re-ran the original failing test
script 10 times (e.g. 10 x 100 test iterations; it took 4+ hours).
There were zero failures observed in my environment.
==
Kind Regards,
Peter Smith.
Fujitsu Australia
Dear Horiguchi-san,
Thanks for sharing the patch! I agree this approach (ensure WAL records are
flushed)
Is more proper than others.
I have an unclear point. According to the comment atop GetInsertRecPtr(), it
just
returns the approximated value - the position of the last full WAL page [1].
If
At Thu, 13 Jun 2024 09:29:03 +0530, Amit Kapila wrote
in
> Yeah, but the commit you quoted later reverted by commit 703f148e98
> and committed again as c6c3334364.
Yeah, right..
> > aiming to prevent walsenders from
> > generating competing WAL (by, for example, CREATE_REPLICATION_SLOT)
> >
On Wed, Jun 12, 2024 at 6:43 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 11 Jun 2024 14:27:28 +0530, Amit Kapila
> wrote in
> > On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> > > wrote in
> > > > Sorry, it is not clear
At Tue, 11 Jun 2024 14:27:28 +0530, Amit Kapila wrote
in
> On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> > wrote in
> > > Sorry, it is not clear to me why we failed to flush the last
> > > continuation record in logical
On Tue, Jun 11, 2024 at 12:34 PM Kyotaro Horiguchi
wrote:
>
> At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila
> wrote in
> > Sorry, it is not clear to me why we failed to flush the last
> > continuation record in logical walsender? I see that we try to flush
> > the WAL after receiving
At Tue, 11 Jun 2024 09:27:20 +0900, Michael Paquier wrote
in
> On Thu, Jun 06, 2024 at 03:19:20PM +0900, Kyotaro Horiguchi wrote:
> > So, I believe the attached small patch fixes the behavior. I haven't
> > come up with a good test script for this issue. Something like
> >
At Tue, 11 Jun 2024 11:32:12 +0530, Amit Kapila wrote
in
> Sorry, it is not clear to me why we failed to flush the last
> continuation record in logical walsender? I see that we try to flush
> the WAL after receiving got_STOPPING in WalSndWaitForWal(), why is
> that not sufficient?
It seems
On Thu, Jun 6, 2024 at 11:49 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith wrote
> in
> > Hi, I have reproduced this multiple times now.
> >
> > I confirmed the initial post/steps from Alexander. i.e. The test
> > script provided [1] gets itself into a state
On Thu, Jun 06, 2024 at 03:19:20PM +0900, Kyotaro Horiguchi wrote:
> During server shutdown, the latter half of the last continuation
> record may fail to be flushed. This is similar to what is described in
> the commit message of commit ff9f111bce. While shutting down,
> WalSndLoop() waits for
On Mon, 10 Jun 2024 at 15:10, Shlok Kyal wrote:
>
> On Thu, 6 Jun 2024 at 11:49, Kyotaro Horiguchi
> wrote:
> >
> > At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith
> > wrote in
> > > Hi, I have reproduced this multiple times now.
> > >
> > > I confirmed the initial post/steps from Alexander.
On Thu, 6 Jun 2024 at 11:49, Kyotaro Horiguchi wrote:
>
> At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith wrote
> in
> > Hi, I have reproduced this multiple times now.
> >
> > I confirmed the initial post/steps from Alexander. i.e. The test
> > script provided [1] gets itself into a state where
At Thu, 6 Jun 2024 12:49:45 +1000, Peter Smith wrote in
> Hi, I have reproduced this multiple times now.
>
> I confirmed the initial post/steps from Alexander. i.e. The test
> script provided [1] gets itself into a state where function
> ReadPageInternal (called by XLogDecodeNextRecord and
On Wed, May 29, 2024 at 9:00 PM Alexander Lakhin wrote:
>
> Hello hackers,
>
> As a recent buildfarm test failure [1] shows:
> [14:33:02.374](0.333s) ok 23 - update works with dropped subscriber column
> ### Stopping node "publisher" using mode fast
> # Running: pg_ctl -D
>
On Thu, May 30, 2024 at 2:09 AM vignesh C wrote:
>
> On Wed, 29 May 2024 at 16:30, Alexander Lakhin wrote:
> >
> > Hello hackers,
> >
> > As a recent buildfarm test failure [1] shows:
> > [14:33:02.374](0.333s) ok 23 - update works with dropped subscriber column
> > ### Stopping node "publisher"
On Wed, 29 May 2024 at 16:30, Alexander Lakhin wrote:
>
> Hello hackers,
>
> As a recent buildfarm test failure [1] shows:
> [14:33:02.374](0.333s) ok 23 - update works with dropped subscriber column
> ### Stopping node "publisher" using mode fast
> # Running: pg_ctl -D
>
Hello hackers,
As a recent buildfarm test failure [1] shows:
[14:33:02.374](0.333s) ok 23 - update works with dropped subscriber column
### Stopping node "publisher" using mode fast
# Running: pg_ctl -D
20 matches
Mail list logo
