[COMMITTERS] pgsql: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/50c8196f946d55f7f4b998491e48f592f711c4fe

Modified Files
--
src/backend/commands/tablecmds.c  | 33 +++
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 108 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: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/f64554b99a00ed0fe4097811dfa94265581c27ae

Modified Files
--
src/backend/commands/tablecmds.c  | 33 +++
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 108 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: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/d86f40009b6b019f794819a9af9038cff0cac6f3

Modified Files
--
src/backend/commands/tablecmds.c  | 44 +--
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 117 insertions(+), 2 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: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
REL9_3_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/5f89a9885e118ab22689f9641237f7941d9ba8fd

Modified Files
--
src/backend/commands/tablecmds.c  | 33 +++
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 108 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: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
REL9_2_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/6c4cf2be81e4b783402aecf49df2f1120e42b99b

Modified Files
--
src/backend/commands/tablecmds.c  | 33 +++
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 108 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: Handle OID column inheritance correctly in ALTER TABLE ... INHER

[Tom Lane]

Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.

Inheritance operations must treat the OID column, if any, much like
regular user columns.  But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.

Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me.  It's been broken all along, so back-patch to
all supported branches.

Discussion: 
https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28...@lab.ntt.co.jp

Branch
--
REL9_4_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/696d40d303af1e92fbbe4192a93c5a94340fc22c

Modified Files
--
src/backend/commands/tablecmds.c  | 33 +++
src/test/regress/expected/inherit.out | 49 +++
src/test/regress/sql/inherit.sql  | 26 +++
3 files changed, 108 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: Improve documentation of timestamp internal representation.

[Robert Haas]

Improve documentation of timestamp internal representation.

Be more clear that we represent timestamps in microseconds when
integer timestamps are used, and in fractional seconds when
floating-point timestamps are used.

Discussion: http://postgr.es/m/20161212135045.GB15488@e733.localdomain

Report by Alexander Alekseev.  Wording by me with a suggestion
from Tom Lane.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/44f7afba79348883da110642d230a13003b75f62

Modified Files
--
doc/src/sgml/datatype.sgml | 15 ---
1 file changed, 8 insertions(+), 7 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: Assorted code improvements for table partitioning.

[Robert Haas]

Assorted code improvements for table partitioning.

Michael Paquier, per Coverity.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/3633b3f65686d3e74ab868e33bc25bec8bcdc7c6

Modified Files
--
src/backend/catalog/heap.c  |  4 
src/backend/catalog/partition.c |  6 ++
src/bin/pg_dump/pg_dump.c   | 10 --
3 files changed, 18 insertions(+), 2 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: Update copyright for 2017

[David Fetter]

On Wed, Jan 04, 2017 at 11:54:07AM -0800, David Fetter wrote:
> On Wed, Jan 04, 2017 at 02:20:52PM -0500, Tom Lane wrote:
> > David Fetter  writes:
> > >>> Actually, my takeaway from this was "don't ever use git reset on
> > >>> the repo".
> > 
> > > That's actually not tenable.  If we ever find something in our
> > > repo that we don't have full rights to, especially if it's
> > > something that would put roadblocks in front of people who'd like
> > > to make a proprietary fork, we have to be able to expunge it, not
> > > merely paper it over.
> > 
> > What, and re-do every commit after the one that added such material?
> > And somehow find every tarball that was shipped with the material,
> > and make them go away?  Please don't bring straw-man arguments.
> 
> It might sound like a straw man if we hadn't already done this once.
> 
> > >> Except for like Andres says, always check *everything* before
> > >> pushing. I know I always push with -n and then do a git show on that
> > >> resulting set of commits just to make sure it's the one I want. It
> > >> doesn't take a lot of extra time after each commit, and it easily
> > >> finds things like this.
> > 
> > > Do we see a point in the future where all pushes to that repo
> > > require a reviewer separate from the author?  The cost in hassle
> > > and aggravation is, to put it mildly, non-trivial, but it makes
> > > these kinds of mistakes a lot harder to make.
> > 
> > No amount of review will prevent human error at the point of the
> > final push.
> 
> I suggest that it would.

