On Tue, Oct 26, 2021 at 11:23:04AM +0900, Kyotaro Horiguchi wrote:
> I noticed a typo in the change.
>
> + If a starting point cannot not be calculated with the previous method,
>
> The "not" is a duplicate.
Fixed, thanks.
--
Michael
signature.asc
Description: PGP signature
doc: Fix grammar in page of pg_receivewal
Introduced by f61e1dd.
Author: Kyotaro Horiguchi
Discussion:
https://postgr.es/m/20211026.112304.1962954080884317968.horikyota@gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8af09daf5629e9b85f37cc23983819b8c
Revert "Remove unused wait events."
This reverts commit 671eb8f34404d24c8f16ae40e94becb38afd93bb. The removed
wait events are used by some extensions and removal of these would force a
recompile of those extensions. We don't want that for released branches.
Discussion: https://postgr.es/m/e1mdoby
At Tue, 26 Oct 2021 00:47:44 +, Michael Paquier wrote
in
> Allow pg_receivewal to stream from a slot's restart LSN
...
> Details
> ---
> https://git.postgresql.org/pg/commitdiff/f61e1dd2cee6b1a1da75c2bb0ca3bc72f18748c1
Ouch.. sorry, it's a bit late.
I noticed a typo in the change.
+
Fix overly-lax regex pattern in TAP test of READ_REPLICATION_SLOT
The case checking for a NULL output when a slot does not exist was
too lax, as it was passing for any output generated by the query. This
fixes the matching pattern to be what it should be, matching only on
"||".
Oversight in b4ad
Allow pg_receivewal to stream from a slot's restart LSN
Prior to this patch, when running pg_receivewal, the streaming start
point would be the current location of the archives if anything is
found in the local directory where WAL segments are written, and
pg_receivewal would fall back to the curr
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
https://postgr.es/m/163271880203.22789.1125998876173795...@wrigl
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
https://postgr.es/m/163271880203.22789.1125998876173795...@wrigl
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
https://postgr.es/m/163271880203.22789.1125998876173795...@wrigl
Reject huge_pages=on if shared_memory_type=sysv.
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion:
https://postgr.es/m/163271880203.22789.1125998876173795...@wrigl
Initialize variable to placate compiler.
Per Nathan Bossart.
Discussion: http://postgr.es/m/fecee7fc-cb74-45a9-bb24-89fee52a9...@amazon.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a030a0c5ccb113ccd09d0f0b82f1edb5e49ed607
Modified Files
--
src/b
Report progress of startup operations that take a long time.
Users sometimes get concerned whe they start the server and it
emits a few messages and then doesn't emit any more messages for
a long time. Generally, what's happening is either that the
system is taking a long time to apply WAL, or it'
Add enable_timeout_every() to fire the same timeout repeatedly.
enable_timeout_at() and enable_timeout_after() can still be used
when you want to fire a timeout just once.
Patch by me, per a suggestion from Tom Lane.
Discussion: http://postgr.es/m/2992585.1632938...@sss.pgh.pa.us
Discussion:
ht
Remove useless code from CreateReplicationSlot.
According to the comments, we initialize sendTimeLineIsHistoric
and sendTimeLine here for the benefit of WalSndSegmentOpen.
However, the only way that can happen is if logical_read_xlog_page
calls WALRead. And since logical_read_xlog_page initializes
StartupXLOG: Call CleanupAfterArchiveRecovery after XLogReportParameters.
This does a better job grouping related operations together, since
all of the WAL records that we need to write prior to allowing WAL
writes generally and written by a single uninterrupted stretch of code.
Since CleanupAfte
StartupXLOG: Don't repeatedly disable/enable local xlog insertion.
All the code that runs in the startup process to write WAL records
before that's allowed generally is now consecutive, so there's no
reason to shut the facility to write WAL locally off and then turn
it on again three times in a ro
16 matches
Mail list logo
