Re: [GENERAL] Serializable isolation -- are predicate locks stillheld across all databases?
| От | Karl O. Pinc |
|---|---|
| Тема | Re: [GENERAL] Serializable isolation -- are predicate locks stillheld across all databases? |
| Дата | |
| Msg-id | 20170519065646.7ca479ac@slate.meme.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Serializable isolation -- are predicate locks stillheld across all databases? ("Karl O. Pinc" <kop@meme.com>) |
| Ответы |
Re: [GENERAL] Serializable isolation -- are predicate locks stillheld across all databases?
|
| Список | pgsql-general |
On Fri, 19 May 2017 01:52:00 -0500
"Karl O. Pinc" <kop@meme.com> wrote:
> On Thu, 18 May 2017 12:04:42 -0500
> Kevin Grittner <kgrittn@gmail.com> wrote:
>
> > On Thu, May 18, 2017 at 11:07 AM, Karl O. Pinc <kop@meme.com> wrote:
> >
> > > ... Does PG
> > > now pay attention to database in it's SSI implementation?
> >
> > Well, it pays attention as far as the scope of each lock, but there
> > is only one variable to track how far back the oldest transaction ID
> > for a running serializable transaction goes, which is used in
> > cleanup of old locks.
> > ... It's the
> > first time I've heard of someone with this particular issue, so at
> > this point I'm inclined to recommend the workaround of using a
> > separate cluster
I think if I was to make an argument for doing something it would
be based on reliability -- how many users can you give their
own database before somebody leaves an open transaction hanging?
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
В списке pgsql-general по дате отправления: