Thank you for your thorough explanation.
On Thu, May 19, 2022 at 5:47 PM Laurenz Albe
wrote:
> On Thu, 2022-05-19 at 15:43 +0200, Koen De Groote wrote:
> > On Thu, May 19, 2022 at 9:10 AM Laurenz Albe
> wrote:
> > > On Wed, 2022-05-18 at 22:51 +0200, Koen De Groote wrote:
> > > > When connectio
On Thu, 2022-05-19 at 15:43 +0200, Koen De Groote wrote:
> On Thu, May 19, 2022 at 9:10 AM Laurenz Albe wrote:
> > On Wed, 2022-05-18 at 22:51 +0200, Koen De Groote wrote:
> > > When connection is gone or blocked, archive_command fails after the
> > > timeout specified
> > > by the NFS mount, as
Hello Laurenz,
Thanks for the reply. That would mean the source code is here:
https://github.com/postgres/postgres/blob/REL_11_0/src/backend/postmaster/pgarch.c
Just to be sure, the "signal" you speak of, this is the result of the
command executed by archive_command?
If my understanding of the c
On Wed, 2022-05-18 at 22:51 +0200, Koen De Groote wrote:
> I've got a setup where archive_command will gzip the wal archive to a
> directory that is itself an NFS mount.
>
> When connection is gone or blocked, archive_command fails after the timeout
> specified by the NFS mount, as expected. (fo
I've got a setup where archive_command will gzip the wal archive to a
directory that is itself an NFS mount.
When connection is gone or blocked, archive_command fails after the timeout
specified by the NFS mount, as expected. (for a soft mount. hard mount
hangs, as expected)
However, on restoring