| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add non-blocking version of PQcancel |
| Date: | 2022-01-13 00:44:11 |
| Message-ID: | 20220113004411.3tdgiqdmmo4musb5@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-01-12 15:22:18 +0000, Jelte Fennema wrote:
> This patch also includes a test for this new API (and also the already
> existing cancellation APIs). The test can be easily run like this:
>
> cd src/test/modules/libpq_pipeline
> make && ./libpq_pipeline cancel
Right now tests fails to build on windows with:
[15:45:10.518] src/interfaces/libpq/libpqdll.def : fatal error LNK1121: duplicate ordinal number '189' [c:\cirrus\libpq.vcxproj]
on fails tests on other platforms. See
https://cirrus-ci.com/build/4791821363576832
> NOTE: I have not tested this with GSS for the moment. My expectation is
> that using this new API with a GSS connection will result in a
> CONNECTION_BAD status when calling PQcancelStatus. The reason for this
> is that GSS reads will also need to communicate back that an EOF was
> found, just like I've done for TLS reads and unencrypted reads. Since in
> case of a cancel connection an EOF is actually expected, and should not
> be treated as an error.
The failures do not seem related to this.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tanghy.fnst@fujitsu.com | 2022-01-13 01:07:49 | RE: Skipping logical replication transactions on subscriber side |
| Previous Message | Andres Freund | 2022-01-13 00:34:42 | Re: Stream replication test fails of cfbot/windows server 2019 |