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