Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b6c994af1f0d42f839df214
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b43cf1dcded905abeceefc7
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/82784f088986140bc08ab22
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ee80124811908ef1d4679296c46e36
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/777192f0dd444d68a95ed9d
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0dfaf8f763ae66eca841366
Mention ownership requirements for REFRESH MATERIALIZED VIEW in docs
Author: Dian Fay
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.3
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/86e873c01650a0d3cd605e8
Proof-reading for documentation.
Somebody accidentally a word. Back-patch to 9.6.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/dedc6a2bb15d1b62485840ad87190
Proof-reading for documentation.
Somebody accidentally a word. Back-patch to 9.6.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/96e98fa2606b2b12805db99196f468152312
Proof-reading for documentation.
Somebody accidentally a word. Back-patch to 9.6.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/3fe8c13a31bcdd0220c0c0891c2a1
Proof-reading for documentation.
Somebody accidentally a word. Back-patch to 9.6.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180816195431.GA23707%40telsasoft.com
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/07b895aef764fe528af57f04d4543
Remove unused configure test for ldopen()
unused since f2cc453dd7e87e800a62a173dea0353bf106668d
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/9d0aa4f4d22a4feddbf7c05308fe32b32d14c13f
Modified Files
--
configure| 61
Remove remaining GEODEBUG references from geo_ops.c
Commit a7dc63d904a6044d299aebdf59ad3199b6a9e99d removed most of the
GEODEBUG occurrences, but there were a couple remaining. So remove
them too, to get rid of the macro entirely.
Author: Emre Hasegeli
Discussion:
https://www.postgresql.org/mes
Use the built-in float datatypes to implement geometric types
This patch makes the geometric operators and functions use the exported
function of the float4/float8 datatypes. The main reason of doing so is
to check for underflow and overflow, and to handle NaNs consciously.
The float datatypes c
Require a C99-compliant snprintf(), and remove related workarounds.
Since our substitute snprintf now returns a C99-compliant result,
there's no need anymore to have complicated code to cope with pre-C99
behavior. We can just make configure substitute snprintf.c if it finds
that the system snprin
Fix executor prune failure when plan already pruned
In a multi-layer partitioning setup, if at plan time all the
sub-partitions are pruned but the intermediate one remains, the executor
later throws a spurious error that there's nothing to prune. That is
correct, but there's no reason to throw an
Fix executor prune failure when plan already pruned
In a multi-layer partitioning setup, if at plan time all the
sub-partitions are pruned but the intermediate one remains, the executor
later throws a spurious error that there's nothing to prune. That is
correct, but there's no reason to throw an
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Close the file descriptor in ApplyLogicalMappingFile
The function was forgetting to close the file descriptor, resulting
in failures like this:
ERROR: 53000: exceeded maxAllocatedDescs (492) while trying to open
file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION: Op
Try to enable C99 in configure, but do not rely on it (yet).
Based on recent discussion it seems possible that we might start to
rely on more of C99. A prerequisite for that is enabling support for
that on used compilers.
Let's see on which buildfarm members autoconf's AC_PROG_CC_C99() is
suffici
Update comment in header of errcodes.txt
This file mentions all the files generated from it, but missed that
errcodes-list.sgml is no more, while errcodes-table.sgml is.
Author: Noriyoshi Shinoda
Discussion:
https://postgr.es/m/tu4pr8401mb0430855d6b971e49eb55f328ee...@tu4pr8401mb0430.namprd84.pr
25 matches
Mail list logo
