pgsql: Stop bgworkers during fast shutdown with postmaster in startup p

2018-08-29 Thread Michael Paquier
Stop bgworkers during fast shutdown with postmaster in startup phase

When a postmaster gets into its phase PM_STARTUP, it would start
background workers using BgWorkerStart_PostmasterStart mode immediately,
which would cause problems for a fast shutdown as the postmaster forgets
to send SIGTERM to already-started background workers.  With smart and
immediate shutdowns, this correctly happened, and fast shutdown is the
only mode missing the shot.

Author: Alexander Kukushkin
Reviewed-by: Michael Paquier
Discussion: 
https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vu9gyn8uv...@mail.gmail.com
Backpatch-through: 9.5

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/55875b6d2aa0946226e9261ee691cb519d92f8c1

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



pgsql: Stop bgworkers during fast shutdown with postmaster in startup p

2018-08-29 Thread Michael Paquier
Stop bgworkers during fast shutdown with postmaster in startup phase

When a postmaster gets into its phase PM_STARTUP, it would start
background workers using BgWorkerStart_PostmasterStart mode immediately,
which would cause problems for a fast shutdown as the postmaster forgets
to send SIGTERM to already-started background workers.  With smart and
immediate shutdowns, this correctly happened, and fast shutdown is the
only mode missing the shot.

Author: Alexander Kukushkin
Reviewed-by: Michael Paquier
Discussion: 
https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vu9gyn8uv...@mail.gmail.com
Backpatch-through: 9.5

Branch
--
REL9_6_STABLE

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

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



pgsql: Stop bgworkers during fast shutdown with postmaster in startup p

2018-08-29 Thread Michael Paquier
Stop bgworkers during fast shutdown with postmaster in startup phase

When a postmaster gets into its phase PM_STARTUP, it would start
background workers using BgWorkerStart_PostmasterStart mode immediately,
which would cause problems for a fast shutdown as the postmaster forgets
to send SIGTERM to already-started background workers.  With smart and
immediate shutdowns, this correctly happened, and fast shutdown is the
only mode missing the shot.

Author: Alexander Kukushkin
Reviewed-by: Michael Paquier
Discussion: 
https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vu9gyn8uv...@mail.gmail.com
Backpatch-through: 9.5

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/35622f7d3210f251c507e77730a3f18246629a95

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



pgsql: Stop bgworkers during fast shutdown with postmaster in startup p

2018-08-29 Thread Michael Paquier
Stop bgworkers during fast shutdown with postmaster in startup phase

When a postmaster gets into its phase PM_STARTUP, it would start
background workers using BgWorkerStart_PostmasterStart mode immediately,
which would cause problems for a fast shutdown as the postmaster forgets
to send SIGTERM to already-started background workers.  With smart and
immediate shutdowns, this correctly happened, and fast shutdown is the
only mode missing the shot.

Author: Alexander Kukushkin
Reviewed-by: Michael Paquier
Discussion: 
https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vu9gyn8uv...@mail.gmail.com
Backpatch-through: 9.5

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/89f562ae10c53c767f3c6c23820022230c641692

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



pgsql: Stop bgworkers during fast shutdown with postmaster in startup p

2018-08-29 Thread Michael Paquier
Stop bgworkers during fast shutdown with postmaster in startup phase

When a postmaster gets into its phase PM_STARTUP, it would start
background workers using BgWorkerStart_PostmasterStart mode immediately,
which would cause problems for a fast shutdown as the postmaster forgets
to send SIGTERM to already-started background workers.  With smart and
immediate shutdowns, this correctly happened, and fast shutdown is the
only mode missing the shot.

Author: Alexander Kukushkin
Reviewed-by: Michael Paquier
Discussion: 
https://postgr.es/m/CAFh8B=mvnD8+DZUfzpi50DoaDfZRDfd7S=gwj5vu9gyn8uv...@mail.gmail.com
Backpatch-through: 9.5

Branch
--
REL9_5_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/32f2792eb6163ce7265b22dad4a20ddd1b81c5eb

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



