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

2020-06-08 Thread Alvaro Herrera
On 2020-Jun-08, Justin Pryzby wrote: > On Mon, Jun 08, 2020 at 11:27:26AM -0400, Alvaro Herrera wrote: > > 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

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

2020-06-08 Thread Justin Pryzby
On Mon, Jun 08, 2020 at 11:27:26AM -0400, Alvaro Herrera wrote: > 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

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

2020-06-08 Thread Alvaro Herrera
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

should CREATE INDEX ON partitioned_table call PreventInTransactionBlock() ?

2020-06-08 Thread Justin Pryzby
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. I noticed while implementing REINDEX for