ETOOLITTLECOFFEE

I do *not* suggest it would.

Best,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
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: Remove unnecessary arguments from partitioning functions.

[Robert Haas]

Remove unnecessary arguments from partitioning functions.

RelationGetPartitionQual() and generate_partition_qual() are always
called with recurse = true, so we don't need an argument for that.

Extracted by me from a larger patch by Amit Langote.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/18fc5192a631441a73e6a3b911ecb14765140389

Modified Files
--
src/backend/catalog/partition.c  | 16 
src/backend/commands/tablecmds.c |  2 +-
src/backend/executor/execMain.c  |  3 +--
src/backend/optimizer/util/plancat.c |  2 +-
src/include/catalog/partition.h  |  2 +-
5 files changed, 12 insertions(+), 13 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: Update copyright for 2017

[David Fetter]

On Wed, Jan 04, 2017 at 02:20:52PM -0500, Tom Lane wrote:
> David Fetter  writes:
> >>> Actually, my takeaway from this was "don't ever use git reset on
> >>> the repo".
> 
> > That's actually not tenable.  If we ever find something in our
> > repo that we don't have full rights to, especially if it's
> > something that would put roadblocks in front of people who'd like
> > to make a proprietary fork, we have to be able to expunge it, not
> > merely paper it over.
> 
> What, and re-do every commit after the one that added such material?
> And somehow find every tarball that was shipped with the material,
> and make them go away?  Please don't bring straw-man arguments.

It might sound like a straw man if we hadn't already done this once.

> >> Except for like Andres says, always check *everything* before
> >> pushing. I know I always push with -n and then do a git show on that
> >> resulting set of commits just to make sure it's the one I want. It
> >> doesn't take a lot of extra time after each commit, and it easily
> >> finds things like this.
> 
> > Do we see a point in the future where all pushes to that repo
> > require a reviewer separate from the author?  The cost in hassle
> > and aggravation is, to put it mildly, non-trivial, but it makes
> > these kinds of mistakes a lot harder to make.
> 
> No amount of review will prevent human error at the point of the
> final push.

I suggest that it would.

> Yeah, Bruce was probably unreasonably sloppy about this particular
> commit, but to imagine that we can get the error rate to exactly
> zero is hopeless.

I did not raise that hope.  What I did say was that we could, at a
cost, reduce the rate at which this happens.  It's far from clear to
me that the cost is worth paying at this point.

Best,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
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 reporting of constraint violations for table partitioning.

[Robert Haas]

Fix reporting of constraint violations for table partitioning.

After a tuple is routed to a partition, it has been converted from the
root table's row type to the partition's row type.  ExecConstraints
needs to report the failure using the original tuple and the parent's
tuple descriptor rather than the ones for the selected partition.

Amit Langote

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/f1b4c771ea74f42447dccaed42ffcdcccf3aa694

Modified Files
--
src/backend/commands/copy.c| 11 ++
src/backend/commands/tablecmds.c   |  1 +
src/backend/executor/execMain.c| 67 +-
src/backend/executor/nodeModifyTable.c | 15 +++-
src/include/executor/executor.h|  4 +-
src/include/nodes/execnodes.h  |  1 +
src/test/regress/expected/insert.out   |  7 
src/test/regress/sql/insert.sql|  6 +++
8 files changed, 86 insertions(+), 26 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: Update copyright for 2017

[Tom Lane]

David Fetter  writes:
>>> Actually, my takeaway from this was "don't ever use git reset on
>>> the repo".

> That's actually not tenable.  If we ever find something in our repo
> that we don't have full rights to, especially if it's something that
> would put roadblocks in front of people who'd like to make a
> proprietary fork, we have to be able to expunge it, not merely paper
> it over.

What, and re-do every commit after the one that added such material?
And somehow find every tarball that was shipped with the material, and
make them go away?  Please don't bring straw-man arguments.

>> Except for like Andres says, always check *everything* before
>> pushing. I know I always push with -n and then do a git show on that
>> resulting set of commits just to make sure it's the one I want. It
>> doesn't take a lot of extra time after each commit, and it easily
>> finds things like this.