Re: pgsql: Rework option set of vacuumlo

2018-08-29 Thread Michael Paquier
On Tue, Aug 28, 2018 at 05:47:47PM -0400, Tom Lane wrote:
> I didn't want to backpatch further than v11 without a test case that would
> work in those branches, and I lacked one.  If you've got out-of-core code
> you could verify it with, please do that and back-patch further.

Was there any need to patch v11 with that actually?  As there is nothing
which needs except HEAD that does not seem strictly necessary.

I have reviewed the modules I have, and actually it seems that I would
not need much of that for a back-patch.  One reason being that most of
my TAP tests need pg_regress so as nodes can be initialized so this
needs an external installation anyway.  Maybe others have more thoughts
to offer and would prefer a back-patch.
--
Michael


signature.asc
Description: PGP signature


Re: pgsql: Rework option set of vacuumlo

2018-08-29 Thread Tom Lane
Michael Paquier  writes:
> On Tue, Aug 28, 2018 at 05:47:47PM -0400, Tom Lane wrote:
>> I didn't want to backpatch further than v11 without a test case that would
>> work in those branches, and I lacked one.  If you've got out-of-core code
>> you could verify it with, please do that and back-patch further.

> Was there any need to patch v11 with that actually?

I figured that patching v11 was safe without further testing, because
HEAD has hardly diverged from that.  Previous branches probably should
get tested in some fashion before back-patching, and I didn't have a
good test case, so I didn't.  But I suspect that a back-patch would
be worthwhile because (a) external modules would like to rely on such
infrastructure and/or (b) we might like to back-patch test cases for
contrib modules.  However ...

> I have reviewed the modules I have, and actually it seems that I would
> not need much of that for a back-patch.  One reason being that most of
> my TAP tests need pg_regress so as nodes can be initialized so this
> needs an external installation anyway.

... if there's other missing pieces then neither (a) nor (b) is very
compelling.

regards, tom lane



pgsql: Fix IndexInfo comments.

2018-08-29 Thread Heikki Linnakangas
Fix IndexInfo comments.

Recently, ii_KeyAttrNumbers was renamed to ii_IndexAttrNumbers, and ii_Am
field was added, but the comments were not updated.

Author: Yugo Nagata
Discussion: 
https://www.postgresql.org/message-id/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/4b035841a1bcaadbe4f9e0e174aef773a4fa41f6

Modified Files
--
src/include/nodes/execnodes.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)



pgsql: Fix IndexInfo comments.

2018-08-29 Thread Heikki Linnakangas
Fix IndexInfo comments.

Recently, ii_KeyAttrNumbers was renamed to ii_IndexAttrNumbers, and ii_Am
field was added, but the comments were not updated.

Author: Yugo Nagata
Discussion: 
https://www.postgresql.org/message-id/[email protected]

Branch
--
REL_11_STABLE

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

Modified Files
--
src/include/nodes/execnodes.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)



pgsql: Error position support for defaults and check constraints

2018-08-29 Thread Peter Eisentraut
Error position support for defaults and check constraints

Add support for error position reporting for the expressions contained
in defaults and check constraint definitions.  This currently works only
for CREATE TABLE, not ALTER TABLE, because the latter is not set up to
pass around the original query string.

Reviewed-by: Fabien COELHO 

Branch
--
master

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

Modified Files
--
src/backend/catalog/heap.c | 4 +++-
src/backend/commands/tablecmds.c   | 9 +
src/include/catalog/heap.h | 3 ++-
src/test/regress/output/constraints.source | 2 ++
4 files changed, 12 insertions(+), 6 deletions(-)



pgsql: Error position support for partition specifications

2018-08-29 Thread Peter Eisentraut
Error position support for partition specifications

Add support for error position reporting for partition specifications.

Reviewed-by: Fabien COELHO 

Branch
--
master

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

Modified Files
--
src/backend/commands/tablecmds.c   | 16 +++-
src/test/regress/expected/create_table.out |  6 ++
2 files changed, 17 insertions(+), 5 deletions(-)