| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: wake up logical workers after ALTER SUBSCRIPTION |
| Date: | 2022-12-31 23:50:19 |
| Message-ID: | 20221231235019.GA1223171@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Dec 18, 2022 at 03:36:07PM -0800, Nathan Bossart wrote:
> This seems to have somehow broken the archiving tests on Windows, so
> obviously I owe some better analysis here. I didn't see anything obvious
> in the logs, but I will continue to dig.
On Windows, WaitForWALToBecomeAvailable() seems to depend on the call to
WaitLatch() for wal_retrieve_retry_interval to ensure that signals are
dispatched (i.e., pgwin32_dispatch_queued_signals()). My first instinct is
to just always call WaitLatch() in this code path, even if
wal_retrieve_rety_interval milliseconds have already elapsed. The attached
0003 does this.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| Attachment | Content-Type | Size |
|---|---|---|
| v10-0001-wake-up-logical-workers-as-needed-instead-of-rel.patch | text/x-diff | 6.4 KB |
| v10-0002-handle-race-condition-when-restarting-wal-receiv.patch | text/x-diff | 2.2 KB |
| v10-0003-ensure-signals-are-dispatched-in-startup-process.patch | text/x-diff | 2.9 KB |
| v10-0004-set-wal_retrieve_retry_interval-to-1ms-in-tests.patch | text/x-diff | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2023-01-01 00:15:36 | Re: Add SHELL_EXIT_CODE to psql |
| Previous Message | Isaac Morland | 2022-12-31 22:28:40 | Re: Add SHELL_EXIT_CODE to psql |