Re: SetQuerySnapshot() for utility statements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: SetQuerySnapshot() for utility statements
Date: 2000-10-19 18:46:38
Message-ID: 11145.971981198@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> 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 CommandId.

Sure. The example was just to point out that we do have tuple
visibility rules, even in utility statements.

>> 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 it buy for us? MVCC lies to user - it returns view of data
> as they were some time ago. What would we get by seeing old
> view of catalog?

Consistency. For example: pg_dump wants a consistent view of the
database, so it runs in a serializable transaction. To the extent that
it uses utility statements rather than standard SELECTs to look at the
state of the system catalogs, it will get the wrong answer if the
utility statements believe that they can ignore the transaction
isolation mode setting.

I'm not sure that there are any utility statements that would be useful
for pg_dump, but certainly there could be such a thing, no?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vadim Mikheev 2000-10-19 18:55:18 Re: time stops within transaction
Previous Message Matthew H. North 2000-10-19 18:40:23 RE: Automation/scheduling of Backup stratetgy