> Do we see a point in the future where all pushes to that repo require
> a reviewer separate from the author?  The cost in hassle and
> aggravation is, to put it mildly, non-trivial, but it makes these
> kinds of mistakes a lot harder to make.

No amount of review will prevent human error at the point of the final
push.  Yeah, Bruce was probably unreasonably sloppy about this particular
commit, but to imagine that we can get the error rate to exactly zero
is hopeless.  That's what "git revert" is for.

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: Add new TAP tests for pg_recvlogical

[Simon Riggs]

Add new TAP tests for pg_recvlogical

Craig Ringer, reviewed by Euler Taveira and Naoki Okano

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/3e353a7bc2dd6a9edfffe7e045c810b421f7ecc4

Modified Files
--
src/bin/pg_basebackup/Makefile|  2 ++
src/bin/pg_basebackup/t/030_pg_recvlogical.pl | 46 +++
2 files changed, 48 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: Add pg_recvlogical —-endpos=LSN

[Simon Riggs]

Add pg_recvlogical —-endpos=LSN

Allow pg_recvlogical to specify an ending LSN, complementing
the existing -—startpos=LSN option.

Craig Ringer, reviewed by Euler Taveira and Naoki Okano

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/7c030783a5bd07cadffc2a1018bc33119a4c7505

Modified Files
--
doc/src/sgml/ref/pg_recvlogical.sgml   |  34 
src/bin/pg_basebackup/pg_recvlogical.c | 145 +
2 files changed, 164 insertions(+), 15 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: Update copyright for 2017

[David Fetter]

On Wed, Jan 04, 2017 at 04:08:20PM +0100, Magnus Hagander wrote:
> On Wed, Jan 4, 2017 at 4:05 PM, Tom Lane  wrote:
> > Andres Freund  writes:
> > > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
> > >> Yeah, I was doing parallel pulls of different branches in git
> > >> via shell script, and it seems the size of this commit showed
> > >> me that doesn't work.  Sorry.
> >
> > > Shouldn't you check the results of something like this before
> > > pushing?  Sorry for piling on, but that seems like a quite
> > > critical step.
> >
> > Actually, my takeaway from this was "don't ever use git reset on
> > the repo".

That's actually not tenable.  If we ever find something in our repo
that we don't have full rights to, especially if it's something that
would put roadblocks in front of people who'd like to make a
proprietary fork, we have to be able to expunge it, not merely paper
it over.

> > "git revert" would have been much safer.  Yeah, it would have meant that
> > git blame on the 9.2 branch would have some useless noise, but how much
> > does anyone still care about that?
> 
> Possibly this time, but the generic answer is a lot harder.

As above.

> Except for like Andres says, always check *everything* before
> pushing. I know I always push with -n and then do a git show on that
> resulting set of commits just to make sure it's the one I want. It
> doesn't take a lot of extra time after each commit, and it easily
> finds things like this.

Do we see a point in the future where all pushes to that repo require
a reviewer separate from the author?  The cost in hassle and
aggravation is, to put it mildly, non-trivial, but it makes these
kinds of mistakes a lot harder to make.

Best,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
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: Prefer int-wide pg_atomic_flag over char-wide when using gcc int

[Tom Lane]

Prefer int-wide pg_atomic_flag over char-wide when using gcc intrinsics.

configure can only probe the existence of gcc intrinsics, not how well
they're implemented, and unfortunately the answer is sometimes "badly".
In particular we've found that multiple compilers fail to implement
char-width __sync_lock_test_and_set() correctly on PPC; and even a correct
implementation would necessarily be pretty inefficient, since that hardware
has only a word-wide primitive to work with.

Given the knowledge we've accumulated in s_lock.h, it appears that it's
best to rely on int-width TAS operations on most non-Intel architectures.
Hence, pick int not char when both are nominally available to us in
generic-gcc.h (note that that code is not used for x86[_64]).

Back-patch to fix regression test failures on FreeBSD/PPC.  Ordinarily
back-patching a change like this would be verboten because of ABI breakage.
But since pg_atomic_flag is not yet used in any Postgres data structure,
there's no ABI to break.  It seems safer to back-patch to avoid possible
gotchas, if someday we do back-patch something that uses pg_atomic_flag.

