| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why is src/test/modules/committs/t/002_standby.pl flaky? |
| Date: | 2022-01-10 09:40:27 |
| Message-ID: | CA+hUKGKPpbC2EM2tSy5-1cfj+-1d2PVwLU4kBNg8E+og+B3fbg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 10, 2022 at 10:20 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, Jan 10, 2022 at 8:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> > The libpqrcv_PQgetResult function, in turn, invokes WaitLatchOrSocket()
> > where WaitEvents are defined locally, and the closed flag set on the
> > first invocation but expected to be checked on second.
>
> D'oh, right. There's also a WaitLatchOrSocket call in walreceiver.c.
> We'd need a long-lived WaitEventSet common across all of these sites,
> which is hard here (because the socket might change under you, as
> discussed in other threads that introduced long lived WaitEventSets to
> other places but not here).
This is super quick-and-dirty code (and doesn't handle some errors or
socket changes correctly), but does it detect the closed socket?
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Make-Windows-FD_CLOSE-reporting-sticky.patch | text/x-patch | 2.1 KB |
| v2-0002-XXX-Quick-hack-to-use-persistent-WaitEventSet-in-.patch | text/x-patch | 12.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Lepikhov | 2022-01-10 10:24:46 | Re: Multiple Query IDs for a rewritten parse tree |
| Previous Message | vignesh C | 2022-01-10 09:27:28 | Re: Skipping logical replication transactions on subscriber side |