Re: [COMMITTERS] pgsql: Remove secondary checkpoint

2017-11-20 Thread Amit Kapila
On Sat, Nov 11, 2017 at 10:58 PM, Andreas Seltenreich
 wrote:
> Hi,
>
> sqlsmith doesn't like commit 4b0d28de06:
>
> ,
> | regression=> select * from pg_control_checkpoint();
> | server closed the connection unexpectedly
> | TRAP: FailedAssertion("!((atti->attalign) == 's')", File: "heaptuple.c", 
> Line: 126)
> `
>
> On a build with assertions disabled, the statement fails with an error
> instead:
>
> ,
> | regression=> select * from pg_control_checkpoint();
> | ERROR:  function return row and query-specified return row do not match
> | DETAIL:  Returned row contains 19 attributes, but query expects 18.
> `
>
> The attached patch fixes it for me.
>


Your patch looks correct to me.  I can reproduce the problem and
verified that patch fixes the problem.  It is better to track this in
CF if not already tracked.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql: Pass eflags down to parallel workers.

2017-11-20 Thread Robert Haas
Pass eflags down to parallel workers.

Currently, there are no known consequences of this oversight, so no
back-patch.  Several of the EXEC_FLAG_* constants aren't usable in
parallel mode anyway, and potential problems related to the presence
or absence of OIDs (see EXEC_FLAG_WITH_OIDS, EXEC_FLAG_WITHOUT_OIDS)
seem at present to be masked by the unconditional projection step
performed by Gather and Gather Merge.  In general, however, it seems
important that all participants agree on the values of these flags,
which modify executor behavior globally, and a pending patch to skip
projection in Gather (Merge) would be outright broken in certain cases
without this fix.

Patch by me, based on investigation of a test case provided by Amit
Kapila.  This patch was also reviewed by Amit Kapila.

Discussion: 
http://postgr.es/m/CA+TgmoZ0ZL=ceszfq8c9nnfk6bqy-wwud3_74iygodyrsoq...@mail.gmail.com

Branch
--
master

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

Modified Files
--
src/backend/executor/execParallel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)



pgsql: Tweak use of ExecContextForcesOids by Gather (Merge).

2017-11-20 Thread Robert Haas
Tweak use of ExecContextForcesOids by Gather (Merge).

Specifically, pass the outer plan's PlanState instead of our own
PlanState.  At present, ExecContextForcesOids doesn't actually care
which PlanState we pass; it just looks through to the underlying
EState to find the result relation or top-level eflags.  However, in
the future it might care.  If that happens, and if our goal is to get
a tuple descriptor that matches that of the outer plan, then I think
what we care about is whether the outer plan's context forces OIDs,
rather than whether our own context forces OIDs, just as we use the
outer node's target list rather than our own.

Patch by me, reviewed by Amit Kapila.

Discussion: 
http://postgr.es/m/CA+TgmoZ0ZL=ceszfq8c9nnfk6bqy-wwud3_74iygodyrsoq...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/0510421ee091ee3ddabdd5bd7ed096563f6bf17f

Modified Files
--
src/backend/executor/nodeGather.c  | 2 +-
src/backend/executor/nodeGatherMerge.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

2017-11-20 Thread Andres Freund
Hi,

On 2017-11-13 19:03:41 -0800, Andres Freund wrote:
> Hi,
> 
> On 2017-11-03 07:53:30 -0700, Andres Freund wrote:
> > Here's that patch.  I've stared at this some, and Robert did too. Robert
> > mentioned that the commit message might need some polish and I'm not
> > 100% sure about the error message texts yet.
> > 
> > I'm not yet convinced that the new elog in vacuumlazy can never trigger
> > - but I also don't think we want to actually freeze the tuple in that
> > case.
> 
> I'm fairly sure it could be triggered, therefore I've rewritten that.
> 
> I've played around quite some with the attached patch. So far, after
> applying the second patch, neither VACUUM nor VACUUM FULL / CLUSTER make
> the situation worse for already existing corruption. HOT pruning can
> change the exact appearance of existing corruption a bit, but I don't
> think it can make the corruption meaningfully worse.  It's a bit
> annoying and scary to add so many checks to backbranches but it kinda
> seems required.  The error message texts aren't perfect, but these are
> "should never be hit" type elog()s so I'm not too worried about that.
> 
> 
> Please review!

Ping? Alvaro, it'd be good to get some input here.

- Andres



Re: [COMMITTERS] pgsql: Remove secondary checkpoint

2017-11-20 Thread Simon Riggs
On 20 November 2017 at 08:38, Amit Kapila  wrote:
> On Sat, Nov 11, 2017 at 10:58 PM, Andreas Seltenreich
>  wrote:
>> Hi,
>>
>> sqlsmith doesn't like commit 4b0d28de06:
>>
>> ,
>> | regression=> select * from pg_control_checkpoint();
>> | server closed the connection unexpectedly
>> | TRAP: FailedAssertion("!((atti->attalign) == 's')", File: "heaptuple.c", 
>> Line: 126)
>> `
>>
>> On a build with assertions disabled, the statement fails with an error
>> instead:
>>
>> ,
>> | regression=> select * from pg_control_checkpoint();
>> | ERROR:  function return row and query-specified return row do not match
>> | DETAIL:  Returned row contains 19 attributes, but query expects 18.
>> `
>>
>> The attached patch fixes it for me.
>>
>
>
> Your patch looks correct to me.  I can reproduce the problem and
> verified that patch fixes the problem.  It is better to track this in
> CF if not already tracked.

What email and patch is this referring to?

-- 
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: [COMMITTERS] pgsql: Remove secondary checkpoint

