Re: [BUG] Logical replica crash if there was an error in a function.
От | Anton A. Melnikov |
---|---|
Тема | Re: [BUG] Logical replica crash if there was an error in a function. |
Дата | |
Msg-id | 18e67956-07ff-7f85-eada-1f74562deb6b@inbox.ru обсуждение исходный текст |
Ответ на | Re: [BUG] Logical replica crash if there was an error in a function. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUG] Logical replica crash if there was an error in a function.
|
Список | pgsql-hackers |
Hello! Thanks for reply! On 24.09.2022 20:27, Tom Lane wrote: > I think you're solving the > problem in the wrong place. The real issue is why are > we not setting up ActivePortal correctly when running > user-defined code in a logrep worker? During a common query from the backend ActivePortal becomes defined in the PortalRun and then AfterTriggerEndQuery starts with non-NULL ActivePortal after ExecutorFinish. When the logrep worker is applying messages there are neither PortalStart nor PortalRun calls. And AfterTriggerEndQuery starts with undefined ActivePortal after finish-edata(). May be it's normal behavior? > There is other code > that expects that to be set, eg EnsurePortalSnapshotExists. When the logrep worker is applying message it doesn't have to use ActivePortal in EnsurePortalSnapshotExists because ActiveSnapshot is already installed. It is set at the beginning of each transaction in the begin_replication_step call. On the other hand, function_parse_error_transpose() tries to get the original query text (INSERT INTO test VALUES ('1') in our case) from the ActivePortal to clarify the location of the error. But in the logrep worker there is no way to restore original query text from the logrep message. There is only 'zipped' query equivalent to the original. So any function_parse_error_transpose() call seems to be useless in the logrep worker. And it looks like we can simply omit match_prosrc_to_query() call there. The attached patch does it. Best wishes, -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: