At Mon, 29 Mar 2021 11:41:32 -0400, Stephen Frost wrote in
> Greetings,
>
> * Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > At Mon, 29 Mar 2021 14:47:33 +0900, Michael Paquier
> > wrote in
> > > On Fri, Mar 26, 2021 at 10:16:40AM -0700, Andres Freund wrote:
> > > > On 2021-03-26 18:2
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Mon, 29 Mar 2021 14:47:33 +0900, Michael Paquier
> wrote in
> > On Fri, Mar 26, 2021 at 10:16:40AM -0700, Andres Freund wrote:
> > > On 2021-03-26 18:20:14 +0900, Kyotaro Horiguchi wrote:
> > > > This is because XLogSendPhysic
At Mon, 29 Mar 2021 14:47:33 +0900, Michael Paquier wrote
in
> On Fri, Mar 26, 2021 at 10:16:40AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2021-03-26 18:20:14 +0900, Kyotaro Horiguchi wrote:
> > > This is because XLogSendPhysical detects removal of the wal segment
> > > currently reading
On Fri, Mar 26, 2021 at 10:16:40AM -0700, Andres Freund wrote:
> Hi,
>
> On 2021-03-26 18:20:14 +0900, Kyotaro Horiguchi wrote:
> > This is because XLogSendPhysical detects removal of the wal segment
> > currently reading by shutdown checkpoint. However, there' no fear of
> > overwriting of WAL s
Hi,
On 2021-03-26 18:20:14 +0900, Kyotaro Horiguchi wrote:
> This is because XLogSendPhysical detects removal of the wal segment
> currently reading by shutdown checkpoint. However, there' no fear of
> overwriting of WAL segments at the time.
>
> So I think we can omit the call to CheckXLogRemove
Hello, I happened to see a doubious behavior of walsender.
On a replication set with wal_keep_size/(segments) = 0, running the
following command on the primary causes walsender to fail to send up
to the final shutdown checkpoint record to the standby.
(create table t in advance)
psql -c 'insert
