public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v3 3/3] Fix sizing of tape read buffers. 2+ messages / 2 participants [nested] [flat]
* [PATCH v3 3/3] Fix sizing of tape read buffers. @ 2021-01-22 20:59 Heikki Linnakangas <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Heikki Linnakangas @ 2021-01-22 20:59 UTC (permalink / raw) --- src/backend/utils/sort/tuplesort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c index 14104643e78..aff2f201f52 100644 --- a/src/backend/utils/sort/tuplesort.c +++ b/src/backend/utils/sort/tuplesort.c @@ -2658,7 +2658,7 @@ merge_read_buffer_size(int64 avail_mem, int nInputTapes, int nInputRuns, * we derive the input buffer size from the amount of memory available, * and M and N. */ - return (avail_mem - TAPE_BUFFER_OVERHEAD * nOutputTapes) / nInputTapes; + return Max((avail_mem - TAPE_BUFFER_OVERHEAD * nOutputTapes) / nInputTapes, 0); } /* -- 2.29.2 --------------631E0A48DCAEA386819DFCEC-- ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Use of backup_label not noted in log @ 2023-11-18 13:26 David Steele <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: David Steele @ 2023-11-18 13:26 UTC (permalink / raw) To: Andres Freund <[email protected]>; pgsql-hackers; Michael Paquier <[email protected]> On 11/17/23 00:18, Andres Freund wrote: > > I've often had to analyze what caused corruption in PG instances, where the > symptoms match not having had backup_label in place when bringing on the > node. However that's surprisingly hard - the only log messages that indicate > use of backup_label are at DEBUG1. > > Given how crucial use of backup_label is and how frequently people do get it > wrong, I think we should add a LOG message - it's not like use of backup_label > is a frequent thing in the life of a postgres instance and is going to swamp > the log. And I think we should backpatch that addition. +1 for the message and I think a backpatch is fine as long as it is a new message. If monitoring systems can't handle an unrecognized message then that feels like a problem on their part. > Medium term I think we should go further, and leave evidence in pg_control > about the last use of ControlFile->backupStartPoint, instead of resetting it. Michael also thinks this is a good idea. > I realize that there's a discussion about removing backup_label - but I think > that's fairly orthogonal. Should we go with the pg_control approach, we should > still emit a useful message when starting in a state that's "equivalent" to > having used the backup_label. Agreed, this new message could easily be adapted to the recovery in pg_control patch. Regards, -David ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2023-11-18 13:26 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-22 20:59 [PATCH v3 3/3] Fix sizing of tape read buffers. Heikki Linnakangas <[email protected]> 2023-11-18 13:26 Re: Use of backup_label not noted in log David Steele <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox