Re: [COMMITTERS] pgsql: Log diagnostic messages if errors occur during LDAP auth.

Peter Eisentraut writes: > Log diagnostic messages if errors occur during LDAP auth. Buildfarm doesn't seem real happy with this ... regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your

[COMMITTERS] pgsql: Attempt to fix LDAP build

Attempt to fix LDAP build Apparently, an older spelling of LDAP_OPT_DIAGNOSTIC_MESSAGE is LDAP_OPT_ERROR_STRING, so fall back to that one. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7d1b8e7591690fb68cc53553e0f13b537b5455dc Modified Files --

[COMMITTERS] pgsql: Log diagnostic messages if errors occur during LDAP auth.

Log diagnostic messages if errors occur during LDAP auth. Diagnostic messages seem likely to help users diagnose root causes more easily, so let's report them as errdetail. Author: Thomas Munro Reviewed-By: Ashutosh Bapat, Christoph Berg, Alvaro Herrera, Peter Eisentraut Discussion:

[COMMITTERS] pgsql: Improve LDAP cleanup code in error paths.

Improve LDAP cleanup code in error paths. After calling ldap_unbind_s() we probably shouldn't try to use the LDAP connection again to call ldap_get_option(), even if it failed. The OpenLDAP man page for ldap_unbind[_s] says "Once it is called, the connection to the LDAP server is closed, and the

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

Noah Misch writes: > On Thu, Oct 12, 2017 at 04:08:44PM -0700, Andres Freund wrote: >> Noah, any chance you could force restrict to off on that animal? > I can confirm it allows "make check" to pass. So that leaves us with two theories: 1. hornet's compiler contains a bug

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

On Thu, Oct 12, 2017 at 04:48:29PM -0700, Andres Freund wrote: > On 2017-10-12 16:08:44 -0700, Andres Freund wrote: > > wrap-gcc -D_THREAD_SAFE=1 -D_LARGE_FILES=1 -maix64 -Wall > > -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > > -Wendif-labels -Wmissing-format-attribute

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

On Thu, Oct 12, 2017 at 04:08:44PM -0700, Andres Freund wrote: > So we've two animals (hornet, sungazer) that are: > #define SIZEOF_SIZE_T 8 > #define WORDS_BIGENDIAN 1 > #define restrict __restrict > > one compiled with xlc that fails and one with gcc that succeeds. I'm > hesitant to reach for

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

Andres Freund writes: > On 2017-10-12 20:06:32 -0400, Tom Lane wrote: >> Nope, because that's quite old. > Right. I'd mentioned that it's *not* that commit, even though it > initially looked suspicious. Right, my point was that nothing else we'd changed recently broke this

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

On 2017-10-12 20:06:32 -0400, Tom Lane wrote: > Andres Freund writes: > >> fe-connect.c:2382:6: warning: implicit declaration of function > >> 'getpeereid' [-Wimplicit-function-declaration] > >> Looks like we're missing > >> #include > > > Hm, it got removed as part of > >

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

Andres Freund writes: >> fe-connect.c:2382:6: warning: implicit declaration of function 'getpeereid' >> [-Wimplicit-function-declaration] >> Looks like we're missing >> #include > Hm, it got removed as part of >

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

On 2017-10-12 16:08:44 -0700, Andres Freund wrote: > wrap-gcc -D_THREAD_SAFE=1 -D_LARGE_FILES=1 -maix64 -Wall -Wmissing-prototypes > -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv >

[COMMITTERS] pgsql: Use C99 restrict via pg_restrict, rather than restrict directly.

Use C99 restrict via pg_restrict, rather than restrict directly. Unfortunately using 'restrict' plainly causes problems with MSVC, which supports restrict only as '__restrict'. Defining 'restrict' to '__restrict' unfortunately causes a conflict with MSVC's usage of __declspec(restrict) in

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

Andres Freund writes: > But it's easy to do so in configure, and then have a separate definition > in pg_config.h.win32. Done so in the attached commit. It's slightly ugly > to have two definitions of restrict in pg_config.h.in, but whatever. WFM.

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

On 2017-10-12 10:44:58 -0400, Tom Lane wrote: > Andres Freund writes: > > Improve performance of SendRowDescriptionMessage. > > One or another of these patches has broken buildfarm member hornet. > Apparently, it's transmitting incorrectly-formatted RowDescription > messages.

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

