Re: Transaction locks on first insert into partitioned table partition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Lund Askøe <martinlundaskoe(at)gmail(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, pgsql-novice(at)lists(dot)postgresql(dot)org
Subject: Re: Transaction locks on first insert into partitioned table partition
Date: 2019-06-08 23:04:32
Message-ID: 7639.1560035072@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

=?UTF-8?Q?Martin_Lund_Ask=C3=B8e?= <martinlundaskoe(at)gmail(dot)com> writes:
> It feels like a bug to me, that the relcache entry update leaves my
> transaction with an access shared lock.

It is not a bug. The fact that the uncommitted insert takes a lock
preventing any DDL changing the partition structure is actually an
essential property, because otherwise such DDL could perhaps change
which partition the inserted row should have gone into. The DDL
command would then be responsible for moving rows appropriately ...
but it can't see an uncommitted row from another session, so it
would fail to move it. Result: corrupted data.

It might be possible to draw some lines around which sorts of
partition-changing DDL could result in that sort of change, allowing
more fine-grained locking. But we don't have any mechanism for that
right now, and I'm not really sure that it'd be cost-effective to
draw finer distinctions.

regards, tom lane

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message David Rowley 2019-06-09 00:28:10 Re: Transaction locks on first insert into partitioned table partition
Previous Message Martin Lund Askøe 2019-06-08 20:30:29 Re: Transaction locks on first insert into partitioned table partition