| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: bug: copy progress reporting of backends which run multiple COPYs |
| Date: | 2023-01-21 00:51:28 |
| Message-ID: | CAEze2WigStQee9rTzVhwT7HCJRFqKy4pMD1Tf=uF0eXKTezDJA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 19 Jan 2023 at 06:47, Justin Pryzby <pryzby(at)telsasoft(dot)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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Only-report-progress-if-we-re-actually-in-a-parse.patch | application/octet-stream | 4.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ted Yu | 2023-01-21 01:03:43 | Re: bug: copy progress reporting of backends which run multiple COPYs |
| Previous Message | Andres Freund | 2023-01-21 00:40:32 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |