On Tue, Jun 29, 2021 at 09:10:30AM -0400, Greg Sabino Mullane wrote:
> Looks great, I appreciate the renaming.
Applied, then.
--
Michael
signature.asc
Description: PGP signature
On Tue, Jun 29, 2021 at 2:59 AM Michael Paquier wrote:
> Does that look fine to you?
>
Looks great, I appreciate the renaming.
Cheers,
Greg
On Wed, Jun 23, 2021 at 09:39:37AM +0900, Michael Paquier wrote:
> Perhaps you are right to keep it simple. If people would like to
> document that more precisely, it could always be changed if
> necessary. What you have here sounds pretty much right to me.
So, I was looking at this one today, a
On Fri, Jun 18, 2021 at 08:01:17PM -0400, Greg Sabino Mullane wrote:
> I don't know that we need to bother: the default is already to sync and one
> has to go out of one's way using the -N argument to NOT sync, so I think
> it's a pretty safe assumption to everyone (except those who read my first
>
On Fri, Jun 18, 2021 at 1:57 AM Michael Paquier wrote:
> This doc addition is a bit confusing, as it could mean that each file
> has just one single checksum. We could be more precise, say:
> "When enabling checksums, each relation file block with a changed
> checksum is rewritten in place."
>
On Wed, Jun 02, 2021 at 05:09:36PM -0400, Greg Sabino Mullane wrote:
> Newer version attach that adds a small documentation tweak as well.
- enabling checksums, every file in the cluster is rewritten in-place.
+ enabling checksums, every file in the cluster with a changed checksum is
+ rewri
Newer version attach that adds a small documentation tweak as well.
Cheers,
Greg
pg_checksums.optimize.writes.and.always.sync.patch
Description: Binary data
Fair enough; thanks for the feedback. Attached is a new version that does
an unconditional sync (well, unless do_sync is false, a flag I am not
particularly fond of).
Cheers,
Greg
pg_checksums.optimize.writes.always.sync.patch
Description: Binary data
On Thu, May 27, 2021 at 10:29:14AM -0400, Greg Sabino Mullane wrote:
> I was originally on the fence about including this as well, but it seems
> like since the database is shut down and already in a consistent state,
> there seems no advantage to syncing if we have not made any changes. Things
> a
Thanks for the quick replies, everyone.
On Wed, May 26, 2021 at 10:17 PM Michael Paquier
wrote:
>
> -if (do_sync)
> +if (do_sync && total_files_modified)
> Here, I am on the edge. It could be an advantage to force a flush of
> the data folder anyway, no?
I was originally on the fence
On Wed, May 26, 2021 at 09:29:43PM -0500, Justin Pryzby wrote:
> In one of the checksum patches, there was an understanding that the pages
> should be written even if the checksum is correct, to handle replicas.
>
> From the v19 patch:
> https://www.postgresql.org/message-id/F7AFCFCD-8F77-4546-8D4
In one of the checksum patches, there was an understanding that the pages
should be written even if the checksum is correct, to handle replicas.
>From the v19 patch:
https://www.postgresql.org/message-id/F7AFCFCD-8F77-4546-8D42-C7F675A4B680%40yesql.se
+* Mark the buffer as dirty an
On Wed, May 26, 2021 at 05:23:55PM -0400, Greg Sabino Mullane wrote:
> The attached patch makes an optimization to pg_checksums which prevents
> rewriting the block if the checksum is already what we expect. This can
> lead to much faster runs in cases where it is already set (e.g. enabled ->
> dis
On Thu, May 27, 2021 at 5:24 AM Greg Sabino Mullane wrote:
>
> The attached patch makes an optimization to pg_checksums which prevents
> rewriting the block if the checksum is already what we expect. This can lead
> to much faster runs in cases where it is already set (e.g. enabled ->
> disable
The attached patch makes an optimization to pg_checksums which prevents
rewriting the block if the checksum is already what we expect. This can
lead to much faster runs in cases where it is already set (e.g. enabled ->
disabled -> enable, external helper process, interrupted runs, future
parallel p
15 matches
Mail list logo
