pgsql: Update comments about progress reporting by index_drop

2019-10-18 Thread Alvaro Herrera
Update comments about progress reporting by index_drop Michaël Paquier complained that index_drop is requesting progress reporting for non-obvious reasons, so let's add a comment to explain why. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Detail

pgsql: Update comments about progress reporting by index_drop

2019-10-18 Thread Alvaro Herrera
Update comments about progress reporting by index_drop Michaël Paquier complained that index_drop is requesting progress reporting for non-obvious reasons, so let's add a comment to explain why. Discussion: https://postgr.es/m/[email protected] Branch -- master Details -

pgsql: Fix typo

2019-10-18 Thread Alvaro Herrera
Fix typo Apparently while this code was being developed, ReindexRelationConcurrently operated on multiple relations. The version that was ultimately pushed doesn't, so this comment's use of plural is inaccurate. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/89403

pgsql: Fix typo

2019-10-18 Thread Alvaro Herrera
Fix typo Apparently while this code was being developed, ReindexRelationConcurrently operated on multiple relations. The version that was ultimately pushed doesn't, so this comment's use of plural is inaccurate. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdif

pgsql: Make crash recovery ignore recovery_min_apply_delay setting.

2019-10-18 Thread Fujii Masao
Make crash recovery ignore recovery_min_apply_delay setting. In v11 or before, this setting could not take effect in crash recovery because it's specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9a8 integrated recovery.conf into postgresql.conf an

pgsql: Make crash recovery ignore recovery_min_apply_delay setting.

2019-10-18 Thread Fujii Masao
Make crash recovery ignore recovery_min_apply_delay setting. In v11 or before, this setting could not take effect in crash recovery because it's specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9a8 integrated recovery.conf into postgresql.conf an

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

pgsql: Fix failure of archive recovery with recovery_min_apply_delay en

2019-10-18 Thread Fujii Masao
Fix failure of archive recovery with recovery_min_apply_delay enabled. recovery_min_apply_delay parameter is intended for use with streaming replication deployments. However, the document clearly explains that the parameter will be honored in all cases if it's specified. So it should take effect e

Re: pgsql: doc: Further clarify how recovery target parameters are applied

2019-10-18 Thread Fujii Masao
On Mon, Sep 30, 2019 at 10:14 PM Fujii Masao wrote: > > On Mon, Sep 30, 2019 at 6:10 AM Peter Eisentraut wrote: > > > > doc: Further clarify how recovery target parameters are applied > > > > Recovery target parameters are all applied even in standby mode. The > > previous documentation mostly w

pgsql: Remove last traces of heap_open/close in the tree

2019-10-18 Thread Michael Paquier
Remove last traces of heap_open/close in the tree Since pluggable storage has been introduced, those two routines have been replaced by table_open/close, with some compatibility macros still present to allow extensions to compile correctly with v12. Some code paths using the old routines still re

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: Use standard compare_exchange loop style in ProcArrayGroupClearX

2019-10-18 Thread Noah Misch
Use standard compare_exchange loop style in ProcArrayGroupClearXid(). Besides style, this might improve performance in the contended case. Reviewed by Amit Kapila. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgre

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the

pgsql: For all ppc compilers, implement compare_exchange and fetch_add

2019-10-18 Thread Noah Misch
For all ppc compilers, implement compare_exchange and fetch_add with asm. This is more like how we handle s_lock.h and arch-x86.h. Reviewed by Tom Lane. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/

pgsql: For PowerPC instruction "addi", use constraint "b".

2019-10-18 Thread Noah Misch
For PowerPC instruction "addi", use constraint "b". Without "b", a variant of the tas() code miscompiles on macOS 10.4. This may also fix a compilation failure involving macOS 10.1. Today's compilers have been allocating acceptable registers with or without this change, but this future-proofs the