Re: Commits 8de72b and 5457a1 (COPY FREEZE)
От | Tom Lane |
---|---|
Тема | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Дата | |
Msg-id | 18997.1354754588@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Commits 8de72b and 5457a1 (COPY FREEZE) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Re: Commits 8de72b and 5457a1 (COPY FREEZE) Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql@j-davis.com> wrote: >> After reading that thread, I still don't understand why it's unsafe to >> set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would >> think that a sufficiently narrow case -- such as CTAS outside of a >> transaction block -- would be safe, along with some slightly broader >> cases (like BEGIN; CREATE TABLE; INSERT/COPY). > I haven't looked at the committed patch - which seemed a bit > precipitous to me given the stage the discussion was at - but I > believe the general issue with HEAP_XMIN_COMMITTED is that there might > be other snapshots in the same transaction, for example from open > cursors. From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED couldn't possibly be from its own transaction, and thus it doesn't make the tests that would be appropriate for a tuple that is from the current transaction. Maybe it's all right anyway (i.e. if we should always treat such a tuple as good) but I don't recall exactly what's tested in those paths. regards, tom lane
В списке pgsql-hackers по дате отправления: