| From: | Neil Harkins <nharkins(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: concurrent SELECT blocking ALTER? |
| Date: | 2014-01-29 22:37:39 |
| Message-ID: | CAMtfGdWzOn1KHA-mwE1Xz-dXY=81rwK47_n1ivzEn6iy1d0Faw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I totally understand DDL taking exclusive locks, the problem here seems to
be that the *SELECTs* are taking out exclusive locks, locking out the
ALTER, which feels like a bug.
On Wednesday, January 29, 2014, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 1/29/14, 4:59 PM, Neil Harkins wrote:
> > Why are those exclusive locks present?
> > Can't the database rely on mvcc for those reads
> > without locking? The autocommit should be
> > increasing the xid used for the reads, so the
> > ALTER should be able to slip in-between?
>
> One would think so, but it's more complicated. There is a long thread
> on pgsql-hackers spreading over many months that discusses the
> intricacies of reducing the strength of the locks taken by DDL commands.
> This is being addressed, but at the moment most DDL commands take
> exclusive locks.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2014-01-29 22:51:00 | Re: concurrent SELECT blocking ALTER? |
| Previous Message | Peter Eisentraut | 2014-01-29 22:32:39 | Re: concurrent SELECT blocking ALTER? |