On 15 September 2016 at 18:51, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 6:04 AM, Simon Riggs wrote:
>> On 1 September 2016 at 21:28, Simon Riggs wrote:
>>> So the only way to handle multiple locks is to do this roughly the way
>>> Rod suggests.
>>
>> I've just been reading the VACUUM code and
On Fri, Sep 16, 2016 at 3:51 AM, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 6:04 AM, Simon Riggs wrote:
> > On 1 September 2016 at 21:28, Simon Riggs wrote:
> >> So the only way to handle multiple locks is to do this roughly the way
> >> Rod suggests.
> >
> > I've just been reading the VACUUM
On Tue, Sep 6, 2016 at 6:04 AM, Simon Riggs wrote:
> On 1 September 2016 at 21:28, Simon Riggs wrote:
>> So the only way to handle multiple locks is to do this roughly the way
>> Rod suggests.
>
> I've just been reading the VACUUM code and it turns out that we
> already use Rod's mechanism intern
On 1 September 2016 at 21:28, Simon Riggs wrote:
> So the only way to handle multiple locks is to do this roughly the way
> Rod suggests.
I've just been reading the VACUUM code and it turns out that we
already use Rod's mechanism internally. So on that basis it seems fine
to support this as a us
On 5 April 2016 at 18:34, Rod Taylor wrote:
>
>
> On Tue, Apr 5, 2016 at 1:10 PM, Simon Riggs wrote:
>>>
>>> If a lock is successfully obtained on one table, but not on all tables,
>>> it releases that lock and will retry to get them as a group in the future.
>>> Since inheritance acts as a group
On Tue, Apr 5, 2016 at 1:10 PM, Simon Riggs wrote:
> If a lock is successfully obtained on one table, but not on all tables, it
>> releases that lock and will retry to get them as a group in the future.
>> Since inheritance acts as a group of tables (top + recursive cascade to
>> children), this
On 2016-04-05 18:10:11 +0100, Simon Riggs wrote:
> I'd prefer to see this as a lock wait mode where it sits in the normal lock
> queue BUT other lock requestors are allowed to queue jump past it. That
> should be just a few lines changed in the lock conflict checker and some
> sleight of hand in th
On 5 April 2016 at 17:43, Rod Taylor wrote:
> The intention of this feature is to give the ability to slip into a normal
> workload for non-urgent maintenance work. In essence, instead of lock
> waiters being in a Queue, DEFERRABLE causes the current lock statement to
> always be last.
>
Good id
The intention of this feature is to give the ability to slip into a normal
workload for non-urgent maintenance work. In essence, instead of lock
waiters being in a Queue, DEFERRABLE causes the current lock statement to
always be last. It was discussed at last years pgCon as useful for
replication t
