> On 9 May 2024, at 21:34, Nathan Bossart wrote:
>
> On Thu, May 09, 2024 at 09:03:56AM +0900, Michael Paquier wrote:
>> +1. Could there be an argument in favor of a backpatch? This is a
>> performance improvement, but one could also side that the addition of
>> sync support in pg_dump[all]
On Thu, May 09, 2024 at 09:03:56AM +0900, Michael Paquier wrote:
> +1. Could there be an argument in favor of a backpatch? This is a
> performance improvement, but one could also side that the addition of
> sync support in pg_dump[all] has made that a regression that we'd
> better fix because
On Wed, May 08, 2024 at 02:49:58PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Thanks for looking. I noticed that the version check is unnecessary since
>> we always use the new binary's pg_dump[all], so I removed that in v2.
>
> +1
+1. Could there be an argument in favor of a
Nathan Bossart writes:
> Thanks for looking. I noticed that the version check is unnecessary since
> we always use the new binary's pg_dump[all], so I removed that in v2.
+1
regards, tom lane
On Wed, May 08, 2024 at 10:09:46AM +0200, Peter Eisentraut wrote:
> On 03.05.24 19:13, Nathan Bossart wrote:
>> This is likely small potatoes compared to some of the other
>> pg_upgrade-related improvements I've proposed [0] [1] or plan to propose,
>> but this is easy enough, and I already wrote
On 03.05.24 19:13, Nathan Bossart wrote:
This is likely small potatoes compared to some of the other
pg_upgrade-related improvements I've proposed [0] [1] or plan to propose,
but this is easy enough, and I already wrote the patch, so here it is.
AFAICT there's no reason to bother syncing these
This is likely small potatoes compared to some of the other
pg_upgrade-related improvements I've proposed [0] [1] or plan to propose,
but this is easy enough, and I already wrote the patch, so here it is.
AFAICT there's no reason to bother syncing these dump files to disk. If
someone pulls the