Discussion: https://postgr.es/m/25414.1483076...@sss.pgh.pa.us

Branch
--
REL9_6_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/6e5de703b6c791d355936a61abb52b3b1fc6e184

Modified Files
--
src/include/port/atomics/generic-gcc.h | 13 -
1 file changed, 8 insertions(+), 5 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: Prefer int-wide pg_atomic_flag over char-wide when using gcc int

[Tom Lane]

Prefer int-wide pg_atomic_flag over char-wide when using gcc intrinsics.

configure can only probe the existence of gcc intrinsics, not how well
they're implemented, and unfortunately the answer is sometimes "badly".
In particular we've found that multiple compilers fail to implement
char-width __sync_lock_test_and_set() correctly on PPC; and even a correct
implementation would necessarily be pretty inefficient, since that hardware
has only a word-wide primitive to work with.

Given the knowledge we've accumulated in s_lock.h, it appears that it's
best to rely on int-width TAS operations on most non-Intel architectures.
Hence, pick int not char when both are nominally available to us in
generic-gcc.h (note that that code is not used for x86[_64]).

Back-patch to fix regression test failures on FreeBSD/PPC.  Ordinarily
back-patching a change like this would be verboten because of ABI breakage.
But since pg_atomic_flag is not yet used in any Postgres data structure,
there's no ABI to break.  It seems safer to back-patch to avoid possible
gotchas, if someday we do back-patch something that uses pg_atomic_flag.

Discussion: https://postgr.es/m/25414.1483076...@sss.pgh.pa.us

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/698127a4a9bc3c74659bf0e5383b1ed99aeb1570

Modified Files
--
src/include/port/atomics/generic-gcc.h | 13 -
1 file changed, 8 insertions(+), 5 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: Prefer int-wide pg_atomic_flag over char-wide when using gcc int

[Tom Lane]

Prefer int-wide pg_atomic_flag over char-wide when using gcc intrinsics.

configure can only probe the existence of gcc intrinsics, not how well
they're implemented, and unfortunately the answer is sometimes "badly".
In particular we've found that multiple compilers fail to implement
char-width __sync_lock_test_and_set() correctly on PPC; and even a correct
implementation would necessarily be pretty inefficient, since that hardware
has only a word-wide primitive to work with.

Given the knowledge we've accumulated in s_lock.h, it appears that it's
best to rely on int-width TAS operations on most non-Intel architectures.
Hence, pick int not char when both are nominally available to us in
generic-gcc.h (note that that code is not used for x86[_64]).

Back-patch to fix regression test failures on FreeBSD/PPC.  Ordinarily
back-patching a change like this would be verboten because of ABI breakage.
But since pg_atomic_flag is not yet used in any Postgres data structure,
there's no ABI to break.  It seems safer to back-patch to avoid possible
gotchas, if someday we do back-patch something that uses pg_atomic_flag.

Discussion: https://postgr.es/m/25414.1483076...@sss.pgh.pa.us

Branch
--
REL9_5_STABLE

Details
---
http://git.postgresql.org/pg/commitdiff/1ed8335ce04598e63944f063c4dc6a8ab08e47bc

Modified Files
--
src/include/port/atomics/generic-gcc.h | 13 -
1 file changed, 8 insertions(+), 5 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: Move partition_tuple_slot out of EState.

[Robert Haas]

Move partition_tuple_slot out of EState.

Commit 2ac3ef7a01df859c62d0a02333b646d65eaec5ff added a TupleTapleSlot
for partition tuple slot to EState (es_partition_tuple_slot) but it's
more logical to have it as part of ModifyTableState
(mt_partition_tuple_slot) and CopyState (partition_tuple_slot).

Discussion: 
http://postgr.es/m/1bd459d9-4c0c-197a-346e-e5e59e217...@lab.ntt.co.jp

Amit Langote, per a gripe from me

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/345b2dcf070bd8fbccde643b1b2856027623e9e5

