On 2019-07-27 19:02, Sehrope Sarkuni wrote:
> Tried out this patch and it applies, compiles, and passes check-world.
> Also flipped things around in pg_recvlogical.c to exit-on-success to
> ensure it's actually being called and that worked too. Outside of a more
> complicated harness that
On Sat, Jul 27, 2019 at 01:06:06PM -0400, Sehrope Sarkuni wrote:
> While reviewing this patch I read through some of the other fsync
> callsites and noticed this typo (walkdir is in file_utils.c, not
> initdb.c) too:
Thanks, Sehrope. Applied.
--
Michael
signature.asc
Description: PGP signature
While reviewing this patch I read through some of the other fsync
callsites and noticed this typo (walkdir is in file_utils.c, not
initdb.c) too:
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 315c74c745..9b79df2d7f 100644
--- a/src/backend/storage/file/fd.c
+++
Hi,
Tried out this patch and it applies, compiles, and passes check-world. Also
flipped things around in pg_recvlogical.c to exit-on-success to ensure it's
actually being called and that worked too. Outside of a more complicated
harness that simulates fsync errors not sure how else to test this
On Tue, Jun 25, 2019 at 02:23:05PM +0200, Peter Eisentraut wrote:
> Yeah, there is more to do. The reason I'm focusing on these two right
> now is that they would typically run as a background service, and a
> clean exit is most important there. In the other cases, the program
> runs more often
On 2019-03-29 14:05, Michael Paquier wrote:
> Yes, I think that we are going to need an equivalent of that for all
> frontend tools. At various degrees, making sure that a fsync happens
> is also important for pg_dump, pg_basebackup, pg_rewind and
> pg_checksums so it is not only a problem of the
On Fri, Mar 29, 2019 at 12:48:09PM +0100, Peter Eisentraut wrote:
> Do we need to review the fsync error handling in pg_receivewal and
> pg_recvlogical, following the recent backend changes? The current
> default behavior is that these tools will log fsync errors and then
> reconnect
Do we need to review the fsync error handling in pg_receivewal and
pg_recvlogical, following the recent backend changes? The current
default behavior is that these tools will log fsync errors and then
reconnect and proceed with the next data streaming in. As a result, you
might then have some
