Re: pgsql: Integrate recovery.conf into postgresql.conf
От | Sergei Kornilov |
---|---|
Тема | Re: pgsql: Integrate recovery.conf into postgresql.conf |
Дата | |
Msg-id | 27802171543235530@iva2-6ec8f0a6115e.qloud-c.yandex.net обсуждение исходный текст |
Ответ на | Re: pgsql: Integrate recovery.conf into postgresql.conf (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgsql: Integrate recovery.conf into postgresql.conf
|
Список | pgsql-hackers |
Hi > The buildfarm is unhappy after this one: > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=culicidae&br=HEAD > > If I use -DEXEC_BACKEND when compiling the tests complain about a > timeout in 003_recovery_targets. Here is what the buildfarm reports, I > can see the failure by myself as well: > # Postmaster PID for node "standby_6" is 26668 > # poll_query_until timed out executing this query: > # SELECT '0/3022690'::pg_lsn <= pg_last_wal_replay_lsn() > # expecting this output: > # t > # last actual query output: > # f > # with stderr: > Timed out while waiting for standby to catch up at > t/003_recovery_targets.pl line 34. I can reproduce this and notice wrong assign settings order. For example standby_6 has > recovery_target_name = '$recovery_name' > recovery_target_xid = '$recovery_txid' > recovery_target_time = '$recovery_time' But recoveryTarget was set to RECOVERY_TARGET_XID Without -DEXEC_BACKEND all fine. As far as I understand the guc.c code with EXEC_BACKEND all processes uses different config processing logic. We serializeall GUC and restore at process start. And we sort GUC by name in build_guc_variables - so we restore settings inwrong order. I was afraid that the GUC system does not guarantee the order of settings... What is preferable solution? Seems we can not simple change this logic. I think i can reorganize all new recovery_target_* GUC into single one with format, for example, recovery_target = "xid:607"(was mentioned in patch discussion). regards, Sergei
В списке pgsql-hackers по дате отправления: