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

[Tom Lane]

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 subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Attempt to fix LDAP build

[Peter Eisentraut]

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
--
src/backend/libpq/auth.c | 6 ++
1 file changed, 6 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Peter Eisentraut]

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: 
https://postgr.es/m/CAEepm=2_dA-SYpFdmNVwvKsEBXOUj=k4ookovhmvj6jnmdt...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/cf1238cd9763f0a6e3454ddf75ac56ff722f18ee

Modified Files
--
src/backend/libpq/auth.c| 48 ++---
src/test/ldap/t/001_auth.pl | 11 ++-
2 files changed, 51 insertions(+), 8 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Peter Eisentraut]

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 ld structure is invalid."  Otherwise, as a
general rule we should probably call ldap_unbind() before returning in all
paths to avoid leaking resources.  It is unlikely there is any practical
leak problem since failure to authenticate currently results in the backend
exiting soon afterwards.

Author: Thomas Munro
Reviewed-By: Alvaro Herrera, Peter Eisentraut
Discussion: https://postgr.es/m/20170914141205.eup4kxzlkagtmfac%40alvherre.pgsql

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1feff99fe4576d4685c14dff18d1f845a1456f10

Modified Files
--
src/backend/libpq/auth.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 that causes it to misoptimize
in the presence of "restrict".

2. There's a bug in the way HEAD is applying "restrict", which happens
not to manifest on other platforms.

While I have to agree with Andres' evident feeling that it's probably
#1, I do not think we should dismiss #2 without inquiring a bit
harder.  It would be really useful, I think, if we could characterize
exactly how the RowDescription output is broken in that build.
Noah, could you capture some of those messages somehow?

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Noah Misch]

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 -Wformat-security 
> > -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -O2 
> > -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS  -DFRONTEND 
> > -DUNSAFE_STAT_OK -I. -I../../../src/include   -I../../../src/port 
> > -I../../../src/port -DSO_MAJOR_VERSION=5  -c -o fe-connect.o fe-connect.c
> > fe-connect.c: In function 'PQconnectPoll':
> > fe-connect.c:2382:6: warning: implicit declaration of function 'getpeereid' 
> > [-Wimplicit-function-declaration]
> >   if (getpeereid(conn->sock, , ) != 0)
> >   ^
> > 
> > Looks like we're missing
> > #include 
> 
> Hm, it got removed as part of
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e3755ecb2d058f7d123dd35a2e1784006190962
> but that's not an explanation, because
> c.h includes sys/types.h. Which according to IBM's docs
> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf1/getpeereid.htm
> is the right thing to include.  Given that xlc doesn't complain, I'll
> just assume this is some issue with the headers gcc uses on aix, but I'm
> far from confident.

The relevant xlc warning is disabled by default.  "xlc -qinfo=pro" does
complain.   provides no such prototype.   provides
a getpeereid() prototype, but under C++ only.  (For getpeername(), it provides
both C and C++ prototypes.)  Thus, the AIX documentation is wrong, and
/usr/include is buggy.


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Noah Misch]

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 that, but I wonder if there's a compiler
> bug. Alternatively there could be some undefined behaviour here that
> only triggers on xlc 64bit, but I'm not quite seeing it.
> 
> Noah, any chance you could force restrict to off on that animal?

I can confirm it allows "make check" to pass.  Specifically, I did this
against commit 91d5f1a:

--- src/include/pg_config.h~2017-10-12 18:11:33.0 -0700
+++ src/include/pg_config.h 2017-10-12 18:22:34.0 -0700
@@ -929 +929 @@
- #define pg_restrict __restrict
+ #define pg_restrict
@@ -934 +934 @@
- #define restrict __restrict
+ #define restrict

I have no reason to believe this is specific to hornet's installation, so I
recommend against altering hornet's configuration.  It's too likely that the
next xlc user will need to do the same thing.  I don't see the problem with
xlc 13.1.3, though.

> Otherwise I can push a platform fix that disables it.

This sounds reasonable.

nm


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 either.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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
> > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e3755ecb2d058f7d123dd35a2e1784006190962
> > but that's not an explanation, because
> 
> Nope, because that's quite old.

Right. I'd mentioned that it's *not* that commit, even though it
initially looked suspicious.

Greetings,

Andres Freund


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e3755ecb2d058f7d123dd35a2e1784006190962
> but that's not an explanation, because

