Re: bug: copy progress reporting of backends which run multiple COPYs

Поиск
Список
Период
Сортировка
От Ted Yu
Тема Re: bug: copy progress reporting of backends which run multiple COPYs
Дата
Msg-id CALte62zGMUSZ2Pf2ac3bieX9BWz8rbVtV6XMRkn9cuHdgrcttQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: bug: copy progress reporting of backends which run multiple COPYs  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Ответы Re: bug: copy progress reporting of backends which run multiple COPYs
Список pgsql-hackers
Дерево обсуждения


On Fri, Jan 20, 2023 at 4:51 PM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote:
On Thu, 19 Jan 2023 at 06:47, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
>
> But if a command JOINs file_fdw tables, the progress report gets bungled
> up.  This will warn/assert during file_fdw tests.

I don't know what to do with that other than disabling COPY progress
reporting for file_fdw, i.e. calls to BeginCopyFrom that don't supply
a pstate. This is probably the best option, because a table backed by
file_fdw would also interfere with COPY TO's progress reporting.

Attached a patch that solves this specific issue in a
binary-compatible way. I'm not super happy about relying on behavior
of callers of BeginCopyFrom (assuming that users that run copy
concurrently will not provide a ParseState* to BeginCopyFrom), but it
is what it is.

Kind regards,

Matthias van de Meent
Hi,
In `BeginCopyFrom`, I see the following :

        if (pstate)
        {
                cstate->range_table = pstate->p_rtable;
                cstate->rteperminfos = pstate->p_rteperminfos; 

Is it possible to check range_table / rteperminfos so that we don't introduce the bool field ?

Cheers

В списке pgsql-hackers по дате отправления: