> >> though we use a lot of table-level locking rather than true MVCC
> >> behavior for schema changes, ISTM that we still have to play by all the
> >> rules when it comes to tuple visibility. In particular I suspect we
> >> ought to be using standard query snapshot behavior...
>
> > What would i
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
>> bar would see the changes the first loop iteration had made. So even
> ^^^
> Snapshot defines visibility of changes made by other transactions.
> Seems that you talk here about self-visibility, defined by Comm
> >> Seems to me this is very broken. Isn't a query snapshot needed for
> >> any utility command that might do database accesses?
>
> > Not needed. We don't support multi-versioning for schema operations.
>
> No? Seems to me we're almost there. Look for instance at that DROP
> USER bug I just
> I notice that ProcessUtility() calls SetQuerySnapshot() for FETCH
> and COPY TO statements, and nothing else.
>
> Seems to me this is very broken. Isn't a query snapshot needed for
> any utility command that might do database accesses?
Not needed. We don't support multi-versioning for schema o
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Seems to me this is very broken. Isn't a query snapshot needed for
>> any utility command that might do database accesses?
> Not needed. We don't support multi-versioning for schema operations.
No? Seems to me we're almost there. Look for instan
> I notice that ProcessUtility() calls SetQuerySnapshot() for FETCH
> and COPY TO statements, and nothing else.
>
> Seems to me this is very broken. Isn't a query snapshot needed for
> any utility command that might do database accesses?
Not needed. We don't support multi-versioning for schema o
I notice that ProcessUtility() calls SetQuerySnapshot() for FETCH
and COPY TO statements, and nothing else.
Seems to me this is very broken. Isn't a query snapshot needed for
any utility command that might do database accesses?
regards, tom lane
