Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

On Mon, Mar 1, 2021 at 11:07 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I don't know Windows at all so I can't really comment on that portion, but from
> my understanding of procsignalbarriers I think this seems right. No tests
> break when forcing the codepath to run on Linux and macOS.

Hey Daniel,

Thanks for looking!

> Should this be performed in tblspc_redo as well for the similar case?

Ah. Yes. Added (not tested yet).

> +#if defined(WIN32) || defined(USE_ASSERT_CHECKING)
>
> Is the USE_ASSERT_CHECKING clause to exercise the code a more frequent than
> just on Windows? That could warrant a quick word in the comment if so IMO to
> avoid confusion.

Note added.

> -ProcessBarrierPlaceholder(void)
> +ProcessBarrierSmgrRelease(void)
> {
> - /*
> - * XXX. This is just a placeholder until the first real user of this
> - * machinery gets committed. Rename PROCSIGNAL_BARRIER_PLACEHOLDER to
> - * PROCSIGNAL_BARRIER_SOMETHING_ELSE where SOMETHING_ELSE is something
> - * appropriately descriptive. Get rid of this function and instead have
> - * ProcessBarrierSomethingElse. Most likely, that function should live in
> - * the file pertaining to that subsystem, rather than here.
> - *
> - * The return value should be 'true' if the barrier was successfully
> - * absorbed and 'false' if not. Note that returning 'false' can lead to
> - * very frequent retries, so try hard to make that an uncommon case.
> - */
> + smgrrelease();
>
> Should this instead be in smgr.c to avoid setting a precedent for procsignal.c
> to be littered with absorption functions?

Done.