Re: bug: copy progress reporting of backends which run multiple COPYs
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, Josef Šimánek <josef.simanek@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-05-08T23:57:32Z
Lists: pgsql-hackers
On Wed, May 08, 2024 at 10:07:15AM -0400, Robert Haas wrote: > I think you're hoping for too much. The progress reporting > infrastructure is fundamentally designed around the idea that there > can only be one progress-reporting operation in progress at a time. > For COPY, that is, I believe, true, but for file_fdw, it's false. If > we want to do any kind of progress reporting from within plannable > queries, we need some totally different and much more complex > infrastructure that can report progress for, probably, each plan node > individually. I think it's likely a mistake to try to shoehorn cases > like this into the infrastructure > that we have today. It will just encourage people to try to use the > current infrastructure in ways that are less and less like what it was > actually designed to do; whereas what we should be doing if we want > this kind of functionality, at least IMHO, is building infrastructure > that's actually fit for purpose. Hmm. OK. I have been looking around for cases out there where BeginCopyFrom() could be called with a pstate where the reporting could matter, and could not find anything worth worrying about. It still makes me a bit uneasy to not have a separate argument in the function to control that. Now, if you, Justin and Matthias agree with this approach, I won't stand in the way either. -- Michael