Re: Vacuum dead tuples that are "between" transactions
От | Simon Riggs |
---|---|
Тема | Re: Vacuum dead tuples that are "between" transactions |
Дата | |
Msg-id | 1141232565.27729.379.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Vacuum dead tuples that are "between" ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Wisconsin Court Systems software
|
Список | pgsql-hackers |
On Wed, 2006-03-01 at 10:22 -0600, Kevin Grittner wrote: > >>> On Tue, Feb 28, 2006 at 7:22 am, in message > <1141132955.27729.119.camel@localhost.localdomain>, Simon Riggs > <simon@2ndquadrant.com> wrote: > > > > OTOH a few hackers discussed this recently and found that nobody > used > > serializable transactions (ST) except during pg_dump. > > I've not been able to keep up with all messages on these lists, and I > missed that discussion. It was a verbal discussion, hence not recorded on list. I should have said "nobody on that discussion"; I had no doubt somebody used them. My mention of that wasn't to add weight to the thought, just to mention a quick straw poll had been taken... > We use serializable transactions heavily; our whole middle tier > architecture depends on having that transaction isolation level for all > requests which modify data. (You probably don't want to hear the > details.) *I* would, but others may not. ;-) > It would be OK (although a little disappointing) if VACUUM > enhancements weren't as beneficial to us as a result; it would render > PostgreSQL entirely unusable for us if the integrity of serializable > transactions was broken unless we added some other, non-standard steps > to run them. I would never suggest breaking STs; they are part of the SQL standard. I merely suggested an extra, optional API by which ST users could provide additional information that could help others avoid pessimal decisions in order to preserve correctness. > We only use pg_dump for version upgrades and other special cases. PITR > is our main backup technique. Cool. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: