On Tue, Sep 01, 2020 at 09:41:48PM -0500, Justin Pryzby wrote:
> I think you probably intended to write: 1<<2
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
> diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
> index 47d4c07306..23840bb8e6 100644
> --- a/src/include/nodes/parsenodes.h
> +++ b/src/include/nodes/parsenodes.h
> @@ -3352,6 +3352,7 @@ typedef struct ConstraintsSetStmt
> /* Reindex options */
> #define REINDEXOPT
On Tue, Sep 01, 2020 at 01:25:27PM +0300, Anastasia Lubennikova wrote:
> Yes, this version is good.
Thanks. I have added an extra comment for the case of RELKIND_INDEX
with REINDEXOPT_MISSING_OK while on it, as it was not really obvious
why the parent relation needs to be locked (at least attempt
On 01.09.2020 04:38, Michael Paquier wrote:
I have added some extra comments. There is one in
ReindexRelationConcurrently() to mention that there should be no extra
use of MISSING_OK once the list of indexes is built as session locks
are taken where needed.
Great, it took me a moment to understa
On Mon, Aug 31, 2020 at 06:10:46PM +0300, Anastasia Lubennikova wrote:
> I reviewed the patch. It does work and the code is clean and sane. It
> implements a logic that we already had in CLUSTER, so I think it was simply
> an oversight. Thank you for fixing this.
Thanks Anastasia for the review.
On 13.08.2020 07:38, Michael Paquier wrote:
Hi all,
While working on support for REINDEX for partitioned relations, I have
noticed an old bug in the logic of ReindexMultipleTables(): the list
of relations to process is built in a first transaction, and then each
table is done in an independent t
Hi all,
While working on support for REINDEX for partitioned relations, I have
noticed an old bug in the logic of ReindexMultipleTables(): the list
of relations to process is built in a first transaction, and then each
table is done in an independent transaction, but we don't actually
check that t