Hi, On 2017-10-12 11:03:34 -0700, Andres Freund wrote: > On 2017-10-12 13:55:07 -0400, Tom Lane wrote: > > Or, if you insist on having it, we're going to have to go the pg_restrict > > route. I don't see why that means duplicating any configure logic: on > > non-Windows we can use the autoconf

Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera wrote: > Fix traversal of half-frozen update chains I have a question about this (this is taken from the master branch): > bool > HeapTupleUpdateXmaxMatchesXmin(TransactionId xmax, HeapTupleHeader htup) > { >

Re: [COMMITTERS] pgsql: Avoid coercing a whole-row variable that is already coerced.

Robert Haas writes: > Avoid coercing a whole-row variable that is already coerced. This logic seems very strange and more than likely buggy: the added coerced_var flag feels like the sort of action at a distance that is likely to have unforeseen side effects. I'm not

[COMMITTERS] pgsql: Avoid coercing a whole-row variable that is already coerced.

Avoid coercing a whole-row variable that is already coerced. Marginal efficiency and beautification hack. I'm not sure whether this case ever arises currently, but the pending patch for update tuple routing will cause it to arise. Amit Khandekar Discussion:

[COMMITTERS] pgsql: Use ResultRelInfo ** rather than ResultRelInfo * for tuple routi

Use ResultRelInfo ** rather than ResultRelInfo * for tuple routing. The previous convention doesn't lend itself to creating ResultRelInfos lazily, as we already do in ExecGetTriggerResultRel. This patch doesn't make anything lazier than before, but the pending patch for UPDATE tuple routing

[COMMITTERS] pgsql: Fix AggGetAggref() so it won't lie to aggregate final functions.

Fix AggGetAggref() so it won't lie to aggregate final functions. If we merge the transition calculations for two different aggregates, it's reasonable to assume that the transition function should not care which of those Aggref structs it gets from AggGetAggref(). It is not reasonable to make

[COMMITTERS] pgsql: Fix AggGetAggref() so it won't lie to aggregate final functions.

Fix AggGetAggref() so it won't lie to aggregate final functions. If we merge the transition calculations for two different aggregates, it's reasonable to assume that the transition function should not care which of those Aggref structs it gets from AggGetAggref(). It is not reasonable to make

[COMMITTERS] pgsql: Fix AggGetAggref() so it won't lie to aggregate final functions.

Fix AggGetAggref() so it won't lie to aggregate final functions. If we merge the transition calculations for two different aggregates, it's reasonable to assume that the transition function should not care which of those Aggref structs it gets from AggGetAggref(). It is not reasonable to make

[COMMITTERS] pgsql: Synchronize error messages.

Synchronize error messages. Commits 6476b26115f3ef25a9cd87880e0ac5ec5f7a05f6 and 14f67a8ee282ebc0de78e773fbd597f460ab4a54 didn't use quite the same error message for what is basically the same situation. Amit Langote, pared back a bit by me. Discussion:

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

Hi, On 2017-10-12 13:55:07 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-12 11:30:00 -0400, Tom Lane wrote: > >> I don't actually see why you need a #define at all --- "restrict" is the > >> standard spelling of the keyword no? > > > It is, but a lot of

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

Andres Freund writes: > On 2017-10-12 11:30:00 -0400, Tom Lane wrote: >> I don't actually see why you need a #define at all --- "restrict" is the >> standard spelling of the keyword no? > It is, but a lot of compilers name it differently, e.g. __restrict in > the case of

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

On 2017-10-12 11:30:00 -0400, Tom Lane wrote: > Andres Freund writes: > > I've temporarily silenced that error by moving the stdlib.h include > > before the definition of restrict, but that seems fairly fragile. I > > primarily wanted to see whether there's other problems. At

Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

I wrote: > On reflection, let's just go with the solution of building libpgport_lib.a > with the right flags (fPIC + threading) and leave libpgport.a alone. > That way we don't need a debate about whether there's an efficiency > cost worth worrying about. I looked into this and got discouraged

[COMMITTERS] pgsql: Doc: fix typo in release notes.

Doc: fix typo in release notes. Ioseph Kim Discussion: https://postgr.es/m/e7a79f91-8244-5bcb-afcc-96c817e86...@postgresql.kr Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0a047a1e3ef852884278b1324df73e359972c43a Modified Files --

[COMMITTERS] pgsql: Doc: fix typo in release notes.

Doc: fix typo in release notes. Ioseph Kim Discussion: https://postgr.es/m/e7a79f91-8244-5bcb-afcc-96c817e86...@postgresql.kr Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5c926e68ea61d0b795ad5438e7223e88d3e2c93f Modified Files --

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

Infer functional dependency past RelabelType Vars hidden within a RelabelType would not be detected as compatible with some functional dependency. Repair by properly ignoring the RelabelType. Author: David Rowley Reviewed-by: Tomas Vondra Discussion:

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

Infer functional dependency past RelabelType Vars hidden within a RelabelType would not be detected as compatible with some functional dependency. Repair by properly ignoring the RelabelType. Author: David Rowley Reviewed-by: Tomas Vondra Discussion:

Re: [COMMITTERS] pgsql: Add configure infrastructure to detect support for C99's restric

Andres Freund writes: > I've temporarily silenced that error by moving the stdlib.h include > before the definition of restrict, but that seems fairly fragile. I > primarily wanted to see whether there's other problems. At least thrips > is is now happy. > I see a number of

Re: [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage.

Andres Freund writes: > Improve performance of SendRowDescriptionMessage. One or another of these patches has broken buildfarm member hornet. Apparently, it's transmitting incorrectly-formatted RowDescription messages. regards, tom lane -- Sent via

[COMMITTERS] pgsql: Fix logical replication to fire BEFORE ROW DELETE triggers.

Fix logical replication to fire BEFORE ROW DELETE triggers. Before, that would fail to happen unless a BEFORE ROW UPDATE trigger was also present. Noted by me while reviewing a patch from Masahiko Sawada, who also wrote this patch. Reviewed by Petr Jelinek. Discussion:

[COMMITTERS] pgsql: Fix logical replication to fire BEFORE ROW DELETE triggers.

Fix logical replication to fire BEFORE ROW DELETE triggers. Before, that would fail to happen unless a BEFORE ROW UPDATE trigger was also present. Noted by me while reviewing a patch from Masahiko Sawada, who also wrote this patch. Reviewed by Petr Jelinek. Discussion: