| From: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Accept recovery conflict interrupt on blocked writing |
| Date: | 2025-01-17 16:01:53 |
| Message-ID: | CAO6_Xqqgo3wCsGTwBW_kzuPdQv3n02PgOYNbLjoBoLJoMnjLTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I've tested on a PG16, the issue is indeed triggered with the
replication blocked while the conflicting query is stuck in
ClientWrite.
I've cleaned up the tests: I've created a dedicated PgProto
(definitely open to suggestions for a better name...) module
containing all the helpers to send and receive messages on a raw
socket in 0001.
0002 contains the change with the test using the new PgProto module.
The failure on windows I had was due to using the wrong username. I
was using $USER variable env and I'm now getting the user from an
existing psql session instead. Also, I think the DoingBlockingWrite
variable was unnecessary? Calling ProcessRecoveryConflictInterrupts
should be enough as I don't think QueryCancelHoldoffCount can be >0
when writing on a socket it should always be able to cancel the
statement.
| Attachment | Content-Type | Size |
|---|---|---|
| v03-0001-Add-PgProto-test-module-to-send-message-on-a-raw.patch | application/octet-stream | 7.7 KB |
| v03-0002-Accept-recovery-conflict-interrupt-on-blocked-wr.patch | application/octet-stream | 8.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2025-01-17 16:10:47 | Re: Fwd: Re: proposal: schema variables |
| Previous Message | Bruce Momjian | 2025-01-17 16:01:41 | Re: Fwd: Re: proposal: schema variables |