On Fri, Jun 24, 2016 at 3:22 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > > > On 24 June 2016 at 10:28, Michael Paquier <michael.paqu...@gmail.com> wrote: >> >> On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer <cr...@2ndquadrant.com> >> wrote: >> > * Launch a VS x86 command prompt >> > * devenv /debugexe bin\initdb.exe -D test >> > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 >> > * Run >> > * When it traps at get_restricted_token(), manually move the execution >> > pointer over the setup of the restricted execution token by dragging & >> > dropping the yellow instruction pointer arrow. Yes, really. Or, y'know, >> > comment it out and rebuild, but I was working with a supplied binary. >> > * Continue until next breakpoint >> > * Launch process explorer and find the pid of the postgres child >> > process >> > * Debug->attach to process, attach to the child postgres. This doesn't >> > detach the parent, VS does multiprocess debugging. >> > * Continue execution >> > * vs will trap on the child when it crashes >> >> Do you think a crash dump could have been created by creating >> crashdumps/ in PGDATA as part of initdb before this query is run? > > > > The answer is "yes" btw. Add "crashdumps" to the static array of directories > created by initdb and it works great.
As simple as attached.. > Sigh. It'd be less annoying if I hadn't written most of the original patch. You mean the patch that created the crashdumps/ trick? This has saved me a couple of months back to analyze a problem TBH. -- Michael
-- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers