Alvaro Herrera wrote: > > > Yeah. We agreed in principle awhile back to "fix" this on the backend > > > side by postponing the actual transaction start until the first command > > > after BEGIN. I looked at this just before 7.4 feature freeze, but > > > decided it wasn't quite trivial and I hadn't time to make it happen. > > > No one's gone back to work on it during the 7.5 cycle either. > > > > > > Right now I'm not wanting to touch that code since both Alvaro and the > > > 2PC guy have open patches against it... > > Actually, my patch is waiting for you to review it ;-) On the other > hand, since I'm already touching that code, maybe I can include it in my > patch. Or would you prefer to keep those things separate? Alvaro, can I ask what is left? I know you have pg_subtrans, but what plans do you have to abort subtransactions and bring the system back to the state before the subtransaction started? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
