Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE
От | Amit Kapila |
---|---|
Тема | Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE |
Дата | |
Msg-id | CAA4eK1+z2zBtj+B4qkGYKVGziYN2DdvsgGitBmSA=sX4-+=s+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE
|
Список | pgsql-hackers |
On Thu, Jun 24, 2021 at 11:25 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapila16@gmail.com> writes: > > On Tue, Jun 22, 2021 at 6:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> BTW, the reason that the walsender is still showing its "query" as > >> "SELECT pg_config..." is that pre-v14 versions don't update the > >> reported query for replication commands, only plain-SQL commands. > >> I recall that we fixed that in HEAD awhile ago; should we consider > >> back-patching something for it? > > > I think it would be great if we can do that. Analyzing such failures > > and in general for replication errors that will be a nice improvement > > and make the jobs of many people a bit easier. > > Checking the git history, this was fixed in f560209c6, which also > included some other mostly-cosmetic cleanup. I'm inclined to > propose back-patching that whole commit, rather than allowing the > code in exec_replication_command() to diverge in different branches. > It looks like it applies cleanly as far back as v10. Maybe something > could be done for 9.6 as well, but since that branch is so close to > EOL, I doubt it's worth spending extra effort on it. > +1. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: