On Wed, 24 Nov 2021 at 17:31, Michael Paquier wrote:
> From what I can see, there are two separate problems here:
> - force_parallel_mode = regress.
> - -DRELCACHE_FORCE_RELEASE and/or -DCATCACHE_FORCE_RELEASE.
Thanks. I missed adding keyparamids to the copy/read/write functions.
David
Fix incorrect format placeholders
Also choose better types for the underlying variables to make this
more consistent.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fb5961fd13b1262df280e400645bdf4ed192f058
Modified Files
--
contrib/pageinspect/heapfunc
On Wed, Nov 24, 2021 at 03:18:53PM +1300, David Rowley wrote:
> I'm currently looking into why the buildfarm does not like this.
From what I can see, there are two separate problems here:
- force_parallel_mode = regress.
- -DRELCACHE_FORCE_RELEASE and/or -DCATCACHE_FORCE_RELEASE.
Regards,
--
Mich
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Add support for Visual Studio 2022 in build scripts
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent
Rename SnapBuild* macros in slot.c.
Same macro names for SnapBuildOnDiskNotChecksummedSize and
SnapBuildOnDiskChecksummedSize are being used in slot.c and snapbuild.c.
This patch renames them, in slot.c, to
ReplicationSlotOnDiskNotChecksummedSize and
ReplicationSlotOnDiskChecksummedSize similar to
Revert "Flush Memoize cache when non-key parameters change"
This reverts commit f94edb06ab60545a0e9e90aedc39e3b81b2b9e3f.
Branch
--
REL_14_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7933bc0d13616844ed66271942eac12c3a7f0488
Modified Files
--
src/backend/execu
Revert "Flush Memoize cache when non-key parameters change"
This reverts commit 1050048a315790a505465bfcceb26eaf8dbc7e2e.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/dad20ad4709f602b4827a1ab2b0e715f36c548c3
Modified Files
--
src/backend/executor/nod
On Wed, 24 Nov 2021 at 14:57, David Rowley wrote:
> Flush Memoize cache when non-key parameters change
I'm currently looking into why the buildfarm does not like this.
David
Flush Memoize cache when non-key parameters change
It's possible that a subplan below a Memoize node contains a parameter
from above the Memoize node. If this parameter changes then cache entries
may become out-dated due to the new parameter value.
Previously Memoize was mistakenly not aware of
Flush Memoize cache when non-key parameters change
It's possible that a subplan below a Memoize node contains a parameter
from above the Memoize node. If this parameter changes then cache entries
may become out-dated due to the new parameter value.
Previously Memoize was mistakenly not aware of
Allow Memoize to operate in binary comparison mode
Memoize would always use the hash equality operator for the cache key
types to determine if the current set of parameters were the same as some
previously cached set. Certain types such as floating points where -0.0
and +0.0 differ in their binar
Allow Memoize to operate in binary comparison mode
Memoize would always use the hash equality operator for the cache key
types to determine if the current set of parameters were the same as some
previously cached set. Certain types such as floating points where -0.0
and +0.0 differ in their binar
Add SQL functions to monitor the directory contents of replication slots
This commit adds a set of functions able to look at the contents of
various paths related to replication slots:
- pg_ls_logicalsnapdir, for pg_logical/snapshots/
- pg_ls_logicalmapdir, for pg_logical/mappings/
- pg_ls_replslo
18 matches
Mail list logo
