Thread: PGAdmin3 runs pg_dump etc

<div class="moz-text-flowed" lang="x-western" style="font-family: -moz-fixed;     font-size: 14px;">Hello list! <br
/><br/> I recently noticed that PGAdmin III (v 1.16.1) is kind of slow starting up (it didn't use to be), and in fact
onetime I wasn't even sure if I clicked on the icon properly to start it. I opened the Task Manager (I run Windows 7
UltimateSP1) and saw pg_restore was running, then the process vanished and PGAdmin finally opened. <br /><br /> I did
itagain, this time watching the process list, and it looks like when I start PGAdmin it automatically runs pg_dump,
pg_dumpall,and then pg_restore in the background before showing the splash screen and actually starting. <br /><br />
I'massuming that as my local development databases grow, it is taking longer to do all this, which is why I never
noticeduntil now. <br /><br /> What's up with that? Should I be concerned? I was unable to find anything about this
withGoogle... I'm not sure why a GUI would need to do all that each time it starts up. I'd prefer to skip this if
possible,since it is becoming slow to get started working. <br /><br /> Thanks for any insight! <br /><br /><br /> --
Stephen<br /><br /></div> 

On Thu, Aug 15, 2013 at 11:56 PM, Stephen Cook <sclists@gmail.com> wrote:
> Hello list!
>
> I recently noticed that PGAdmin III (v 1.16.1) is kind of slow starting up
> (it didn't use to be), and in fact one time I wasn't even sure if I clicked
> on the icon properly to start it. I opened the Task Manager (I run Windows 7
> Ultimate SP1) and saw pg_restore was running, then the process vanished and
> PGAdmin finally opened.
>
> I did it again, this time watching the process list, and it looks like when
> I start PGAdmin it automatically runs pg_dump, pg_dumpall, and then
> pg_restore in the background before showing the splash screen and actually
> starting.
>
> I'm assuming that as my local development databases grow, it is taking
> longer to do all this, which is why I never noticed until now.

No, that won't make any difference. It runs those utilities with the
--version flag to check what version they are so it knows how to call
them and what servers they will be compatible with. No attempt is made
to connect to any databases or anything.

I suppose it could slow down if you've replaced any of those utilities
with scripts of the same name that do something else - i.e. a pg_dump
script that calls the real pg_dump with the right parameters to
execute a backup. That doesn't seem like something anyone would do
though (and certainly wouldn't be advisable).

Probably the best bet would be to enable debug logging and then check
the timestamps to see what appears to be taking time.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 8/16/2013 4:47 AM, Dave Page wrote:
> On Thu, Aug 15, 2013 at 11:56 PM, Stephen Cook <sclists@gmail.com> wrote:
>> Hello list!
>>
>> I recently noticed that PGAdmin III (v 1.16.1) is kind of slow starting up
>> (it didn't use to be), and in fact one time I wasn't even sure if I clicked
>> on the icon properly to start it. I opened the Task Manager (I run Windows 7
>> Ultimate SP1) and saw pg_restore was running, then the process vanished and
>> PGAdmin finally opened.
>>
>> I did it again, this time watching the process list, and it looks like when
>> I start PGAdmin it automatically runs pg_dump, pg_dumpall, and then
>> pg_restore in the background before showing the splash screen and actually
>> starting.
>>
>> I'm assuming that as my local development databases grow, it is taking
>> longer to do all this, which is why I never noticed until now.
> No, that won't make any difference. It runs those utilities with the
> --version flag to check what version they are so it knows how to call
> them and what servers they will be compatible with. No attempt is made
> to connect to any databases or anything.
>
> I suppose it could slow down if you've replaced any of those utilities
> with scripts of the same name that do something else - i.e. a pg_dump
> script that calls the real pg_dump with the right parameters to
> execute a backup. That doesn't seem like something anyone would do
> though (and certainly wouldn't be advisable).
>
> Probably the best bet would be to enable debug logging and then check
> the timestamps to see what appears to be taking time.

Shortly after sending that email *everything* became terribly slow, and 
soon after my hard drive gave up the ghost. I rebuilt my PC and 
everything is just fine. At least I learned a thing.

Sorry for the noise on the list!


-- Stephen