mirror of
https://github.com/timescale/timescaledb.git
synced 2025-05-16 18:43:18 +08:00
ad97d266c0
There was a race condition between the post_restore function restarting the background worker and the setting of the restoring flag to "off". If the worker started before the change to the restoring flag had been committed, it would not see the change and then die because the worker should exit when the db is in a restoring state. This modifies the post_restore function to use a restart instead of a start so that it waits on the commit to start up. It also adds logic to the entrypoint to reload config changes caused by an `ALTER DATABASE SET` command. These changes are normally only seen at connection startup but we have to wait until after our lock on the modifying transaction is released to know whether we should adopt them.