2017-11-20 Thread Andres Freund
On 2017-11-20 15:50:40 -0500, Simon Riggs wrote:
> On 20 November 2017 at 08:38, Amit Kapila  wrote:
> > Your patch looks correct to me.  I can reproduce the problem and
> > verified that patch fixes the problem.  It is better to track this in
> > CF if not already tracked.
> 
> What email and patch is this referring to?

https://www.postgresql.org/message-id/[email protected]



pgsql: Fix pg_control_checkpoint from commit 4b0d28de06

2017-11-20 Thread Simon Riggs
Fix pg_control_checkpoint from commit 4b0d28de06

Author: Simon Riggs 
Reported-By: Andreas Seltenreich 

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/2ede45c3a49e484edfa143850d55eb32dba296de

Modified Files
--
src/backend/utils/misc/pg_controldata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)



Re: pgsql: Fix pg_control_checkpoint from commit 4b0d28de06

2017-11-20 Thread Andres Freund
On 2017-11-20 21:04:08 +, Simon Riggs wrote:
> Fix pg_control_checkpoint from commit 4b0d28de06
> 
> Author: Simon Riggs 
> Reported-By: Andreas Seltenreich 

Wasn't Andreas both author and reporter here?



Re: pgsql: Fix pg_control_checkpoint from commit 4b0d28de06

2017-11-20 Thread Simon Riggs
On 20 November 2017 at 16:05, Andres Freund  wrote:
> On 2017-11-20 21:04:08 +, Simon Riggs wrote:
>> Fix pg_control_checkpoint from commit 4b0d28de06
>>
>> Author: Simon Riggs 
>> Reported-By: Andreas Seltenreich 
>
> Wasn't Andreas both author and reporter here?

In fact, no, since I couldn't find his email or patch so I had to work
it out myself.

I fixed it quickly since the bug was down to me.

-- 
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: [COMMITTERS] pgsql: Remove secondary checkpoint

2017-11-20 Thread Simon Riggs
On 20 November 2017 at 15:55, Andres Freund  wrote:
> On 2017-11-20 15:50:40 -0500, Simon Riggs wrote:
>> On 20 November 2017 at 08:38, Amit Kapila  wrote:
>> > Your patch looks correct to me.  I can reproduce the problem and
>> > verified that patch fixes the problem.  It is better to track this in
>> > CF if not already tracked.
>>
>> What email and patch is this referring to?
>
> https://www.postgresql.org/message-id/[email protected]

Apologies to Andreas, I didn't receive that email

-- 
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_6_STABLE

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

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/84669c9b06ba0d2485007643322bd3fcaa8c729e

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
master

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

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/8bd8b4b77c300c659667b16ef72a2d5c5ac63f49

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL_10_STABLE

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

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_4_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/13f2bdb6394ff7f933955609bb42d4381240a602

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/1056dd0e94f349882deaca072e80b58529ed8c3c

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_6_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/940bafa75a0417128279095673a22d6d9b9e8413

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL_10_STABLE

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

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/516cea4bb273364edb118f75dceadfc9573ba024

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD

2017-11-20 Thread Tom Lane
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/2cfafabe64bae2d7923ab9863786d7bcc7cdf793

Modified Files
--
src/backend/storage/lmgr/s_lock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)



pgsql: Add support for Motorola 88K to s_lock.h.

2017-11-20 Thread Tom Lane
Add support for Motorola 88K to s_lock.h.

Apparently there are still people out there who care about this old
architecture.  They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.

David Carlier (from a patch being carried by OpenBSD packagers)

Discussion: 
https://postgr.es/m/ca+xhmqzwfsgvu7menfhcecc8ydp98tigxzzpd0aadwagwav...@mail.gmail.com

Branch
--
REL9_3_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/0245c75f4f241901c62067c32ccd8afc1d3db3b2

Modified Files
--
src/include/storage/s_lock.h | 24 
1 file changed, 24 insertions(+)



pgsql: Support index-only scans in contrib/cube and contrib/seg GiST in

2017-11-20 Thread Tom Lane
Support index-only scans in contrib/cube and contrib/seg GiST indexes.

To do this, we only have to remove the compress and decompress support
functions, which have never done anything more than detoasting.
In the wake of commit d3a4f89d8, this results in automatically enabling
index-only scans, since the core code will now know that the stored
representation is the same as the original data (up to detoasting).

The only exciting part of this is that ALTER OPERATOR FAMILY lacks
a way to drop a support function that was declared as being part of
an opclass rather than being loose in the family.  For the moment,
we'll hack our way to a solution with a manual update of the pg_depend
entry type, which is what distinguishes the two cases.  Perhaps
someday it'll be worth providing a cleaner way to do that, but for
now it seems like a very niche problem.

Note that the underlying C functions remain, to support use of the shared
libraries with older versions of the modules' SQL declarations.  Someday
we may be able to remove them, but not soon.

Andrey Borodin, reviewed by me

Discussion: 
https://postgr.es/m/[email protected]

Branch
--
master

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

Modified Files
--
contrib/cube/Makefile|  2 +-
contrib/cube/cube--1.3--1.4.sql  | 45 
contrib/cube/cube.control|  2 +-
contrib/cube/expected/cube.out   | 22 
contrib/cube/expected/cube_2.out | 22 
contrib/cube/sql/cube.sql|  7 +++
contrib/seg/Makefile |  2 +-
contrib/seg/expected/seg.out | 28 +
contrib/seg/expected/seg_1.out   | 28 +
contrib/seg/seg--1.2--1.3.sql| 45 
contrib/seg/seg.control  |  2 +-
contrib/seg/sql/seg.sql  |  9 
12 files changed, 210 insertions(+), 4 deletions(-)