Modified Files
--
src/backend/commands/copy.c| 26 +-
src/backend/executor/execMain.c| 12 
src/backend/executor/nodeModifyTable.c | 17 -
src/include/executor/executor.h|  1 +
src/include/nodes/execnodes.h  |  4 +---
5 files changed, 35 insertions(+), 25 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: Re-allow SSL passphrase prompt at server start, but not thereaft

[Tom Lane]

Re-allow SSL passphrase prompt at server start, but not thereafter.

Leave OpenSSL's default passphrase collection callback in place during
the first call of secure_initialize() in server startup.  Although that
doesn't work terribly well in daemon contexts, some people feel we should
not break it for anyone who was successfully using it before.  We still
block passphrase demands during SIGHUP, meaning that you can't adjust SSL
configuration on-the-fly if you used a passphrase, but this is no worse
than what it was before commit de41869b6.  And we block passphrase demands
during EXEC_BACKEND reloads; that behavior wasn't useful either, but at
least now it's documented.

Tweak some related log messages for more readability, and avoid issuing
essentially duplicate messages about reload failure caused by a passphrase.

Discussion: https://postgr.es/m/29982.1483412...@sss.pgh.pa.us

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/6667d9a6d77b9a6eac89638ac363b6d03da253c1

Modified Files
--
doc/src/sgml/runtime.sgml | 19 +---
src/backend/libpq/be-secure-openssl.c | 84 ---
src/backend/libpq/be-secure.c | 10 ++---
src/backend/postmaster/postmaster.c   |  8 ++--
src/include/libpq/libpq-be.h  |  2 +-
src/include/libpq/libpq.h |  2 +-
6 files changed, 72 insertions(+), 53 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: Update obsolete comments in lwlock.h.

[Robert Haas]

Update obsolete comments in lwlock.h.

The typical size of an LWLock is now 16 bytes even on 64-bit platforms,
and the size of slock_t is now irrelevant.  But pg_atomic_uint32 can
(perhaps surprisingly) still be larger than 4 bytes, so there's still
some marginal point to allowing LWLOCK_MINIMAL_SIZE == 64.

Commit 008608b9d51061b1f598c197477b3dc7be9c4a64 made the changes
that led to the need for these updates.

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/0fad355beca9f73687c0b27647ea570ce10c7ae3

Modified Files
--
src/include/storage/lwlock.h | 17 +
1 file changed, 9 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: Add 18 new recovery TAP tests

[Simon Riggs]

Add 18 new recovery TAP tests

Add new tests for physical repl slots and hot standby feedback.

Craig Ringer, reviewed by Aleksander Alekseev and Simon Riggs

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/0813216cb416bf9173ddc7ff3cf495755d943743

Modified Files
--
src/test/recovery/t/001_stream_rep.pl | 105 +-
1 file changed, 104 insertions(+), 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

Re: [COMMITTERS] pgsql: Update copyright for 2017

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund  writes:
> > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
> >> Yeah, I was doing parallel pulls of different branches in git via shell
> >> script, and it seems the size of this commit showed me that doesn't
> >> work.  Sorry.
> 
> > Shouldn't you check the results of something like this before pushing?
> > Sorry for piling on, but that seems like a quite critical step.
> 
> Actually, my takeaway from this was "don't ever use git reset on the repo".
> "git revert" would have been much safer.  Yeah, it would have meant that
> git blame on the 9.2 branch would have some useless noise, but how much
> does anyone still care about that?

+1.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [COMMITTERS] pgsql: Update copyright for 2017

[Magnus Hagander]

On Wed, Jan 4, 2017 at 4:05 PM, Tom Lane  wrote:

> Andres Freund  writes:
> > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
> >> Yeah, I was doing parallel pulls of different branches in git via shell
> >> script, and it seems the size of this commit showed me that doesn't
> >> work.  Sorry.
>
> > Shouldn't you check the results of something like this before pushing?
> > Sorry for piling on, but that seems like a quite critical step.
>
> Actually, my takeaway from this was "don't ever use git reset on the repo".
> "git revert" would have been much safer.  Yeah, it would have meant that
> git blame on the 9.2 branch would have some useless noise, but how much
> does anyone still care about that?
>

