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:
On 25 October 2014 19:00, Noah Misch n...@leadboat.com 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
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
Thanks for weighing in, Noah.
On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch n...@leadboat.com 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 andr...@proxel.se 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
On Mon, Oct 27, 2014 at 08:24:15AM -0400, Robert Haas wrote:
On Sat, Oct 25, 2014 at 2:00 PM, Noah Misch n...@leadboat.com wrote:
http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail.gmail.com
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
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.
On Wed, Oct 22, 2014 at 3:06 AM, Andreas Karlsson andr...@proxel.se 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
On 10/22/2014 04:13 PM, Tom Lane wrote:
Andreas Karlsson andr...@proxel.se 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
Andreas Karlsson andr...@proxel.se 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
13 matches
Mail list logo