Nope, because that's quite old.  The oldest make log on praxis for
sungazer is from 2015-08-31, and it contains these warning lines:

 auth.c:1585:2: warning: implicit declaration of function 'getpeereid' 
[-Wimplicit-function-declaration]
 ip.c:228:31: warning: large integer implicitly truncated to unsigned type 
[-Woverflow]
 pg_locale.c:1284:3: warning: implicit declaration of function 'wcstombs_l' 
[-Wimplicit-function-declaration]
 fe-connect.c:1991:6: warning: implicit declaration of function 'getpeereid' 
[-Wimplicit-function-declaration]
 ip.c:228:31: warning: large integer implicitly truncated to unsigned type 
[-Woverflow]

It looks like we have grown another occurrence of the "implicitly
truncated" nag, but otherwise it's the same warnings in the most
recent log.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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 
> -fexcess-precision=standard -g -O2 -I../../../src/include-c -o auth.o 
> auth.c
> auth.c: In function 'auth_peer':
> auth.c:2002:2: warning: implicit declaration of function 'getpeereid' 
> [-Wimplicit-function-declaration]
>   if (getpeereid(port->sock, , ) != 0)
>   ^
> 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 
> -fexcess-precision=standard -g -O2 -D_REENTRANT -D_THREAD_SAFE 
> -D_POSIX_PTHREAD_SEMANTICS  -DFRONTEND -DUNSAFE_STAT_OK -I. 
> -I../../../src/include   -I../../../src/port -I../../../src/port 
> -DSO_MAJOR_VERSION=5  -c -o fe-connect.o fe-connect.c
> fe-connect.c: In function 'PQconnectPoll':
> fe-connect.c:2382:6: warning: implicit declaration of function 'getpeereid' 
> [-Wimplicit-function-declaration]
>   if (getpeereid(conn->sock, , ) != 0)
>   ^
> 
> Looks like we're missing
> #include 

Hm, it got removed as part of
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e3755ecb2d058f7d123dd35a2e1784006190962
but that's not an explanation, because
c.h includes sys/types.h. Which according to IBM's docs
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf1/getpeereid.htm
is the right thing to include.  Given that xlc doesn't complain, I'll
just assume this is some issue with the headers gcc uses on aix, but I'm
far from confident.

Greetings,

Andres Freund


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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 headers.

Therefore define pg_restrict to the appropriate keyword instead, and
replace existing usages.

This replaces the temporary workaround introduced in 36b4b91ba078.

Author: Andres Freund
Discussion: https://postgr.es/m/2656.1507830...@sss.pgh.pa.us

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/91d5f1a4a3e8aea2a6488243bac55806160408fb

Modified Files
--
configure | 107 --
configure.in  |  15 +-
src/include/libpq/pqformat.h  |  24 +-
src/include/pg_config.h.in|   4 ++
src/include/pg_config.h.win32 |  22 -
5 files changed, 101 insertions(+), 71 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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.

This is curious.

Buildfarm animal hornet has failed. It's ppc64 compiled with xlc 12.1,
64 bit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2017-10-12%2022%3A14%3A41

Buildfarm animal mandrill succeeded. It's ppc64 compiled with xlc 12.1,
32 bit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill=2017-10-12%2018%3A35%3A47

Buildfarm animal sungazer succeeded. It's ppc64 compiled with gcc 4.8,
64 bit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer=2017-10-12%2008%3A21%3A29

All of these are up to at least 31079a4.

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 that, but I wonder if there's a compiler
bug. Alternatively there could be some undefined behaviour here that
only triggers on xlc 64bit, but I'm not quite seeing it.

Noah, any chance you could force restrict to off on that animal?
Otherwise I can push a platform fix that disables it.


Entirely independent of this, both machines report some interesting
warnings:
Hornet:
xlc_r -D_LARGE_FILES=1  -qnoansialias -g -O2 -qmaxmem=16384 -qsrcmsg  
-L../../src/port -L../../src/common  
-Wl,-blibpath:'/home/nm/farm/xlc64/HEAD/inst/lib:/usr/lib:/lib' 
-L../../src/port -lpgport  -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE -o timetravel.so 
timetravel.o -Wl,-bE:timetravel.exp -Wl,-bI:../../src/backend/postgres.imp
ld: 0711-224 WARNING: Duplicate symbol: .pg_strcasecmp
ld: 0711-224 WARNING: Duplicate symbol: .pg_ascii_tolower
ld: 0711-224 WARNING: Duplicate symbol: .pg_ascii_toupper
ld: 0711-224 WARNING: Duplicate symbol: .pg_tolower
ld: 0711-224 WARNING: Duplicate symbol: .pg_toupper
ld: 0711-224 WARNING: Duplicate symbol: .pg_strncasecmp

Hm. Seems we've some workaround in some platforms:
# src/template/win32

# --allow-multiple-definition is required to link pg_dump because it finds
# pg_toupper() etc. in both libpq and pgport

But that, uh, seems not good?

Sungazer:
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 
-fexcess-precision=standard -g -O2 zic.o  -L../../src/port -L../../src/common  
-Wl,-blibpath:'/home/nm/farm/gcc64/HEAD/inst/lib:/usr/lib:/lib'  -lpgcommon 
-lpgport -lssl -lcrypto -lz -lreadline -lld -lm  -o zic
ld: 0711-224 WARNING: Duplicate symbol: .bcopy
ld: 0711-224 WARNING: Duplicate symbol: .memmove

Hm.

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 
-fexcess-precision=standard -g -O2 -I../../../src/include-c -o auth.o auth.c
auth.c: In function 'auth_peer':
auth.c:2002:2: warning: implicit declaration of function 'getpeereid' 
[-Wimplicit-function-declaration]
  if (getpeereid(port->sock, , ) != 0)
  ^
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 
-fexcess-precision=standard -g -O2 -D_REENTRANT -D_THREAD_SAFE 
-D_POSIX_PTHREAD_SEMANTICS  -DFRONTEND -DUNSAFE_STAT_OK -I. 
-I../../../src/include   -I../../../src/port -I../../../src/port 
-DSO_MAJOR_VERSION=5  -c -o fe-connect.o fe-connect.c
fe-connect.c: In function 'PQconnectPoll':
fe-connect.c:2382:6: warning: implicit declaration of function 'getpeereid' 
[-Wimplicit-function-declaration]
  if (getpeereid(conn->sock, , ) != 0)
  ^

Looks like we're missing
#include 


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 
-fexcess-precision=standard -g -O2 -I../../../../src/include-c -o 
pg_locale.o pg_locale.c
pg_locale.c: In function 'wchar2char':
pg_locale.c:1648:3: warning: implicit declaration of function 'wcstombs_l' 
[-Wimplicit-function-declaration]
   result = wcstombs_l(to, from, tolen, locale->info.lt);
   ^
This is curious. If I'm interpreting this correctly PGAC_FUNC_WCSTOMBS_L
fails to find a declaration, but AC_CHECK_FUNCS finds wcstombs_l, so we
happily use it.

Greetings,

Andres Freund


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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 probe and then write
> > "#define pg_restrict restrict".
> 
> Yea, that should work. I'll try to come up with a patch.

We can't do so unconditionally in c.h or such, because that'd again
cause conflicts with __declspec(restrict) on MSVC versions that don't
support restrict, because it'd require restrict to be defined empty.

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.

Greetings,

Andres Freund
>From 0ddc96424119682cf3b68c6d8d95ea894a60817a Mon Sep 17 00:00:00 2001
From: Andres Freund 
Date: Thu, 12 Oct 2017 15:25:38 -0700
Subject: [PATCH] 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 headers.

Therefore define pg_restrict to the appropriate keyword instead, and
replace existing usages.

This replaces the temporary workaround introduced in 36b4b91ba078.

Author: Andres Freund
Discussion: https://postgr.es/m/2656.1507830...@sss.pgh.pa.us
---
 configure | 107 --
 configure.in  |  15 +-
 src/include/libpq/pqformat.h  |  24 +-
 src/include/pg_config.h.in|   4 ++
 src/include/pg_config.h.win32 |  22 -
 5 files changed, 101 insertions(+), 71 deletions(-)

diff --git a/configure b/configure
index 910f0fc3736..cdcb3ceb0c8 100755
--- a/configure
+++ b/configure
@@ -11545,52 +11545,6 @@ _ACEOF
 ;;
 esac
 
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
-$as_echo_n "checking for C/C++ restrict keyword... " >&6; }
-if ${ac_cv_c_restrict+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-  ac_cv_c_restrict=no
-   # The order here caters to the fact that C++ does not require restrict.
-   for ac_kw in __restrict __restrict__ _Restrict restrict; do
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-typedef int * int_ptr;
-	int foo (int_ptr $ac_kw ip) {
-	return ip[0];
-   }
-int
-main ()
-{
-int s[1];
-	int * $ac_kw t = s;
-	t[0] = 0;
-	return foo(t)
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  ac_cv_c_restrict=$ac_kw
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
- test "$ac_cv_c_restrict" != no && break
-   done
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_restrict" >&5
-$as_echo "$ac_cv_c_restrict" >&6; }
-
- case $ac_cv_c_restrict in
-   restrict) ;;
-   no) $as_echo "#define restrict /**/" >>confdefs.h
- ;;
-   *)  cat >>confdefs.h <<_ACEOF
-#define restrict $ac_cv_c_restrict
-_ACEOF
- ;;
- esac
-
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for printf format archetype" >&5
 $as_echo_n "checking for printf format archetype... " >&6; }
 if ${pgac_cv_printf_archetype+:} false; then :
@@ -12508,6 +12462,67 @@ $as_echo "#define LOCALE_T_IN_XLOCALE 1" >>confdefs.h
 
 fi
 
+# MSVC doesn't cope well with defining restrict to __restrict, the
+# spelling it understands, because it conflicts with
+# __declspec(restrict). Therefore we define pg_restrict to the
+# appropriate definition, which presumably won't conflict.
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for C/C++ restrict keyword" >&5
+$as_echo_n "checking for C/C++ restrict keyword... " >&6; }
+if ${ac_cv_c_restrict+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_cv_c_restrict=no
+   # The order here caters to the fact that C++ does not require restrict.
+   for ac_kw in __restrict __restrict__ _Restrict restrict; do
+ cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+typedef int * int_ptr;
+	int foo (int_ptr $ac_kw ip) {
+	return ip[0];
+   }
+int
+main ()
+{
+int s[1];
+	int * $ac_kw t = s;
+	t[0] = 0;
+	return foo(t)
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  ac_cv_c_restrict=$ac_kw
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+ test "$ac_cv_c_restrict" != no && break
+   done
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_c_restrict" >&5
+$as_echo "$ac_cv_c_restrict" >&6; }
+
+ case $ac_cv_c_restrict in
+   restrict) ;;
+   no) $as_echo "#define restrict /**/" >>confdefs.h
+ ;;
+   *)  cat >>confdefs.h <<_ACEOF
+#define restrict $ac_cv_c_restrict
+_ACEOF
+ ;;
+ esac
+
+if test "$ac_cv_c_restrict" = "no" ; then
+  pg_restrict=""
+else
+  pg_restrict="$ac_cv_c_restrict"
+fi
+
+cat 

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

[Peter Geoghegan]

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)
> {
> TransactionId   xmin = HeapTupleHeaderGetXmin(htup);
>
> /*
>  * If the xmax of the old tuple is identical to the xmin of the new one,
>  * it's a match.
>  */
> if (TransactionIdEquals(xmax, xmin))
> return true;
>
> /*
>  * If the Xmin that was in effect prior to a freeze matches the Xmax,
>  * it's good too.
>  */
> if (HeapTupleHeaderXminFrozen(htup) &&
> TransactionIdEquals(HeapTupleHeaderGetRawXmin(htup), xmax))
> return true;
>
> /*
>  * When a tuple is frozen, the original Xmin is lost, but we know it's a
>  * committed transaction.  So unless the Xmax is InvalidXid, we don't know
>  * for certain that there is a match, but there may be one; and we must
>  * return true so that a HOT chain that is half-frozen can be walked
>  * correctly.
>  *
>  * We no longer freeze tuples this way, but we must keep this in order to
>  * interpret pre-pg_upgrade pages correctly.
>  */
> if (TransactionIdEquals(xmin, FrozenTransactionId) &&
> TransactionIdIsValid(xmax))
> return true;
>
> return false;
> }

Wouldn't this last "if" test, to cover the pg_upgrade case, be better
targeted by comparing *raw* xmin to FrozenTransactionId? You're using
the potentially distinct xmin value returned by
HeapTupleHeaderGetXmin() for the test here. I think we should be
directly targeting tuples frozen on or before 9.4 (prior to
pg_upgrade) instead.

Have I missed something?

-- 
Peter Geoghegan


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 entirely sure what the issue is here, but if you're concerned
about not applying two ConvertRowtypeExprs in a row, why not have the
upper one just strip off the lower one?  We handle, eg, nested
RelabelTypes that way.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Robert Haas]

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: 
http://postgr.es/m/caj3gd9cazfppe7-wwubabpcq4_0subkipfd1+0r5_dkvnwo...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/1c497fa72df7593d8976653538da3d0ab033207f

