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,
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
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
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
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
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
Jeff Janes jeff.ja...@gmail.com 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
On Sat, Aug 22, 2015 at 11:25 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
User backends attempt to take the lock conditionally, because otherwise
On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com 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
Jeff Janes jeff.ja...@gmail.com writes:
On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
User backends attempt to take the lock conditionally, because otherwise
they
would cause an autovacuum already holding the lock to cancel itself,
On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com 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
On Mon, Aug 17, 2015 at 6:23 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Aug 16, 2015 11:49 PM, Heikki Linnakangas hlinn...@iki.fi 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
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 understand
On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera alvhe...@2ndquadrant.com
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
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
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
17 matches
Mail list logo