Re: [HACKERS] Potential GIN vacuum bug

2015-10-04 Thread Jeff Janes
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,

Re: [HACKERS] Potential GIN vacuum bug

2015-10-02 Thread Robert Haas
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

Re: [HACKERS] Potential GIN vacuum bug

2015-10-01 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-09-03 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-09-01 Thread Robert Haas
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-31 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-30 Thread Tom Lane
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-30 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-30 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-30 Thread Tom Lane
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-22 Thread Jeff Janes
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,

Re: [HACKERS] Potential GIN vacuum bug

2015-08-18 Thread Robert Haas
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-17 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-17 Thread Alvaro Herrera
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-17 Thread Jeff Janes
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

Re: [HACKERS] Potential GIN vacuum bug

2015-08-17 Thread Heikki Linnakangas
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

[HACKERS] Potential GIN vacuum bug

2015-08-15 Thread Jeff Janes
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