Message-ID: <4DDC1DBF.3050306@2ndQuadrant.com>
Date: Tue, 24 May 2011 17:06:07 -0400
From: Greg Smith <greg@2ndQuadrant.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: Alvaro Herrera <alvherre@commandprompt.com>
CC: pgsql-docs <pgsql-docs@postgresql.org>
Subject: Re: Improve warnings around CREATE INDEX CONCURRENTLY
References: <4DDB64CB.7070109@2ndQuadrant.com>
	<1306269968-sup-2890@alvh.no-ip.org>
In-Reply-To: <1306269968-sup-2890@alvh.no-ip.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 05/24/2011 04:48 PM, Alvaro Herrera wrote:
> Excerpts from Greg Smith's message of mar may 24 03:56:59 -0400 2011:
>
>    
>> What makes it worse is that the wait shows up as a virtualxid one, which
>> doesn't pop up on many common samples of things to look for in
>> pg_locks.  It would be reasonable but also incorrect for admins to
>> assume a table one would be visible if running into the case alluded to
>> in the docs.  The serial way locks are obtained is unexpected too.
>>      
> Incidentally, this is one of the things that Jim Nasby wanted exposed
> somehow so that these problems are more easily diagnosed.  I dropped the
> ball on that one, but I'll be picking it up again at some point.
>    

I don't remember seeing anything about that before, but then again I 
wasn't really looking for it until now.  Did you have a basic idea what 
you wanted to do there?  I have enough of this work queued up now that I 
may end up poking at the code myself here soon.

The first thing I was considering was dropping some DEBUG2 level logging 
about the various phases of the reindex into there.  Given that 
concurrent index creation has all these single instance requirements and 
long runtimes, I find myself putting them into scripts that do all the 
work as background processes.  If I could set client_min_messages=debug2 
when starting the script, and see more info about the progress as it 
happens appear in the script's output log, that is something I think 
many admins would choose to do.

Not the ideal UI for exposing this info, certainly.  But a really easy 
one to add, and realistically I think it would be enough to resolve most 
of the transparency complaints here.  The biggest problem is not even 
documenting where people should be looking toward suspiciously, which I 
think the doc patch I submitted helps with.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us