Re: RFC: Making TRUNCATE more "MVCC-safe"
От | Simon Riggs |
---|---|
Тема | Re: RFC: Making TRUNCATE more "MVCC-safe" |
Дата | |
Msg-id | CA+U5nML-0oSxRQA=D9VDD556M9ES4P7SUwNnLzDdtVdxaFUZcA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: Making TRUNCATE more "MVCC-safe" (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RFC: Making TRUNCATE more "MVCC-safe"
|
Список | pgsql-hackers |
On Fri, Mar 9, 2012 at 3:46 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 7, 2012 at 5:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> Case #2 is certainly a problem for FrozenXID as well, because anything >>> that's marked with FrozenXID is going to look visible to everybody, >>> including our older snapshots. And I gather you're saying it's also a >>> problem for HEAP_XMIN_COMMITTED. >> >> The problem there is that later subtransactions often have xids that >> are greater than xmax, so the xid shows as running when we do >> XidInMVCCSnapshot(), which must then be altered for this one weird >> case. I tried that and not happy with result. > > Altering XidInMVCCSnapshot() seems like a good thing to avoid, but I > confess I don't quite follow what you're describing here otherwise. > >>> I had assumed that the way we were >>> fixing this problem was to disable these optimizations for >>> transactions that had more than one snapshot floating around. I'm not >>> sure whether the patch does that or not, but I think it probably needs >>> to >> >> It does. I thought you already read the patch? > > I glanced over it, but did not look through it in detail. I'll do a > more careful look at your next version. I'm not confident about the restrictions this patch imposes and we aren't close enough to a final version for me to honestly request this be considered for this release. I think its time to close this door for now. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: