| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
| Date: | 2022-06-21 11:02:57 |
| Message-ID: | CA+hUKG+EbZjFWd8t1npqZPhF-wJEFWx7cfkXAO8s-KpKTx1jBg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 21, 2022 at 7:44 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> The extra business with QueryCancelHoldoffCount and DoingCommandRead
> is the only addition for the snapshot, lock and tablespace conflict
> handling part. I don't see why a reason why that could be wrong on a
> close lookup. Anyway, why don't you check QueryCancelPending on top
> of QueryCancelHoldoffCount?
The idea of this patch is to make ProcessRecoveryConflictInterrupt()
throw its own ERROR, instead of setting QueryCancelPending (as an
earlier version of the patch did). It still has to respect
QueryCancelHoldoffCount, though, to avoid emitting an ERROR at bad
times for the fe/be protocol.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2022-06-21 11:03:50 | Re: Use fadvise in wal replay |
| Previous Message | Thomas Munro | 2022-06-21 10:51:38 | Re: Use fadvise in wal replay |