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
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 |