Fix pg_isblank()
There was a pg_isblank() function that claimed to be a replacement for
the standard isblank() function, which was thought to be "not very
portable yet". We can now assume that it's portable (it's in C99).
But pg_isblank() actually diverged from the standard isblank() by also
acc
Add slotsync_skip_reason column to pg_replication_slots view.
Introduce a new column, slotsync_skip_reason, in the pg_replication_slots
view. This column records the reason why the last slot synchronization was
skipped. It is primarily relevant for logical replication slots on standby
servers wher
pg_buffercache: Add pg_buffercache_mark_dirty{,_relation,_all}()
This commit introduces three new functions for marking shared buffers as
dirty by using the functions introduced in 9660906dbd69:
* pg_buffercache_mark_dirty() for one shared buffer.
- pg_buffercache_mark_dirt_relation() for all the
Fix possibly uninitialized HeapScanDesc.rs_startblock
The solution used in 0ca3b1697 to determine the Parallel TID Range
Scan's start location was to modify the signature of
table_block_parallelscan_startblock_init() to allow the startblock
to be passed in as a parameter. This allows the scan lim
doc: Add missing tags in pg_buffercache page
Issue noticed while looking at this area of the documentation, for a
different patch. This is a matter of style, so no backpatch is done.
Discussion:
https://postgr.es/m/can55fz0h_yosqqutxv6des1rw8ig6wca8cr9rjk358yrmxz...@mail.gmail.com
Branch
-
Add routines for marking buffers dirty efficiently
This commit introduces new internal bufmgr routines for marking shared
buffers as dirty:
* MarkDirtyUnpinnedBuffer()
* MarkDirtyRelUnpinnedBuffers()
* MarkDirtyAllUnpinnedBuffers()
These functions provide an efficient mechanism to respectively ma
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
Allow indexscans on partial hash indexes with implied quals.
Normally, if a WHERE clause is implied by the predicate of a partial
index, we drop that clause from the set of quals used with the index,
since it's redundant to test it if we're scanning that index.
However, if it's a hash index (or an
doc: Fix misleading synopsis for CREATE/ALTER PUBLICATION.
The documentation for CREATE/ALTER PUBLICATION previously showed:
[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expression ) ] [, ... ]
to indicate that the table/column specification could be repeated.
Howeve
doc: Fix misleading synopsis for CREATE/ALTER PUBLICATION.
The documentation for CREATE/ALTER PUBLICATION previously showed:
[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expression ) ] [, ... ]
to indicate that the table/column specification could be repeated.
Howeve
doc: Fix misleading synopsis for CREATE/ALTER PUBLICATION.
The documentation for CREATE/ALTER PUBLICATION previously showed:
[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expression ) ] [, ... ]
to indicate that the table/column specification could be repeated.
Howeve
doc: Fix misleading synopsis for CREATE/ALTER PUBLICATION.
The documentation for CREATE/ALTER PUBLICATION previously showed:
[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expression ) ] [, ... ]
to indicate that the table/column specification could be repeated.
Howeve
doc: Fix misleading synopsis for CREATE/ALTER PUBLICATION.
The documentation for CREATE/ALTER PUBLICATION previously showed:
[ ONLY ] table_name [ * ] [ ( column_name [, ... ] ) ] [ WHERE (
expression ) ] [, ... ]
to indicate that the table/column specification could be repeated.
Howeve
Fix new test for CATCACHE_FORCE_RELEASE builds
Two of the isolation tests introduce by commit bc32a12e0db2 had a
problem under CATCACHE_FORCE_RELEASE, as evidenced by buildfarm member
prion. An injection point is hit ahead of what the test spec expects,
so a session goes to sleep and there's no o
doc: Fix typo in pg_dump documentation
Reported-by: Erik Rijkers
Reviewed-by: Chao Li
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/e396a18f32e1a174be2492a83e7a8bfce568e6ab
Modified
19 matches
Mail list logo
