From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ALTER TABLE transaction isolation problem |
Date: | 2013-09-03 14:42:06 |
Message-ID: | 1378219326061-5769393.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kevin Grittner-5 wrote
>> [ Examples shows that both SERIALIZABLE and REPEATABLE READ
>> transactions could see an empty table which was not empty as of
>> the point the snapshot was taken. For that matter, it was not
>> empty at any later point, either. ]
>
> Why don't we rewrite tuples with their existing xid in such cases?
> The current state of affairs seem to me to be a pretty clear bug.
In the ADD COLUMN scenario this results in the new column being visible when
it technically should not be but that is not likely a huge concern.
In the DROP COLUMN scenario you can no longer see data which should
technically be present. I guess if you go to use that data and it is not
present you'd get an error which is the technically correct response anyway
so probably not a huge concern either.
The idea of altering a record but not updating its xid sounds unclean but
I'm not able to evaluate any potential pitfalls of such an action.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/ALTER-TABLE-transaction-isolation-problem-tp5769289p5769393.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Nix | 2013-09-03 14:44:35 | Creating a very simple extension causing: ERROR: could not open file "base/6064585/9440403": No such file or directory |
Previous Message | Kevin Grittner | 2013-09-03 14:29:28 | Re: ALTER TABLE transaction isolation problem |