Re: [Tarantool-patches] [PATCH 1/1] applier: process synchro rows after WAL write

[Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On Thu, Apr 08, 2021 at 11:39:03AM +0300, Serge Petrenko wrote:
> 
> Thanks for the patch!
> 
> I'm a bit worried about two different synchro rows coming from two
> appliers. Is everything ok in this case?

Serge, you mean the scenario when some instances in replicaset
have the patch applied and some are not?

> Or even normal rows coming from other appliers. Say some other replica
> has already applied this synchro row and even has written some rows on
> top of it. Its applier won't block on replica_id latch, and may fail to
> apply
> some txs following this synchro row, because it's not yet written to WAL
> and thus not applied (limbo is still not empty or belongs to other
> instance).
> 
> Looks like this won't be a problem once synchro rows start pinning the
> limbo to some specific replica. Because in this case only the replica that
> has issued confirm will be able to generate new rows. And these rows will
> be ordered by replica_id latch.
> 
> But still, maybe this is worth fixing?
> Am I missing something?

> > -	struct journal_entry journal_entry;
> > +	union {
> > +		struct journal_entry base;
> > +		char base_buf[sizeof(base) + sizeof(base.rows[0])];
> > +	};
> >   };
> 
> I don't understand this union stuff.
> The journal_entry is the last entry in synchro_entry anyway.
> Is this a hack for allowing to allocate synchro_entry on the stack?

Yeah, the journal_entry last member is zero size array so someone
has to preallocate memory for rows and using union allows to squash
everything statically on stack.