| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add a new BGWORKER_BYPASS_ROLELOGINCHECK flag |
| Date: | 2023-10-16 07:16:37 |
| Message-ID: | ZSzjVRaLMbwg-9gi@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 15, 2023 at 10:47:22PM -0400, Tom Lane wrote:
> I agree that that probably is the root cause, and we should fix it
> by bumping up max_worker_processes in this test.
Thanks. I've fixed this one now. Let's see if mamba is OK after
that.
> If there's actually a defensible reason for the C code to act
> like that, then all the call sites need to have checks for
> a null result.
We're just talking about a test module and an ERROR in the same
fashion as autoprewarm makes things more predictible for the TAP
script, IMO.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-10-16 07:17:23 | Re: pg_logical_emit_message() misses a XLogFlush() |
| Previous Message | Konstantin Knizhnik | 2023-10-16 06:32:21 | Re: Can concurrent create index concurrently block each other? |