| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
| Date: | 2023-01-04 22:55:43 |
| Message-ID: | 2383762.1672872943@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Hm. Seems confusing for this to continue being called rcancelrequested() and
> to be called via if(CANCEL_REQUESTED()), if we're not even documenting that
> it's intended to be usable that way?
Yeah. I'm not very happy with this line of development at all,
because I think we are painting ourselves into a corner by not allowing
code to detect whether a cancel is pending without having it happen
immediately. (That is, I do not believe that backend/regex/ is the
only code that will ever wish for that.) But if that is the direction
we're going to go in, we should probably revise these APIs to make them
less odd. I'm not sure why we'd keep the REG_CANCEL error code at all.
> I think it might be nicer to create this below CacheMemoryContext?
Meh ... CacheMemoryContext might not exist yet, especially for the
use-cases in the login logic.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2023-01-04 22:56:07 | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
| Previous Message | Andres Freund | 2023-01-04 22:53:54 | Re: meson oddities |