> I went through this thread. I don't quite agree with the proposed
> patch. I think construction like
>
> BEGIN ISOLATION LEVEL ... ; WAIT FOR LSN ...; do the work
>
> should work at any isolation level. v4 patch makes it work with READ
> COMMITTED, but fail with higher levels. I think this is undesired
> asymmetry.
I don't think there is a good use-case here where someone will do:
BEGIN ISOLATION LEVEL REPEATBLE READ; WAIT FOR LSN ...;
SELECT ...
but, perhaps it's better to be more flexible here. So, I'm ok with proceeding
with your suggestion.
> I suggest we should better fix the docs. The attached v5 patch does
> it. Additionally it makes errdetail() about the isolation level
> conditional and shown only on isolation levels higher than READ
> COMMITTED.
The existing error message is:
```
errmsg("WAIT must be called without an active or registered snapshot")
```
and v5 uses the same terminology in the documentation:
```
<command>DO</command> block. It also requires that no active or
registered snapshot be held.
```
The terms "active snapshot" and "registered snapshot" describe internal
snapshot states, and don't seem appropriate for user-facing docs/error
messages.
For example, the COPY documentation instead refers to "snapshots held
by this transaction".
Could we instead use:
```
errmsg("WAIT cannot be executed while the current transaction
holds a snapshot")
```
and change the documentation to:
```
<command>DO</command> block. It also cannot be executed while the
current transaction holds a snapshot. A transaction running at an
isolation level higher than <literal>READ COMMITTED</literal> holds
one from its first query until it ends ....
```
--
Sami Imseih
Amazon Web Services (AWS)
