Re: should CREATE INDEX ON partitioned_table call PreventInTransactionBlock() ?

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: should CREATE INDEX ON partitioned_table call PreventInTransactionBlock() ?
Date: 2020-06-08 15:27:26
Message-ID: 20200608152726.GA7241@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Jun-08, Justin Pryzby wrote:

> This blocks writes to all partitions until commit:
>
> postgres=# begin; CREATE INDEX ON pt(i);
> BEGIN
> CREATE INDEX
>
> Compare with CLUSTER rel1, rel2, ..., and REINDEX {SCHEMA|DATABASE|SYSTEM},
> which release their locks as soon as each rel is processed.

Well, that would also require that transactions are committed and
started for each partition. Merely adding PreventInTransactionBlock
would not do that. Moreover, since this would break DDL-in-transactions
that would otherwise work, it should be optional and thus need a keyword
in the command. But CONCURRENTLY isn't it (because that means something
else) so we'd have to discuss what it would be.

> I noticed while implementing REINDEX for partitioned tables, which, it seems
> clear, should also avoid slowly accumulating more and more write locks across
> an entire partition heirarchy.

Right.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-06-08 15:40:45 Re: should CREATE INDEX ON partitioned_table call PreventInTransactionBlock() ?
Previous Message Tom Lane 2020-06-08 15:19:25 Re: snowball release