On 5 April 2015 at 19:19, Michael Paquier wrote:
> Cool! Thanks for showing up.
Visibility <> Activity. How is REINDEX CONCURRENTLY doing?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
--
Sent via pgsql-ha
On 04/05/2015 05:56 PM, Simon Riggs wrote:
Committed. We move forwards, slowly but surely. Thanks for the patch.
Thanks to you and the reviewers for helping me out with this patch!
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Mon, Apr 6, 2015 at 12:56 AM, Simon Riggs wrote:
> On 7 February 2015 at 20:05, Andreas Karlsson wrote:
>> On 01/30/2015 07:48 AM, Michael Paquier wrote:
>>>
>>> Looking at the latest patch, it seems that in
>>> AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
>>> AT_AddC
On 7 February 2015 at 20:05, Andreas Karlsson wrote:
> On 01/30/2015 07:48 AM, Michael Paquier wrote:
>>
>> Looking at the latest patch, it seems that in
>> AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
>> AT_AddConstraintRecurse and AT_ProcessedConstraint under the same
>
On Sun, Feb 8, 2015 at 10:05 AM, Andreas Karlsson wrote:
> On 01/30/2015 07:48 AM, Michael Paquier wrote:
>>
>> Looking at the latest patch, it seems that in
>> AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
>> AT_AddConstraintRecurse and AT_ProcessedConstraint under the sa
On 02/06/2015 08:16 AM, Michael Paquier wrote:
On Fri, Jan 30, 2015 at 10:26 PM, Andreas Karlsson wrote:
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Looking at the latest patch, it seems that in
AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
AT_AddConstraintRecurse an
On Fri, Jan 30, 2015 at 10:26 PM, Andreas Karlsson wrote:
> On 01/30/2015 07:48 AM, Michael Paquier wrote:
>> Looking at the latest patch, it seems that in
>> AlterTableGetLockLevel@tablecmds.c we ought to put AT_ReAddConstraint,
>> AT_AddConstraintRecurse and AT_ProcessedConstraint under the same
On 01/30/2015 07:48 AM, Michael Paquier wrote:
Ok, so the deal is to finally reduce the locks to
ShareRowExclusiveLock for the following commands :
- CREATE TRIGGER
- ALTER TABLE ENABLE/DISABLE
- ALTER TABLE ADD CONSTRAINT
Correct. I personally still find this useful enough to justify a patch.
On Fri, Jan 23, 2015 at 8:55 AM, Andreas Karlsson wrote:
> On 01/22/2015 10:31 PM, Andreas Karlsson wrote:
>>
>> I agree with this view, and am not sure myself that it is worth lowering
>> the lock level of ALTER TRIGGER RENAME. I have attached a patch without
>> the changes to ALTER TRIGGER and r
On 01/20/2015 10:08 AM, Noah Misch wrote:
Fair enough. It did reinforce pg_get_constraintdef() as a subroutine of
pg_dump rather than an independent, rigorous interface. It perhaps made the
function worse for non-pg_dump callers. In that vein, each one of these hacks
has a cost. One could mak
On Fri, Jan 16, 2015 at 04:59:56PM +0100, Andres Freund wrote:
> On 2015-01-16 15:16:20 +0100, Andreas Karlsson wrote:
> > For this reason I opted to only lower the lock levels of ADD and ALTER
> > TRIGGER, and not DROP TRIGGER. Neither of those require MVCC of then
> > WHEN clause.
>
> I'm unconv
On 01/19/2015 06:14 PM, Robert Haas wrote:
On Fri, Jan 16, 2015 at 10:59 AM, Andres Freund wrote:
This will give you: The old trigger name. The new table name. The new
column name. The new function name.
Ouch. That's clearly no good. I'm struggling to understand whether
this is a problem wi
On Fri, Jan 16, 2015 at 10:59 AM, Andres Freund wrote:
> Just consider:
> S1: CREATE TABLE flubber(id serial primary key, data text);
> S1: CREATE FUNCTION blarg() RETURNS TRIGGER LANGUAGE plpgsql AS $$BEGIN
> RETURN NEW; END;$$;
> S1: CREATE TRIGGER flubber_blarg BEFORE INSERT ON flubber FOR EAC
On 2015-01-16 15:16:20 +0100, Andreas Karlsson wrote:
> Indeed. As Noah and I discussed previously in this thread we would need to
> do quite a bit of refactoring of ruleutils.c to make it fully MVCC.
Right.
> For this reason I opted to only lower the lock levels of ADD and ALTER
> TRIGGER, and n
On 01/16/2015 03:01 PM, Andres Freund wrote:
Hi,
/*
-* Grab an exclusive lock on the pk table, so that someone doesn't
delete
-* rows out from under us. (Although a lesser lock would do for that
-* purpose, we'll need exclusive lock anyway to add triggers to the
Hi,
> /*
> - * Grab an exclusive lock on the pk table, so that someone doesn't
> delete
> - * rows out from under us. (Although a lesser lock would do for that
> - * purpose, we'll need exclusive lock anyway to add triggers to the pk
> - * table; trying to start with a l
On 01/14/2015 08:48 AM, Michael Paquier wrote:
All those things gathered give the patch attached. Andreas, if you are
fine with it I think that we could pass it to a committer.
Excellent changes. Thanks for the patch and the reviews.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list
I wrote:
> I think that we could pass it to a committer.
Marked as such.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks for the review.
Here is a new version of the patch with updated isolation tests and
documentation.
--
Andreas Karlsson
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index a0d6867..459e86d 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -908,9 +908,10 @
On Sun, Dec 14, 2014 at 5:45 AM, Andreas Karlsson wrote:
> get_rule_expr() relies heavily on the catcache which to me does not look
> like it could easily be (and probably not even should be) made to use the
> current snapshot. Refactoring ruleutils.c to rely less no the catcache seems
> like a re
I'm not sure about the rest of this but...
On Sat, Dec 13, 2014 at 3:45 PM, Andreas Karlsson wrote:
> Is this patch
> worthwhile even without reducing the lock levels of the drop commands?
Yes! It certainly makes more sense to reduce the lock levels where we
can do that relatively easily, and p
21 matches
Mail list logo
