Re: Question about SSI, subxacts, and aborted read-only xacts

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Question about SSI, subxacts, and aborted read-only xacts
Дата
Msg-id 5055FB56020000250004A442@gw.wicourts.gov
обсуждение исходный текст
Ответ на Question about SSI, subxacts, and aborted read-only xacts  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: Question about SSI, subxacts, and aborted read-only xacts  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Question about SSI, subxacts, and aborted read-only xacts  (Jeff Davis <pgsql@j-davis.com>)
Re: Question about SSI, subxacts, and aborted read-only xacts  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Jeff Davis  wrote:
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:

>> Do you have any suggested wording [...] ?

> Attached. I thought about putting it as a "note", but it seems like
> it's easy to go overboard with those.

I agree about a note being overkill for this.

I'm attaching an alternative proposal, with changes for the following
reasons:

(1)  The complete re-wrap of that first paragraph made it really hard
to see what the actual change to the documentation was.  I would
rather change it like this and have a separate patch to re-wrap the
paragraph (with no content change) or maybe restrict the reformatting
to two or three lines.

(2)  The second paragraph starts with "There may still be
serialization anomalies involving aborted transactions" which seems
a bit alarming, seems to bend the definition of serialization
anomalies and seems odd to pick out for special attention when the
same could be said of data read in transactions at other isolation
levels if those transactions roll back from a deferred constraint or
a write conflict.

(3)  There is a significant exception to this caveat which I felt
would be useful to people who wanted to generate big reports without
waiting for transaction commit: deferrable read-only transactions
offer applications a way to count on data as soon as it is read.

I'm not sure whether the omission of this from the docs should be
considered a big enough hazard to merit a back-patch, or if it should
just be committed to HEAD.

-Kevin



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [WIP] Patch : Change pg_ident.conf parsing to be the same as pg_hba.conf
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed