[HACKERS] Strange behavior with pg_locks and partitioning
All, In the course of debugging why a particular server required increasing max_locks_per_transation, I found a peculiar behavior. If you do an UPDATE which doesn't match any CE constraint on the parent table in an inheritance chain, you get a RowExclusiveLock on every partition and every index on every partition. However, these rowexclusivelocks have no page or tuple reference; it's a RowExclusiveLock with no row. Is this intentional? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Strange behavior with pg_locks and partitioning
On Fri, Jun 15, 2012 at 12:42 PM, Josh Berkus j...@agliodbs.com wrote: In the course of debugging why a particular server required increasing max_locks_per_transation, I found a peculiar behavior. If you do an UPDATE which doesn't match any CE constraint on the parent table in an inheritance chain, you get a RowExclusiveLock on every partition and every index on every partition. However, these rowexclusivelocks have no page or tuple reference; it's a RowExclusiveLock with no row. Is this intentional? RowExclusiveLock is a type of table lock, not a lock on a row. You're going to get that on all tables (and their indexes) involved in any write query. So it sounds unsurprising to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Strange behavior with pg_locks and partitioning
So it sounds unsurprising to me. OK, I'll just submit a note for the docs for max_locks_per_transaction, then. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
