On 05/15/2013 07:30 AM, Tom Lane wrote:
> Hannu Krosing <hannu@krosing.net> writes:
>> Has anybody looked into making syscache MVCC compliant ?
> This is the wrong statement of the question.
>
> The right statement is "how would you like backend A to be updating
> table T in compliance with a view of table T's schema that is obsolete
> because of backend B's already-committed DDL changes?"
Could we not treat it the same way we treat updated rows in
serializable transaction mode ? That is rollback and let the
client retry if it so wishes ?
> For example, ignoring a just-committed CHECK constraint because it's not visible
> to your transaction's snapshot.
Is there anything in SQL standard that tells us to handle schema changes
in parallel to DML in any other way than by rollback ?
I agree it is nice to have a way to carry on in this case, but there is
only
so much you can sensibly do. For example I can see no good way to handle
parallel DROP COLUMN, especially if you are trying to update that same
column
based on your old snapshot.
> The point of SnapshotNow catalog lookups is to be sure that we see the
> current definition of a table whether or not we're in a transaction
> whose snapshot precedes the last DDL change to that table.
Can't we just detect that "there have been changes" and rollback if trying
any DML on changed tables. It does not seem like something what happens
too often.
> There might
> be some other way to deal with that consistency problem, but just
> changing syscache's behavior is not going to make things better.
I was targeting mainly the read-only case of querying data from a changed
table. I have not checked how SnapshotNow catalog handle this, but I guess
it is not trivial in case there have been changes to catalog since the
active snapshot was taken.
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