On 12/17/2014 03:41 PM, Simon Riggs wrote:
All of this is just a replay of the earlier conversations about
reducing lock levels.
My original patch did reduce lock levels for CREATE TRIGGER, but we
stepped back from doing that in 9.4 until we had feedback as to
whether the whole idea of reducing
On Wed, Dec 17, 2014 at 02:41:39PM +, Simon Riggs wrote:
> Is there anything different here from work in my original patch series?
Not to my knowledge.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On 25 October 2014 19:00, Noah Misch wrote:
>> So I tentatively propose (and with due regard for the possibility
>> others may see dangers that I've missed) that a reasonable goal would
>> be to lower the lock strength required for both CREATE TRIGGER and ADD
>> FOREIGN KEY from AccessExclusiveLo
On 10/28/2014 01:33 AM, Noah Misch wrote:
ALTER TRIGGER is not bad; like you say, change pg_get_triggerdef_worker() the
way commit e5550d5 changed pg_get_constraintdef_worker(). DROP TRIGGER is
more difficult. pg_constraint.tgqual of a dropped trigger may reference other
dropped objects, which
There are actually TWO tables involved: the table upon which
the trigger will actually fire, and some other table which is
mentioned in passing in the trigger definition. It's possible that
the locking requirements for the secondary table are weaker since I
don't think the presence of the trig
On Mon, Oct 27, 2014 at 08:24:15AM -0400, Robert Haas wrote:
> On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch wrote:
> >> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail.gmail.com
> >> http://www.postgresql.org/message-id/20893.1393892...@sss.pgh.pa.us
>
On Sun, Oct 26, 2014 at 9:48 PM, Andreas Karlsson wrote:
> Agreed.. But I think reducing the lock level of the secondary table is much
> more important than doing the same for the primary table due to the case
> where the secondary table is an existing table which is hit by a workload of
> long ru
Thanks for weighing in, Noah.
On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch wrote:
>> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail.gmail.com
>> http://www.postgresql.org/message-id/20893.1393892...@sss.pgh.pa.us
>> http://www.postgresql.org/message-i
On 10/24/2014 06:07 PM, Robert Haas wrote:
I think instead of focusing on foreign keys, we should rewind a bit
and think about the locking level required to add a trigger.
Agreed.
As far as triggers are concerned, the issue of skew between the
transaction snapshot and what the ruleutils.c sna
On Fri, Oct 24, 2014 at 12:07:42PM -0400, Robert Haas wrote:
> I think instead of focusing on foreign keys, we should rewind a bit
> and think about the locking level required to add a trigger.
Agreed.
> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail
On Wed, Oct 22, 2014 at 3:06 AM, Andreas Karlsson wrote:
> I have been thinking about why we need to grab an AccessExclusiveLock on the
> table with the PK when we add a foreign key. Adding new tables with foreign
> keys to old ones is common so it would be really nice if the lock strength
> could
On 10/22/2014 04:13 PM, Tom Lane wrote:
Andreas Karlsson writes:
I have attached a proof of concept
patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
Why would it have to be self-exclusive? As far as I know we only need to
ensu
Andreas Karlsson writes:
> I have attached a proof of concept
> patch which reduces the lock strength to ShareLock.
You're kidding, right? ShareLock isn't even self-exclusive.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Hi,
I have been thinking about why we need to grab an AccessExclusiveLock on
the table with the PK when we add a foreign key. Adding new tables with
foreign keys to old ones is common so it would be really nice if the
lock strength could be reduced.
A comment in the code claims that we need
14 matches
Mail list logo
