On Friday, 31 January 2020 22:57:23 MSK Cyrill Gorcunov wrote:
> On Fri, Jan 31, 2020 at 10:44:48PM +0300, Konstantin Osipov wrote:
> > I believe Georgy added this for a reason - since the current fiber
> > is no longer locked until the transaction is resumed, it should
> > be removed from the fiber key (this change AFAIU comes from
> > parallel applier patch).
> > 
> > I suggest you move this statement inside txn_write_to_wal(). I
> > can't find a good place for it yet though.
> 
> Thanks for idea, Kostya! The my patch above didn't work simply
> because if I don't set NULL here it start triggering assertion
> in another places. IOW, I filed this issue and will back to
> it on the next week I hope. I'll show you the result.

Kostja is right - the intention was to detach a transaction from a fiber.
The first step is being able to fire a transaction to wal and forget aboit it 
because all transaction finalization logic could be implemented via on_commit/
on_rollback trigger.  The reason to setup fiber while transaction on_commit/
on_rollback is backward compatibility - some transaction finalization triggers 
use in_txn() macro. So it makes the applier able to process transactions 
logging in parallel.
The second step I would like to implement is processing more than one 
transaction simultaneously, for instance we can be able to fire an autonomous 
transaction for sequences while a primary transaction still in progress and 
preserve such autonomous transaction effect even when the primary one is going 
to be rolled back.
Note: the second feature is limited until a transaction manager is implemented 
because simultaneous transactions shall be non-conflicting.