On Fri, Mar 10, 2017 at 7:39 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I agree that more analysis can help us to decide if we can use subxids
> from PGPROC and if so under what conditions. Have you considered the
> another patch I have posted to fix the issue which is to do this
> optimization only when subxids are not present? In that patch, it
> will remove the dependency of relying on subxids in PGPROC.
Well, that's an option, but it narrows the scope of the optimization
quite a bit. I think Simon previously opposed handling only the
no-subxid cases (although I may be misremembering) and I'm not that
keen about it either.
I was wondering about doing an explicit test: if the XID being
committed matches the one in the PGPROC, and nsubxids matches, and the
actual list of XIDs matches, then apply the optimization. That could
replace the logic that you've proposed to exclude non-commit cases,
gxact cases, etc. and it seems fundamentally safer. But it might be a
more expensive test, too, so I'm not sure.
It would be nice to get some other opinions on how (and whether) to
proceed with this. I'm feeling really nervous about this right at the
moment, because it seems like everybody including me missed some
fairly critical points relating to the safety (or lack thereof) of
this patch, and I want to make sure that if it gets committed again,
we've really got everything nailed down tight.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company