Modified Files
--
src/backend/rewrite/rewriteManip.c | 53 ++
1 file changed, 42 insertions(+), 11 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Robert Haas]

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 proposes to do so (and there might be other
opportunities as well).

Amit Khandekar with some adjustments by me.

Discussion: 
http://postgr.es/m/ca+tgmoypvp9lyf6vufa5dwxs4c--x6loj2y36bsjaytp62e...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/60f7c0abef0327648c02795312d1679c66586fbb

Modified Files
--
src/backend/commands/copy.c| 10 ++---
src/backend/executor/execMain.c| 13 +++---
src/backend/executor/nodeModifyTable.c | 74 --
src/include/executor/executor.h|  2 +-
src/include/nodes/execnodes.h  |  2 +-
5 files changed, 57 insertions(+), 44 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 the same assumption about an aggregate final function,
however.  Commit 804163bc2 broke this, as it will pass whichever Aggref
was first associated with the transition state in both cases.

This doesn't create an observable bug so far as the core system is
concerned, because the only existing uses of AggGetAggref() are in
ordered-set aggregates that happen to not pay attention to anything
but the input properties of the Aggref; and besides that, we disabled
sharing of transition calculations for OSAs yesterday.  Nonetheless,
if some third-party code were using AggGetAggref() in a normal aggregate,
they would be entitled to call this a bug.  Hence, back-patch the fix
to 9.6 where the problem was introduced.

In passing, improve some of the comments about transition state sharing.

Discussion: 
https://postgr.es/m/cab4elo5rzhoamut9xsf72ozbendllxzksk07fisvsujnzb8...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/305cf1fd7239e0ffa9ae4ff54a7c66f36432c741

Modified Files
--
src/backend/executor/nodeAgg.c | 65 +++---
src/include/nodes/execnodes.h  |  3 +-
2 files changed, 44 insertions(+), 24 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 the same assumption about an aggregate final function,
however.  Commit 804163bc2 broke this, as it will pass whichever Aggref
was first associated with the transition state in both cases.

This doesn't create an observable bug so far as the core system is
concerned, because the only existing uses of AggGetAggref() are in
ordered-set aggregates that happen to not pay attention to anything
but the input properties of the Aggref; and besides that, we disabled
sharing of transition calculations for OSAs yesterday.  Nonetheless,
if some third-party code were using AggGetAggref() in a normal aggregate,
they would be entitled to call this a bug.  Hence, back-patch the fix
to 9.6 where the problem was introduced.

In passing, improve some of the comments about transition state sharing.

Discussion: 
https://postgr.es/m/cab4elo5rzhoamut9xsf72ozbendllxzksk07fisvsujnzb8...@mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/aa1e9b3a466102fc43dc96906b9b3ced299ca7ed

Modified Files
--
src/backend/executor/nodeAgg.c | 65 +++---
src/include/nodes/execnodes.h  |  3 +-
2 files changed, 44 insertions(+), 24 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 the same assumption about an aggregate final function,
however.  Commit 804163bc2 broke this, as it will pass whichever Aggref
was first associated with the transition state in both cases.

This doesn't create an observable bug so far as the core system is
concerned, because the only existing uses of AggGetAggref() are in
ordered-set aggregates that happen to not pay attention to anything
but the input properties of the Aggref; and besides that, we disabled
sharing of transition calculations for OSAs yesterday.  Nonetheless,
if some third-party code were using AggGetAggref() in a normal aggregate,
they would be entitled to call this a bug.  Hence, back-patch the fix
to 9.6 where the problem was introduced.

In passing, improve some of the comments about transition state sharing.

Discussion: 
https://postgr.es/m/cab4elo5rzhoamut9xsf72ozbendllxzksk07fisvsujnzb8...@mail.gmail.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/d48bf6a94d295c3779c6af4df118d95a6606192f

Modified Files
--
src/backend/executor/nodeAgg.c | 65 +++---
src/include/nodes/execnodes.h  |  3 +-
2 files changed, 44 insertions(+), 24 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Synchronize error messages.

[Robert Haas]

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: 
http://postgr.es/m/54dc76d0-3b5b-ba5a-27dc-fb31a3975...@lab.ntt.co.jp

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/ad4a7ed0996ee044ee7291559deddf9842d8bbf7

Modified Files
--
src/backend/catalog/partition.c   | 4 ++--
src/test/regress/expected/alter_table.out | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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 compilers name it differently, e.g. __restrict in
> > the case of msvc.
> 
> It's 2017 and they're still not C99 compliant?  Oh well.

...


> TBH, I really doubt that restrict buys us enough performance to justify
> dealing with this.  I'd just revert that change altogether.

It's quite noticeable, and there's plenty of other case where it seems
likely to be beneficial.


> 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 probe and then write
> "#define pg_restrict restrict".

Yea, that should work. I'll try to come up with a patch.

Greetings,

Andres Freund


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 msvc.

It's 2017 and they're still not C99 compliant?  Oh well.

TBH, I really doubt that restrict buys us enough performance to justify
dealing with this.  I'd just revert that change altogether.

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 probe and then write
"#define pg_restrict restrict".

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Andres Freund]

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 least thrips
> > is is now happy.
> 
> > I see a number of options to continue:
> > - only define restrict on msvc 2013+ - for some reason woodlouse didn't
> >   complain about this problem, but I'm very doubtful that that's
> >   actually reliable.
> > - rename restrict to pg_restrict. That's annoying because we'd have to
> >   copy the autoconf test.
> > - live with the hack of including stdlib.h early, in pg_config.h.win32.
> > - $better_idea
> 
> 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 msvc.


> I really do not like the stdlib.h hack: that amounts to assuming that
> only stdlib.h does or ever will contain declspec(restrict).  Maybe
> you could get away with that if you were applying it only to long-dead
> MSVC versions, but doing it "#if (_MSC_VER >= 1500)" is clearly going
> to break someday.

Yea, I dislike it quite a bit too. Unfortunately not even defining
restrict to empty as if it were unsupported looks viable to me :(

Greetings,

Andres Freund


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 after realizing that not only does
libpq pull in and recompile a bundle of src/port/ files, but also from
src/common/, and even some random backend files like encnames.c and
wchar.c.  We could possibly apply the same build-a-third-way technique to
src/common/, but we'd still end up with messiness for the encoding files.

Perhaps what this is telling us is that encnames.c and wchar.c ought to be
moved to src/common/.

On top of that, there are also some interactions with the MSVC build
system that I don't especially want to debug or untangle.

In short, this is looking like a whole lot more work than we could
ever hope to save by not having to maintain these file lists anymore.
So I'm not planning to pursue it.  If someone else wants to, though,
have at it.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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
--
doc/src/sgml/release-10.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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
--
doc/src/sgml/release-10.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

[Alvaro Herrera]

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: 
https://postgr.es/m/CAKJS1f-y-UEy=rsbxynbogiw1fkmr_lvoysgl9qoc36mlec...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e9ef11ac8bb2acc2d2462fc17ec3291a959589e7

Modified Files
--
src/backend/statistics/dependencies.c | 8 
1 file changed, 8 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

[Alvaro Herrera]

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: 
https://postgr.es/m/CAKJS1f-y-UEy=rsbxynbogiw1fkmr_lvoysgl9qoc36mlec...@mail.gmail.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/a01a3d931e5a14d60eec75f7945d5e66ff9cc575

Modified Files
--
src/backend/statistics/dependencies.c | 8 
1 file changed, 8 insertions(+)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 options to continue:
> - only define restrict on msvc 2013+ - for some reason woodlouse didn't
>   complain about this problem, but I'm very doubtful that that's
>   actually reliable.
> - rename restrict to pg_restrict. That's annoying because we'd have to
>   copy the autoconf test.
> - live with the hack of including stdlib.h early, in pg_config.h.win32.
> - $better_idea

I don't actually see why you need a #define at all --- "restrict" is the
standard spelling of the keyword no?

I really do not like the stdlib.h hack: that amounts to assuming that
only stdlib.h does or ever will contain declspec(restrict).  Maybe
you could get away with that if you were applying it only to long-dead
MSVC versions, but doing it "#if (_MSC_VER >= 1500)" is clearly going
to break someday.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Tom Lane]

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 pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Robert Haas]

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: 
http://postgr.es/m/ca+tgmobazvcxdug8y_mqkbk7nz-vhbdlvjm354kefozpuzm...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/360fd1a7b2fe779cc9e696b813b12f6a8e83b558

Modified Files
--
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

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

[Robert Haas]

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: 
http://postgr.es/m/ca+tgmobazvcxdug8y_mqkbk7nz-vhbdlvjm354kefozpuzm...@mail.gmail.com

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/7cde649ab150412344ee50fc90f24d6fe891bcf0

Modified Files
--
src/backend/executor/execReplication.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers