[Tarantool-patches] [PATCH v2 1/3] gc/xlog: delay xlog cleanup until relays are subscribed

Cyrill Gorcunov gorcunov at gmail.com
Tue Mar 23 14:25:26 MSK 2021

On Tue, Mar 23, 2021 at 10:28:46AM +0300, Cyrill Gorcunov wrote:
> > 
> > Also you should use 'replication_anon' global variable instead
> > of the config, which might be not installed at this moment yet.
> What would happen if one setup both 'wal_cleanup_delay' and
> 'replication_anon' in config at once. Which C's replication_anon
> value I will be reading? The C's replication_anon is set after
> the cfg procedure complete, so since I operate on values obrained
> from Lua level I need to use cfg_geti("replication_anon") because
> at this moment only Lua level is consistent and replication_anon
> may have a value from previous box.cfg call.

Vlad, here are some moments I don't understand.

1) gc_init is called from box_cfg_xc, and here is a call chain

  box.cfg = locked(load_cfg)
      -- goes into C layer --
          if (box_check_wal_cleanup_delay() < 0)

          here either all values are sane and
          passes the tests, or configuration
          stage aborts

      -- back to Lua level --
      -- jusmp to C again --

here the box_check_wal_cleanup_delay won't fail because
it is already verified but we can't be sure that any
dependent variable (as global replication_anon) been
already set or not. And we should not bound to order
of box_check_wal_cleanup_delay() invocation relatively
to some other helpers.

Thus I think we should use cfg_geti("replication_anon") inside
box_check_wal_cleanup_delay code instead because only the
level cfg_x() is consistent here.

On reconfiguration stage the scheme is similar we must
not access C's global replication_anon variable which
is rather a cached value from cfg_geti("replication_anon").

Am I convinced you? I mean current code with access to
cfg_geti("replication_anon") looks more preferred.

More information about the Tarantool-patches mailing list