public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/6] 0001 review
10+ messages / 6 participants
[nested] [flat]
* [PATCH 2/6] 0001 review
@ 2021-02-15 15:26 Tomas Vondra <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Tomas Vondra @ 2021-02-15 15:26 UTC (permalink / raw)
---
doc/src/sgml/monitoring.sgml | 2 +-
src/backend/commands/copyfrom.c | 1 +
src/backend/commands/copyto.c | 2 ++
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 3c39c82f1a..c5048fefd4 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6561,7 +6561,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
<para>
The io target that the data is read from or written to:
<literal>FILE</literal>, <literal>PROGRAM</literal>,
- <literal>STDIO</literal> (for COPY FROM STDIN and COPY TO STDOUT),
+ <literal>STDIO</literal> (for <command>COPY FROM STDIN</command> and <command>COPY TO STDOUT</command>),
or <literal>CALLBACK</literal> (used in the table synchronization
background worker).
</para></entry>
diff --git a/src/backend/commands/copyfrom.c b/src/backend/commands/copyfrom.c
index c3610eb67e..d98f447cf5 100644
--- a/src/backend/commands/copyfrom.c
+++ b/src/backend/commands/copyfrom.c
@@ -1508,6 +1508,7 @@ BeginCopyFrom(ParseState *pstate,
ReceiveCopyBinaryHeader(cstate);
}
+ /* XXX this block seems weird */
{
int64 io_target;
switch (cstate->copy_src)
diff --git a/src/backend/commands/copyto.c b/src/backend/commands/copyto.c
index 42c4a828df..4b76bf5ef6 100644
--- a/src/backend/commands/copyto.c
+++ b/src/backend/commands/copyto.c
@@ -772,6 +772,8 @@ BeginCopyTo(ParseState *pstate,
/* initialize progress */
pgstat_progress_start_command(PROGRESS_COMMAND_COPY,
cstate->rel ? RelationGetRelid(cstate->rel) : InvalidOid);
+
+ /* XXX this too */
{
const int progress_index[] = {
PROGRESS_COPY_COMMAND,
--
2.26.2
--------------DA8D60BF026F7ACE69A9AEE5
Content-Type: text/x-patch; charset=UTF-8;
name="v7-0003-Add-backlinks-to-progress-reporting-documentation.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="v7-0003-Add-backlinks-to-progress-reporting-documentation.pa";
filename*1="tch"
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
@ 2024-05-16 19:47 Tom Lane <[email protected]>
2024-05-16 20:14 ` Re: commitfest.postgresql.org is no longer fit for purpose Greg Stark <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2024-05-16 19:47 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
Daniel Gustafsson <[email protected]> writes:
>> On 16 May 2024, at 20:30, Robert Haas <[email protected]> wrote:
>> The original intent of CommitFests, and of commitfest.postgresql.org
>> by extension, was to provide a place where patches could be registered
>> to indicate that they needed to be reviewed, thus enabling patch
>> authors and patch reviewers to find each other in a reasonably
>> efficient way. I don't think it's working any more.
> But which part is broken though, the app, our commitfest process and workflow
> and the its intent, or our assumption that we follow said process and workflow
> which may or may not be backed by evidence? IMHO, from being CMF many times,
> there is a fair bit of the latter, which excacerbates the problem. This is
> harder to fix with more or better software though.
Yeah. I think that Robert put his finger on a big part of the
problem, which is that punting a patch to the next CF is a lot
easier than rejecting it, particularly for less-senior CFMs
who may not feel they have the authority to say no (or at
least doubt that the patch author would accept it). It's hard
even for senior people to get patch authors to take no for an
answer --- I know I've had little luck at it --- so maybe that
problem is inherent. But a CF app full of patches that are
unlikely ever to go anywhere isn't helpful.
It's also true that some of us are abusing the process a bit.
I know I frequently stick things into the CF app even if I intend
to commit them pretty darn soon, because it's a near-zero-friction
way to run CI on them, and I'm too lazy to learn how to do that
otherwise. I like David's suggestion of a "Pending Commit"
status, or maybe I should just put such patches into RfC state
immediately? However, short-lived entries like that don't seem
like they're a big problem beyond possibly skewing the CF statistics
a bit. It's the stuff that keeps hanging around that seems like
the core of the issue.
>> I spent a good deal of time going through the CommitFest this week
> And you deserve a big Thank You for that.
+ many
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
@ 2024-05-16 20:14 ` Greg Stark <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Greg Stark @ 2024-05-16 20:14 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
When I was CFM for a couple cycles I started with the idea that I was going
to try being a hardass and rejecting or RWF all the patches that had gotten
negative reviews and been bounced forward.
Except when I actually went through them I didn't find many. Mostly like
Robert I found perfectly reasonable patches that had received generally
positive reviews and had really complex situations that really needed more
analysis.
I also found a lot of patches that were just not getting any reviews at all
:( and rejecting those didn't feel great....
On Thu, May 16, 2024, 21:48 Tom Lane <[email protected]> wrote:
> Daniel Gustafsson <[email protected]> writes:
> >> On 16 May 2024, at 20:30, Robert Haas <[email protected]> wrote:
> >> The original intent of CommitFests, and of commitfest.postgresql.org
> >> by extension, was to provide a place where patches could be registered
> >> to indicate that they needed to be reviewed, thus enabling patch
> >> authors and patch reviewers to find each other in a reasonably
> >> efficient way. I don't think it's working any more.
>
> > But which part is broken though, the app, our commitfest process and
> workflow
> > and the its intent, or our assumption that we follow said process and
> workflow
> > which may or may not be backed by evidence? IMHO, from being CMF many
> times,
> > there is a fair bit of the latter, which excacerbates the problem. This
> is
> > harder to fix with more or better software though.
>
> Yeah. I think that Robert put his finger on a big part of the
> problem, which is that punting a patch to the next CF is a lot
> easier than rejecting it, particularly for less-senior CFMs
> who may not feel they have the authority to say no (or at
> least doubt that the patch author would accept it). It's hard
> even for senior people to get patch authors to take no for an
> answer --- I know I've had little luck at it --- so maybe that
> problem is inherent. But a CF app full of patches that are
> unlikely ever to go anywhere isn't helpful.
>
> It's also true that some of us are abusing the process a bit.
> I know I frequently stick things into the CF app even if I intend
> to commit them pretty darn soon, because it's a near-zero-friction
> way to run CI on them, and I'm too lazy to learn how to do that
> otherwise. I like David's suggestion of a "Pending Commit"
> status, or maybe I should just put such patches into RfC state
> immediately? However, short-lived entries like that don't seem
> like they're a big problem beyond possibly skewing the CF statistics
> a bit. It's the stuff that keeps hanging around that seems like
> the core of the issue.
>
> >> I spent a good deal of time going through the CommitFest this week
>
> > And you deserve a big Thank You for that.
>
> + many
>
> regards, tom lane
>
>
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
@ 2024-05-16 20:31 ` Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
2024-05-16 21:00 ` Re: commitfest.postgresql.org is no longer fit for purpose Jesper Pedersen <[email protected]>
1 sibling, 2 replies; 10+ messages in thread
From: Joe Conway @ 2024-05-16 20:31 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
On 5/16/24 15:47, Tom Lane wrote:
> Daniel Gustafsson <[email protected]> writes:
>>> On 16 May 2024, at 20:30, Robert Haas <[email protected]> wrote:
>>> The original intent of CommitFests, and of commitfest.postgresql.org
>>> by extension, was to provide a place where patches could be registered
>>> to indicate that they needed to be reviewed, thus enabling patch
>>> authors and patch reviewers to find each other in a reasonably
>>> efficient way. I don't think it's working any more.
>
>> But which part is broken though, the app, our commitfest process and workflow
>> and the its intent, or our assumption that we follow said process and workflow
>> which may or may not be backed by evidence? IMHO, from being CMF many times,
>> there is a fair bit of the latter, which excacerbates the problem. This is
>> harder to fix with more or better software though.
>
> Yeah. I think that Robert put his finger on a big part of the
> problem, which is that punting a patch to the next CF is a lot
> easier than rejecting it, particularly for less-senior CFMs
> who may not feel they have the authority to say no (or at
> least doubt that the patch author would accept it).
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for the next one?
>>> I spent a good deal of time going through the CommitFest this week
>
>> And you deserve a big Thank You for that.
>
> + many
+1 agreed
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
@ 2024-05-16 20:57 ` Jacob Champion <[email protected]>
2024-05-16 21:06 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 21:08 ` Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
1 sibling, 2 replies; 10+ messages in thread
From: Jacob Champion @ 2024-05-16 20:57 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
On Thu, May 16, 2024 at 1:31 PM Joe Conway <[email protected]> wrote:
> Maybe we should just make it a policy that *nothing* gets moved forward
> from commitfest-to-commitfest and therefore the author needs to care
> enough to register for the next one?
I think that's going to severely disadvantage anyone who doesn't do
this as their day job. Maybe I'm bristling a bit too much at the
wording, but not having time to shepherd a patch is not the same as
not caring.
--Jacob
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
@ 2024-05-16 21:06 ` Joe Conway <[email protected]>
2024-05-16 21:24 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Joe Conway @ 2024-05-16 21:06 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
On 5/16/24 16:57, Jacob Champion wrote:
> On Thu, May 16, 2024 at 1:31 PM Joe Conway <[email protected]> wrote:
>> Maybe we should just make it a policy that *nothing* gets moved forward
>> from commitfest-to-commitfest and therefore the author needs to care
>> enough to register for the next one?
>
> I think that's going to severely disadvantage anyone who doesn't do
> this as their day job. Maybe I'm bristling a bit too much at the
> wording, but not having time to shepherd a patch is not the same as
> not caring.
Maybe the word "care" was a poor choice, but forcing authors to think
about and decide if they have the "time to shepherd a patch" for the
*next CF* is exactly the point. If they don't, why clutter the CF with it.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
2024-05-16 21:06 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
@ 2024-05-16 21:24 ` Jacob Champion <[email protected]>
2024-05-16 21:29 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Jacob Champion @ 2024-05-16 21:24 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
On Thu, May 16, 2024 at 2:06 PM Joe Conway <[email protected]> wrote:
> Maybe the word "care" was a poor choice, but forcing authors to think
> about and decide if they have the "time to shepherd a patch" for the
> *next CF* is exactly the point. If they don't, why clutter the CF with it.
Because the community regularly encourages new patch contributors to
park their stuff in it, without first asking them to sign on the
dotted line and commit to the next X months of their free time. If
that's not appropriate, then I think we should decide what those
contributors need to do instead, rather than making a new bar for them
to clear.
--Jacob
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
2024-05-16 21:06 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 21:24 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
@ 2024-05-16 21:29 ` Joe Conway <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Joe Conway @ 2024-05-16 21:29 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Tom Lane <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
On 5/16/24 17:24, Jacob Champion wrote:
> On Thu, May 16, 2024 at 2:06 PM Joe Conway <[email protected]> wrote:
>> Maybe the word "care" was a poor choice, but forcing authors to think
>> about and decide if they have the "time to shepherd a patch" for the
>> *next CF* is exactly the point. If they don't, why clutter the CF with it.
>
> Because the community regularly encourages new patch contributors to
> park their stuff in it, without first asking them to sign on the
> dotted line and commit to the next X months of their free time. If
> that's not appropriate, then I think we should decide what those
> contributors need to do instead, rather than making a new bar for them
> to clear.
If no one, including the author (new or otherwise) is interested in
shepherding a particular patch, what chance does it have of ever getting
committed?
IMHO the probability is indistinguishable from zero anyway.
Perhaps we should be more explicit to new contributors that they need to
either own their patch through the process, or convince someone to do it
for them.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
@ 2024-05-16 21:08 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Tom Lane @ 2024-05-16 21:08 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Joe Conway <[email protected]>; Daniel Gustafsson <[email protected]>; Robert Haas <[email protected]>; pgsql-hackers
Jacob Champion <[email protected]> writes:
> On Thu, May 16, 2024 at 1:31 PM Joe Conway <[email protected]> wrote:
>> Maybe we should just make it a policy that *nothing* gets moved forward
>> from commitfest-to-commitfest and therefore the author needs to care
>> enough to register for the next one?
> I think that's going to severely disadvantage anyone who doesn't do
> this as their day job. Maybe I'm bristling a bit too much at the
> wording, but not having time to shepherd a patch is not the same as
> not caring.
Also, I doubt that there are all that many patches that have simply
been abandoned by their authors. Our problem is the same as it's
been for many years: not enough review person-power, rather than
not enough patches. So I think authors would just jump through that
hoop, or enough of them would that it wouldn't improve matters.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: commitfest.postgresql.org is no longer fit for purpose
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
@ 2024-05-16 21:00 ` Jesper Pedersen <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Jesper Pedersen @ 2024-05-16 21:00 UTC (permalink / raw)
To: pgsql-hackers
Hi,
On 5/16/24 4:31 PM, Joe Conway wrote:
>> Yeah. I think that Robert put his finger on a big part of the
>> problem, which is that punting a patch to the next CF is a lot
>> easier than rejecting it, particularly for less-senior CFMs
>> who may not feel they have the authority to say no (or at
>> least doubt that the patch author would accept it).
>
> Maybe we should just make it a policy that *nothing* gets moved forward
> from commitfest-to-commitfest and therefore the author needs to care
> enough to register for the next one?
>
Or at least nothing get moved forward from March.
Spending time on a patch during a major version doesn't mean that you
have time to do the same for the next major version.
That way July could start "clean" with patches people are interested in
and willing to maintain during the next year.
Also, it is a bit confusing that f.ex.
https://commitfest.postgresql.org/48/
already shows 40 patches as Committed...
So, having some sort of "End of Development" state in general would be good.
Best regards,
Jesper
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2024-05-16 21:29 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-02-15 15:26 [PATCH 2/6] 0001 review Tomas Vondra <[email protected]>
2024-05-16 19:47 Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 20:14 ` Re: commitfest.postgresql.org is no longer fit for purpose Greg Stark <[email protected]>
2024-05-16 20:31 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 20:57 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
2024-05-16 21:06 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 21:24 ` Re: commitfest.postgresql.org is no longer fit for purpose Jacob Champion <[email protected]>
2024-05-16 21:29 ` Re: commitfest.postgresql.org is no longer fit for purpose Joe Conway <[email protected]>
2024-05-16 21:08 ` Re: commitfest.postgresql.org is no longer fit for purpose Tom Lane <[email protected]>
2024-05-16 21:00 ` Re: commitfest.postgresql.org is no longer fit for purpose Jesper Pedersen <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox