Fix thinko in allocation call during MVC list deserialization
Spotted by Coverity.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4ae7f02b0364ccba49a82efbfff46125fb357d6c
Modified Files
--
src/backend/statistics/mcv.c | 2 +-
1 file changed, 1
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
Update HINT for pre-existing shared memory block.
One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is
tableam: sample scan.
This moves sample scan support to below tableam. It's not optional as
there is, in contrast to e.g. bitmap heap scans, no alternative way to
perform tablesample queries. If an AM can't deal with the block based
API, it will have to throw an ERROR.
The tableam callbacks for
tableam: bitmap table scan.
This moves bitmap heap scan support to below an optional tableam
callback. It's optional as the whole concept of bitmap heapscans is
fairly block specific.
This basically moves the work previously done in bitgetpage() into the
new scan_bitmap_next_block callback, and
tableam: Formatting and other minor cleanups.
The superflous heapam_xlog.h includes were reported by Peter
Geoghegan.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4bb50236eb561f4639e75a393a5a1c9b8681acfb
Modified Files
--
Fix nbtree high key "continuescan" row compare bug.
Commit 29b64d1d mishandled skipping over truncated high key attributes
during row comparisons. The row comparison key matching loop would loop
forever when a truncated attribute was encountered for a row compare
subkey. Fix by following the
Add test case exercising formerly-unreached code in inheritance_planner.
There was some debate about whether the code I'd added to remap
AppendRelInfos obtained from the initial SELECT planning run is
actually necessary. Add a test case demonstrating that it is.
Discussion:
Compute root->qual_security_level in a less random place.
We can set this up once and for all in subquery_planner's initial survey
of the flattened rangetable, rather than incrementally adjusting it in
build_simple_rel. The previous approach made it rather hard to reason
about exactly when the
Skip redundant anti-wraparound vacuums
An anti-wraparound vacuum has to be by definition aggressive as it needs
to work on all the pages of a relation. However it can happen that due
to some concurrent activity an anti-wraparound vacuum is marked as
non-aggressive, which makes it redundant with
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion:
https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f...@2ndquadrant.com
Branch
--
REL_11_STABLE
Details
---
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion:
https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f...@2ndquadrant.com
Branch
--
REL9_6_STABLE
Details
---
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion:
https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f...@2ndquadrant.com
Branch
--
master
Details
---
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion:
https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f...@2ndquadrant.com
Branch
--
REL9_5_STABLE
Details
---
Have pg_upgrade's Makefile honor NO_TEMP_INSTALL
Backpatch to 9.5, when pg_upgrade's location changed.
Discussion:
https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f...@2ndquadrant.com
Branch
--
REL_10_STABLE
Details
---
19 matches
Mail list logo
