Use correct connection name variable in ecpglib.
Fixed-by: Kuroda-san
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c21d6033f77353623f8642c5541e0d002d986f59
Modified Files
--
src/interfaces/ecpg/ecpglib/prepare.c | 2 +-
1 file changed, 1 insertion(+)
On Fri, Mar 15, 2019 at 10:09:57AM -0400, Robert Haas wrote:
> OK. My other gripe with this commit message is that it doesn't
> actually explain what problem was being fixed. You explain that it's
> wrong, and you explain why fixing it is not a big deal, but you never
> quite say what you're actu
Improve code comments in b0eaa4c51b.
Author: John Naylor
Discussion:
https://postgr.es/m/CACPNZCswjyGJxTT=mxHgK=Z=mJ9uJ4WEx_UO=bnwpr_i0ea...@mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/06c8a5090ed9ec188557a86d4de11384f5128ec0
Modified Files
Further reduce memory footprint of CLOBBER_CACHE_ALWAYS testing.
Some buildfarm members using CLOBBER_CACHE_ALWAYS have been having OOM
problems of late. Commit 2455ab488 addressed this problem by recovering
space transiently used within RelationBuildPartitionDesc, but it turns
out that leaves qu
On Thu, Mar 14, 2019 at 8:54 PM Michael Paquier wrote:
> My apologies for the confusion. It looks like there is a lot of
> Frenglish power in that. What I meant is "faire face", so it would
> have been better to use "facing", "scanning" or "finding".
OK. My other gripe with this commit message
PL/Tcl: Improve trigger tests organization
The trigger tests for PL/Tcl were spread aroud pltcl_setup.sql and
pltcl_queries.sql, mixed with other tests, which makes them hard to
follow and edit. Move all the trigger-related pieces to a new file
pltcl_trigger.sql. This also makes the test setup m
Add walreceiver API to get remote server version
Add a separate walreceiver API function walrcv_server_version() to get
the version of the remote server, instead of doing it as part of
walrcv_identify_system(). This allows the server version to be
available even for uses that don't call IDENTIFY_
Fix volatile vs. pointer confusion
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* w
Fix volatile vs. pointer confusion
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* w
Fix volatile vs. pointer confusion
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* w
Fix volatile vs. pointer confusion
Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* w
Fix typo related to to_tsvector() in tests of json and jsonb
Author: Sho Kato
Reviewed-by: Kyotaro Horiguchi
Discussion:
https://postgr.es/m/25C1C6B2E7BE044889E4FE8643A58BA963E1D03D@G01JPEXMBKW03
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4e197bf19556a1699b0e1
12 matches
Mail list logo