Possibly this time, but the generic answer is a lot harder.

If you do a git reset, you pay the one-time cost. Once the (fairly few)
people who managed to pull in between have updated, the problem is gone.

If you do a git revert, the problem stays around forever (but it's a
smaller one).

In the end it's going to be case-by-case. We may have done it wrong this
time, but I don't think we can generally say what's right for the next one.

Except for like Andres says, always check *everything* before pushing. I
know I always push with -n and then do a git show on that resulting set of
commits just to make sure it's the one I want. It doesn't take a lot of
extra time after each commit, and it easily finds things like this.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [COMMITTERS] pgsql: Update copyright for 2017

[Tom Lane]

Andres Freund  writes:
> On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
>> Yeah, I was doing parallel pulls of different branches in git via shell
>> script, and it seems the size of this commit showed me that doesn't
>> work.  Sorry.

> Shouldn't you check the results of something like this before pushing?
> Sorry for piling on, but that seems like a quite critical step.

Actually, my takeaway from this was "don't ever use git reset on the repo".
"git revert" would have been much safer.  Yeah, it would have meant that
git blame on the 9.2 branch would have some useless noise, but how much
does anyone still care about that?

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: Better fix for sequence access in hot standby test

[Peter Eisentraut]

Better fix for sequence access in hot standby test

The purpose of the test was to check access to the sequence relation on
a hot standby, so change the test to read a different column from the
sequence, instead of just reading the catalog.

From: Andreas Karlsson 

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/579f700911794d33d95628266f8ed700f113ee16

Modified Files
--
src/test/regress/expected/hs_standby_allowed.out | 8 
src/test/regress/sql/hs_standby_allowed.sql  | 2 +-
2 files changed, 5 insertions(+), 5 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: Attempt to handle pending-delete files on Windows

[Magnus Hagander]

Attempt to handle pending-delete files on Windows

These files are deleted but not yet gone from the filesystem. Operations
on them will return ERROR_DELETE_PENDING.

With this we start treating that as ENOENT, meaning files does not
exist (which is the state it will soon reach). This should be safe in
every case except when we try to recreate a file with exactly the same
name. This is an operation that PostgreSQL does very seldom, so
hopefully that won't happen much -- and even if it does, this treatment
should be no worse than treating it as an unhandled error.

We've been un able to reproduce the bug reliably, so pushing this to
master to get buildfarm coverage and other testing. Once it's proven to
be stable, it should be considered for backpatching.

Discussion: 
https://postgr.es/m/20160712083220.1426.58667%40wrigleys.postgresql.org

Patch by me and Michael Paquier

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/9951741bbeb3ec37ca50e9ce3df1808c931ff6a6

Modified Files
--
src/port/dirmod.c | 15 +++
src/port/win32error.c |  3 +++
2 files changed, 18 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: Make wal streaming the default mode for pg_basebackup

[Magnus Hagander]

Make wal streaming the default mode for pg_basebackup

Since streaming is now supported for all output formats, make this the
default as this is what most people want.

To get the old behavior, the parameter -X none can be specified to turn
it off.

This also removes the parameter -x for fetch, now requiring -X fetch to
be specified to use that.

Reviewed by Vladimir Rusinov, Michael Paquier and Simon Riggs

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/9a4d51077c96c10322582211781bb969b51822ff

Modified Files
--
doc/src/sgml/ref/pg_basebackup.sgml  | 42 
src/bin/pg_basebackup/pg_basebackup.c| 49 
src/bin/pg_basebackup/t/010_pg_basebackup.pl |  9 +++--
src/test/perl/PostgresNode.pm|  2 +-
4 files changed, 50 insertions(+), 52 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: Update copyright for 2017

[Andres Freund]

On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote:
> Yeah, I was doing parallel pulls of different branches in git via shell
> script, and it seems the size of this commit showed me that doesn't
> work.  Sorry.

Shouldn't you check the results of something like this before pushing?
Sorry for piling on, but that seems like a quite critical step.

Andres


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