Re: serializable read only deferrable

Tom Lane wrote:
> "Kevin Grittner" writes:
>> I'm reviving the discussion on the subject topic because I just
>> had an epiphany which makes it seem simple to implement. The
>> concept of this is that if you start a SERIALIZABLE READ ONLY
>> transaction in an SSI environment when certain conditions are
>> true, it doesn't need to acquire predicate locks or test for
>> rw-conflicts.
>
> I assume this would have to be a "hard" definition of READ ONLY,
> not the rather squishy definition we use now? How would we manage
> the compatibility implications?

If there are issues with whether READ ONLY covers the right ground,
it's likely to affect more than this particular issue -- I've taken
advantage of the READ ONLY property of transactions to allow quite a
few novel optimizations to SSI beyond what is presented in Cahill's
doctoral work.

I'm excluding temporary tables from SSI on the grounds that they are
only read and written by a single transaction and therefore can't be
a source of rw-dependencies, and I'm excluding system tables on the
grounds that they don't follow normal snapshot isolation rules. Hint
bit rewrites are not an issue for SSI. Are there any other squishy
aspect I might need to consider?

-Kevin

I wrote:
> Tom Lane wrote:

>> I assume this would have to be a "hard" definition of READ ONLY,
>> not the rather squishy definition we use now?

> I'm excluding temporary tables from SSI on the grounds that they
> are only read and written by a single transaction and therefore
> can't be a source of rw-dependencies, and I'm excluding system
> tables on the grounds that they don't follow normal snapshot
> isolation rules. Hint bit rewrites are not an issue for SSI. Are
> there any other squishy aspect I might need to consider?

I reviewed the documentation and played around with this a bit and
can't find any areas where the current PostgreSQL implementation of
READ ONLY is incompatible with what is needed for the SSI
optimizations where it is used. There are a large number of tests
which exercise this, and they're all passing.

Did you have something in particular in mind which I should check?
An example of code you think might break would be ideal, but
anything more concrete than the word "squishy" would be welcome.

Any thoughts on the original question about what to use as a
heavyweight lock to support the subject feature?

-Kevin

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I reviewed the documentation and played around with this a bit and
> can't find any areas where the current PostgreSQL implementation of
> READ ONLY is incompatible with what is needed for the SSI
> optimizations where it is used. There are a large number of tests
> which exercise this, and they're all passing.

> Did you have something in particular in mind which I should check?

I did not, just thought it was a point that merited examination.

regards, tom lane