On Thu, Sep 3, 2015 at 10:42 AM, Jeff Janes wrote:
> On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes wrote:
>
>> On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane wrote:
>>
>>> Jeff Janes writes:
>>> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
>>>
>> > But we would still have to deal with the
>>
On Thu, Oct 1, 2015 at 4:44 PM, Jeff Janes wrote:
> Is the locking around indexes summarized someplace?
Not to my knowledge. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Tue, Sep 1, 2015 at 8:05 AM, Robert Haas wrote:
> On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane wrote:
> >> But we would still have to deal with the
> >> fact that unconditional acquire attempt by the backends will cause a
> vacuum
> >> to cancel itself, which is undesirable.
> >
> > Good point.
On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes wrote:
> On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane wrote:
>
>> Jeff Janes writes:
>> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
>>
> > But we would still have to deal with the
>> > fact that unconditional acquire attempt by the backends wil
On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane wrote:
>> But we would still have to deal with the
>> fact that unconditional acquire attempt by the backends will cause a vacuum
>> to cancel itself, which is undesirable.
>
> Good point.
>
>> If we define a new namespace for
>> this lock (like the relati
On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane wrote:
> Jeff Janes writes:
> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
> >> Your earlier point about how the current design throttles insertions to
> >> keep the pending list from growing without bound seems like a bigger
> deal
> >> to worry
Jeff Janes writes:
> On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
>> Your earlier point about how the current design throttles insertions to
>> keep the pending list from growing without bound seems like a bigger deal
>> to worry about. I think we'd like to have some substitute for that.
>>
On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane wrote:
> Jeff Janes writes:
>
> Your earlier point about how the current design throttles insertions to
> keep the pending list from growing without bound seems like a bigger deal
> to worry about. I think we'd like to have some substitute for that.
>
Jeff Janes writes:
> Attached is a patch to deal with this without the heavyweight locks.
> I realized that using the clean up lock on the meta page, rather than the
> pending head page, would be easier to implement as a pin was already held
> on the meta page throughout, and the pending head page
On Sat, Aug 22, 2015 at 11:25 AM, Jeff Janes wrote:
> On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas
> wrote:
>
>> On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes wrote:
>> > User backends attempt to take the lock conditionally, because otherwise
>> they
>> > would cause an autovacuum already holding
On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas wrote:
> On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes wrote:
> > User backends attempt to take the lock conditionally, because otherwise
> they
> > would cause an autovacuum already holding the lock to cancel itself,
> which
> > seems quite bad.
> >
>
On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes wrote:
> User backends attempt to take the lock conditionally, because otherwise they
> would cause an autovacuum already holding the lock to cancel itself, which
> seems quite bad.
>
> Not that this a substantial behavior change, in that with this code
On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera
wrote:
> Jeff Janes wrote:
>
> > The attached patch takes a ShareUpdateExclusiveLock lock on the index in
> > order to clean the pending list.
>
> Does it take a lock on the table also? Because if not ...
>
There must be some kind of lock held on
Jeff Janes wrote:
> The attached patch takes a ShareUpdateExclusiveLock lock on the index in
> order to clean the pending list.
Does it take a lock on the table also? Because if not ...
> One potential problem is how it will interact with "create index
> concurrently".
... then I don't underst
On Mon, Aug 17, 2015 at 6:23 AM, Jeff Janes wrote:
>
> On Aug 16, 2015 11:49 PM, "Heikki Linnakangas" wrote:
> >
> > On 08/16/2015 12:58 AM, Jeff Janes wrote:
> >>
> >> When ginbulkdelete gets called for the first time in a VACUUM(i.e.
> stats
> >> == NULL), one of the first things it does is c
On 08/16/2015 12:58 AM, Jeff Janes wrote:
When ginbulkdelete gets called for the first time in a VACUUM(i.e. stats
== NULL), one of the first things it does is call ginInsertCleanup to get
rid of the pending list. It does this in lieu of vacuuming the pending
list.
This is important because if
When ginbulkdelete gets called for the first time in a VACUUM(i.e. stats
== NULL), one of the first things it does is call ginInsertCleanup to get
rid of the pending list. It does this in lieu of vacuuming the pending
list.
This is important because if there are any dead tids still in the Pendin
17 matches
Mail list logo
