Re: ALTER TABLE lock strength reduction patch is unsafe

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Date: 2014-03-04 08:39:28
Message-ID: CAOeZVifePi5ZcoRZPNO3jh=BkrfCYepQwDdgsa1RsSKUp9QEyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> Good points.
>
> In most cases, DDL is applied manually after careful thought, so
> people seldom dump at the same time they upgrade the database. This is
> especially true for pg_dump since it captures the logical definition
> of tables. So most people will be happy with the default locking, but
> we could make the lock level optional.
>
> Currently we use AccessShareLock. Locking out all DDL, even with this
> patch applied would only require ShareUpdateExclusiveLock.
>
> Looking at the code, it will take about an hour to add an option to
> pg_dump that specifies the lock level used when dumping. I would be
> happy to include that as part of this patch.
>

I think the use case for specifying multiple locks is pretty slim given
that a ShareUpdateExclusiveLock is good enough mostly for everybody.

If its not the case, the user should be more careful about when he is
scheduling backups to so that they dont conflict with DDL changes.

I am not too comfortable with exposing the locking type to the user. That
may be just me though.

Regards,

Atri
--
Regards,

Atri
*l'apprenant*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KONDO Mitsumasa 2014-03-04 08:42:08 Re: gaussian distribution pgbench
Previous Message Peter Geoghegan 2014-03-04 08:38:39 Re: jsonb and nested hstore