public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 6/6] More likely to be less likely
5+ messages / 3 participants
[nested] [flat]
* [PATCH 6/6] More likely to be less likely
@ 2020-10-25 19:27 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Justin Pryzby @ 2020-10-25 19:27 UTC (permalink / raw)
---
src/backend/commands/copy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 36ddcdccdb..a84a2e6091 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -2610,9 +2610,9 @@ CopyMultiInsertInfoFlush(CopyMultiInsertInfo *miinfo, ResultRelInfo *curr_rri)
/*
* Trim the list of tracked buffers down if it exceeds the limit. Here we
- * remove buffers starting with the ones we created first. It seems more
- * likely that these older ones are less likely to be needed than ones
- * that were just created.
+ * remove buffers starting with the ones we created first. It seems less
+ * likely that these older ones will be needed than ones that were just
+ * created.
*/
while (list_length(miinfo->multiInsertBuffers) > MAX_PARTITION_BUFFERS)
{
--
2.17.0
--SavPGzlo48F1Gxyz--
^ permalink raw reply [nested|flat] 5+ messages in thread
* [PATCH v2 4/6] More likely to be less likely
@ 2020-10-25 19:27 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Justin Pryzby @ 2020-10-25 19:27 UTC (permalink / raw)
---
src/backend/commands/copy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/copy.c b/src/backend/commands/copy.c
index 36ddcdccdb..a84a2e6091 100644
--- a/src/backend/commands/copy.c
+++ b/src/backend/commands/copy.c
@@ -2610,9 +2610,9 @@ CopyMultiInsertInfoFlush(CopyMultiInsertInfo *miinfo, ResultRelInfo *curr_rri)
/*
* Trim the list of tracked buffers down if it exceeds the limit. Here we
- * remove buffers starting with the ones we created first. It seems more
- * likely that these older ones are less likely to be needed than ones
- * that were just created.
+ * remove buffers starting with the ones we created first. It seems less
+ * likely that these older ones will be needed than ones that were just
+ * created.
*/
while (list_length(miinfo->multiInsertBuffers) > MAX_PARTITION_BUFFERS)
{
--
2.17.0
--QRj9sO5tAVLaXnSD
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v2-0005-comparison-but-see-also-language-changed-at-35cb5.patch"
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress.
@ 2023-03-03 16:37 Tom Lane <[email protected]>
2023-03-03 16:47 ` Re: pgsql: Harden new test case against force_parallel_mode = regress. Tom Lane <[email protected]>
2023-03-03 17:40 ` Re: pgsql: Harden new test case against force_parallel_mode = regress. Robert Haas <[email protected]>
0 siblings, 2 replies; 5+ messages in thread
From: Tom Lane @ 2023-03-03 16:37 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
Robert Haas <[email protected]> writes:
> On Thu, Mar 2, 2023 at 5:47 PM Tom Lane <[email protected]> wrote:
>> Per buildfarm: worker processes can't see a role created in
>> the current transaction.
> Now why would that happen? Surely the snapshot for each command is
> passed down from leader to worker, and the worker is not free to
> invent a snapshot from nothing.
The workers were failing at startup, eg (from [1]):
+ERROR: role "regress_psql_user" does not exist
+CONTEXT: while setting parameter "session_authorization" to "regress_psql_user"
Maybe this says that worker startup needs to install the snapshot before
doing any catalog accesses? Anyway, I'd be happy to revert this test
hack if you care to make the case work.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress.
2023-03-03 16:37 Re: pgsql: Harden new test case against force_parallel_mode = regress. Tom Lane <[email protected]>
@ 2023-03-03 16:47 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Tom Lane @ 2023-03-03 16:47 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
I wrote:
> The workers were failing at startup, eg (from [1]):
argh, forgot to add the link:
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hippopotamus&dt=2023-03-02%2022%3A31%3A1...
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress.
2023-03-03 16:37 Re: pgsql: Harden new test case against force_parallel_mode = regress. Tom Lane <[email protected]>
@ 2023-03-03 17:40 ` Robert Haas <[email protected]>
1 sibling, 0 replies; 5+ messages in thread
From: Robert Haas @ 2023-03-03 17:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
On Fri, Mar 3, 2023 at 11:37 AM Tom Lane <[email protected]> wrote:
> The workers were failing at startup, eg (from [1]):
>
> +ERROR: role "regress_psql_user" does not exist
> +CONTEXT: while setting parameter "session_authorization" to "regress_psql_user"
>
> Maybe this says that worker startup needs to install the snapshot before
> doing any catalog accesses? Anyway, I'd be happy to revert this test
> hack if you care to make the case work.
Oh, that's interesting (and sad). A parallel worker has a "startup
transaction" that is used to restore library and GUC state, and then
after that transaction commits, it starts up a new transaction that
uses the same snapshot and settings as the transaction in the parallel
leader. So the problem here is that the startup transaction can't see
the uncommitted work of some unrelated (as far as it knows)
transaction, and that prevents restoring the session_authorization
GUC.
That startup transaction has broken stuff before, and it would be nice
to get rid of it. Unfortunately, I don't remember right now why we
need it in the first place. I'm fairly sure that if you load the
library and GUC state without any transaction, that doesn't work,
because a bunch of important processing gets skipped. And I think if
you try to do those things in the "real" transaction that fails for
some reason too, maybe that there's no guarantee that all the relevant
GUCs can be changed at that point, but I'm fuzzy on the details at the
moment.
So I don't know how to fix this right now, but thanks for the details.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2023-03-03 17:40 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-10-25 19:27 [PATCH 6/6] More likely to be less likely Justin Pryzby <[email protected]>
2020-10-25 19:27 [PATCH v2 4/6] More likely to be less likely Justin Pryzby <[email protected]>
2023-03-03 16:37 Re: pgsql: Harden new test case against force_parallel_mode = regress. Tom Lane <[email protected]>
2023-03-03 16:47 ` Re: pgsql: Harden new test case against force_parallel_mode = regress. Tom Lane <[email protected]>
2023-03-03 17:40 ` Re: pgsql: Harden new test case against force_parallel_mode = regress. Robert Haas <[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