Free memory properly in pg_restore.c
Thinko in commit 39729ec01d2. Mea maxima culpa.
Per Mahendra Singh Thalor
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/f09088a01d3372fdfe5da12dd0b2e24989f0caa6
Modified Files
--
src/bin/pg_dump/pg_restore.c | 2
On 2025-04-11 Fr 3:24 PM, Mahendra Singh Thalor wrote:
On Fri, 11 Apr 2025 at 04:38, Andrew Dunstan wrote:
>
> Fix fat fingering in 22cb6d28950
>
> Per Rainier Vilela
>
> Branch
> --
> master
>
> Details
> ---
>
https://git.postgresql.org/pg/commitdiff/39729ec01d25dbe12e0dd8322c68f2426
Doc: do a little copy-editing on Index Storage Parameters list.
Add a paragraph break per suggestion from David G. Johnston.
Use a consistent voice for all the different parameter
descriptions, and fix a couple of grammatical issues.
Reported-by: Igor Korot
Co-authored-by: "David G. Johnston"
C
Peter Geoghegan writes:
> Looks like I'm done with this process, at least until this time next year.
OK. Thanks for taking care of it.
regards, tom lane
On Sat, Apr 12, 2025 at 12:35 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > The first such complaint concerns a new mcxt.c function parameter that
> > shadows a global variable in the same file -- attached patch fixes
> > that by renaming the function parameter. Technically, this is a
> > dist
Peter Geoghegan writes:
> The first such complaint concerns a new mcxt.c function parameter that
> shadows a global variable in the same file -- attached patch fixes
> that by renaming the function parameter. Technically, this is a
> distinct type of complaint to the clang-tidy complaints that I
>
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
Fix GIN's shimTriConsistentFn to not corrupt its input.
Commit 0f21db36d made an assumption that GIN triConsistentFns
would not modify their input entryRes[] arrays. But in fact,
the "shim" triConsistentFn that we use for opclasses that don't
supply their own did exactly that, potentially leading
I just pushed my annual commit that makes function parameter names
consistent between function declarations and their corresponding
definitions, to cover the Postgres 18 cycle. The details there were
all straightforward. But there are 2 remaining complaints from
clang-tidy that seem worth fixing, t
Harmonize function parameter names for Postgres 18.
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in a few places. These
inconsistencies were all introduced during Postgres 18 development.
This commit was written with help fro
14 matches
Mail list logo
