On Thu, Oct 25, 2018 at 4:41 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:
>
> On 17/10/2018 23:11, Peter Eisentraut wrote:
> > On 13/10/2018 04:01, Andres Freund wrote:
> >> I don't see how this could be argued. It has to be a self-conflicting
> >> lockmode, otherwise you'd end up doing renames of tables where you
> >> cannot see the previous state. And you'd get weird errors about updating
> >> invisible rows etc.
> >
> >> I don't buy this description. Imo it's a fundamental correctness
> >> thing. Without it concurrent DDL would potentially overwrite the rename,
> >> because they could start updating while still seeing the old version.
> >
> > OK, I can refine those descriptions/comments. Do you have any concerns
> > about the underlying principle of this patch?
>
> Patch with updated comments to reflect your input.
>
Great... this patch will help a lot so I took the liberty to perform some review:
- the doc and code (simple) looks good
- the patch apply cleanly against current master
- all tests (check and check-world) past without any issue
I also perform some test using DDLs and DMLs in various sessions:
- renaming indexes / dml against same table
- creating and renaming indexes / altering tables in other session
- renaming indexes / dropping indexes
I didn't found any issue, so the patch looks in a very good shape.
Regards,
--
Fabrízio de Royes Mello Timbira -
http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
