Re: BUG #12469: pg_locks shows locks held by pids not found i n pg_stat_activity or ps

From: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #12469: pg_locks shows locks held by pids not found i n pg_stat_activity or ps
Date: 2015-01-09 19:02:53
Message-ID: 20150109130253.523c250c@slate.meme.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, 9 Jan 2015 18:38:36 +0000 (UTC)
Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

> Karl O. Pinc <kop(at)meme(dot)com> wrote:

> > It would be nice if pg were clever enough to isolate transactions
> > within databases.
>
> Good point. That would complicate the logic a bit, but it might be
> worth it. I'll make a note to look at that as a potential
> enhancement. Thanks!

Rather than figure it out dynamically at transaction commit/lock
release time you could have those operations that alter things
common to all dbs (the postgres db?) add a flag to the transaction
itself. Then the actual commit/lock release is fast. And it's
not (I suppose) all that often that things change that are
"cross-database data" so them down very slightly shouldn't
be an issue.

Just a thought. (I'd know whether it makes sense if I'd
looked at the code. ;-)

Thanks for the attention.

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2015-01-09 19:09:31 Re: BUG #12469: pg_locks shows locks held by pids not found i n pg_stat_activity or ps
Previous Message Marko Tiikkaja 2015-01-09 18:44:28 Re: BUG #12469: pg_locks shows locks held by pids not found i n pg_stat_activity or ps