Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

Поиск
Список
Период
Сортировка
От Fabrízio de Royes Mello
Тема Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Дата
Msg-id CAFcNs+rFpk4btHZ1eFGac49ZNdkjSFFgcMxKZ8MtqQKEOdVBEA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );  (Michael Paquier <michael.paquier@gmail.com>)
Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

On Fri, Jul 24, 2015 at 4:05 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
>
> On Fri, Jul 24, 2015 at 7:11 AM, Fabrízio de Royes Mello
> <fabriziomello@gmail.com> wrote:
> > On Thu, Jul 2, 2015 at 2:03 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >> Looks functionally complete
> >>
> >> Need a test to show that ALTER TABLE works on views, as discussed on this
> >> thread. And confirmation that pg_dump is not broken by this.
> >>
> >> Message-ID:     20140321205828.GB3969106@tornado.leadboat.com
> >>
> >
> > Added more test cases to cover ALTER TABLE on views.
> >
> > I'm thinking about the isolation tests, what about add another 'alter-table'
> > spec for isolation tests enabling and disabling 'autovacuum' options?
>
> Yes, please.
>

Added. I really don't know if my isolation tests are completely correct, is my first time writing this kind of tests.


> > I did some tests using ALTER TABLE on views and also ALTER VIEW and I didn't
> > identify any anomalies.
> >
> >> Needs documentation
> >>
> >
> > Added.
>
>         for (i = 0; boolRelOpts[i].gen.name; i++)
> +       {
> +
> Assert(DoLockModesConflict(boolRelOpts[i].gen.lockmode,
> boolRelOpts[i].gen.lockmode));
>                 j++;
> +       }
>         for (i = 0; intRelOpts[i].gen.name; i++)
> +       {
> +               Assert(DoLockModesConflict(intRelOpts[i].gen.lockmode,
> intRelOpts[i].gen.lockmode));
>                 j++;
> +       }
>         for (i = 0; realRelOpts[i].gen.name; i++)
> +       {
> +
> Assert(DoLockModesConflict(realRelOpts[i].gen.lockmode,
> realRelOpts[i].gen.lockmode));
>                 j++;
> +       }
>         for (i = 0; stringRelOpts[i].gen.name; i++)
> +       {
> +
> Assert(DoLockModesConflict(stringRelOpts[i].gen.lockmode,
> stringRelOpts[i].gen.lockmode));
>                 j++;
> +       }
> Splitting those long lines into two will avoid some work for pgindent.
>

Fixed.


> +GetRelOptionsLockLevel(List *defList)
> +{
> +       LOCKMODE    lockmode = NoLock;
> Shouldn't this default to AccessExclusiveLock instead of NoLock?
>

No, because it will break the logic bellow (get the highest locklevel according the defList), but I force return an AccessExclusiveLock if "defList == NIL".

Thanks for reviewing.

Regards,


*** This work is funded by Zenvia Mobile Results (http://www.zenvia.com.br)

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: TAP tests are badly named