Re: Range Types - typo + NULL string constructor
От | Heikki Linnakangas |
---|---|
Тема | Re: Range Types - typo + NULL string constructor |
Дата | |
Msg-id | 4EA82CBC.3050601@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Range Types - typo + NULL string constructor (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Range Types - typo + NULL string constructor
Re: Range Types - typo + NULL string constructor |
Список | pgsql-hackers |
On 26.10.2011 18:42, Robert Haas wrote: > On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis<pgsql@j-davis.com> wrote: >> Aren't there a few other cases like this floating around the code? I >> know the single-xid cache is potentially vulnerable to xid wraparound >> for the same reason. > > I believe that we're in trouble with XIDs as soon as you have two > active XIDs that are separated by a billion, ... That's not what Jeff is referring to here, though (correct me if I'm wrong). He's talking about the one-item cache in TransactionIdLogFetch(). You don't need need long-running transactions for that to get confused. Specifically, this could happen: 1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT; The row has xmin = 123456, and it is cached as committedin the one-item cache by TransactionLogFetch. 2. A lot of time passes. Everything is frozen, and XID wrap-around happens. (Session A is idle but not in a transaction, so it doesn't inhibit freezing.) 3. In session B: BEGIN: INSERT INTO foo (id) VALUES (2); ROLLBACK; By coincidence, this transaction was assigned XID 123456. 4. In session A: SELECT * FROM foo WHERE id = 2; The one-item cache still says that 123456 committed, so we return the tuple inserted by the aborted transaction. Oops. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: