From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rethink the wait event names for postgres_fdw, dblink and etc |
Date: | 2023-10-04 08:19:40 |
Message-ID: | ZR0gHNUR_oMVn8jx@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 21, 2023 at 11:04:23AM +0900, Masahiro Ikeda wrote:
> I updated the patch to v2.
> * Update a comment instead writing documentation about
> the wait events for pg_prewarm.
Right. It does not seem worth the addition currently, so I am
discarded this part. It's just not worth the extra cycles for the
moment.
> * Make the name of wait events which are different code
> path different. Add DblinkGetConnect and PgPrewarmDumpShutdown.
> * Make variable names shorter like pgfdw_we_receive.
> * Update documents.
> * Add some tests with pg_wait_events view.
Sounds like a good idea for postgres_fdw and dblink, still some of
them may not be stable? First, PostgresFdwReceive and
PostgresFdwCleanupReceive would be registered only if the connection
is busy, but that may not be always the case depending on the timing?
PostgresFdwConnect is always OK because this code path in
connect_pg_server() is always taken. Similarly, DblinkConnect and
DblinkGetConnect are registered in deterministic code paths, so these
will show up all the time.
I am lacking a bit of time now, but I have applied the bits for
test_shm_mq and worker_spi. Note that I have not added tests for
test_shm_mq as it may be possible that the two events (for the
bgworker startup and for a message to be queued) are never reached
depending on the timing. I'll handle the rest tomorrow, with likely
some adjustments to the tests. (I may as well just remove them, this
API is already covered by worker_spi.)
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-10-04 09:39:44 | Re: [PATCH] Add CANONICAL option to xmlserialize |
Previous Message | Orlov Aleksej | 2023-10-04 08:08:49 | RE: [PATCH] Fix memory leak in memoize for numeric key |