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