Re: Help: 8.0.3 Vacuum of an empty table never completes ...

James Robinson <jlrobins(at)socialserve(dot)com> writes:
> (gdb) bt
> #0 0xffffe410 in ?? ()
> #1 0xbfffd508 in ?? ()
> #2 0x082aef97 in PqSendBuffer ()
> #3 0xbfffd4f0 in ?? ()
> #4 0xb7ec03e1 in send () from /lib/tls/libc.so.6
> #5 0x08137d27 in secure_write ()
> #6 0x0813c2a7 in internal_flush ()
> #7 0x0813c4ff in pq_flush ()
> #8 0x0820bfec in EmitErrorReport ()
> #9 0x0820b5ac in errfinish ()
> #10 0x0811d0a8 in lazy_vacuum_rel ()
> #11 0x0811ac5a in vacuum_rel ()
> #12 0x0811bb93 in vacuum ()
> #13 0x0819c84d in PortalRunUtility ()
> #14 0x0819d9b8 in PortalRun ()
> #15 0x0819b221 in PostgresMain ()
> #16 0x0816ffa9 in ServerLoop ()
> #17 0x08170de9 in PostmasterMain ()
> #18 0x0813e5e5 in main ()
> (gdb) quit

Hmm, what this says is that the backend is blocked trying to send an
error or notice message to the client. We can't tell anything about
what the message was, but that's not so relevant ... the focus now
has to shift to the network or client side, ie, why in the world is
the backend waiting on the client to accept a message?

Can you get a similar backtrace from the vacuumdb process? (Obviously,
give gdb the vacuumdb executable not the postgres one.)

regards, tom lane