| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: pg_sleep() doesn't work well with recovery conflict interrupts. |
| Date: | 2014-05-30 05:00:42 |
| Message-ID: | CAA4eK1JZP+RGgG2ZnrYYXQRVKbWfVkfUnrGv5=_3hEsz_k=yAA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 28, 2014 at 8:53 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> Hi,
>
> Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
> WaitLatch() to wait. That's fine in itself. But
> procsignal_sigusr1_handler, which is used e.g. when resolving recovery
> conflicts, doesn't unconditionally do a SetLatch().
> That means that we'll we'll currently not be able to cancel conflicting
> backends during recovery for 10min. Now, I don't think that'll happen
> too often in practice, but it's still annoying.
How will such a situation occur, aren't we using pg_usleep during
RecoveryConflict functions
(ex. in ResolveRecoveryConflictWithVirtualXIDs)?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2014-05-30 07:15:44 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |
| Previous Message | Robert Haas | 2014-05-30 03:42:21 | Re: postgres_fdw and connection management |