public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v2 4/6] More likely to be less likely 4+ messages / 3 participants [nested] [flat]
* [PATCH v2 4/6] More likely to be less likely @ 2020-10-25 19:27 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 4+ 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] 4+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress. @ 2023-03-03 16:37 Tom Lane <[email protected]> 0 siblings, 2 replies; 4+ 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] 4+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress. @ 2023-03-03 16:47 Tom Lane <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 4+ 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] 4+ messages in thread
* Re: pgsql: Harden new test case against force_parallel_mode = regress. @ 2023-03-03 17:40 Robert Haas <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 4+ 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] 4+ messages in thread
end of thread, other threads:[~2023-03-03 17:40 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 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