On Sun, Feb 20, 2011 at 5:08 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Maxim Boguk <maxim.bo...@gmail.com> writes: > > I finally managed create working slave server with non-stripped > Postgresql > > 8.4.7 and working gdb. > > (sorry for such long delay). > > And i can reproduce situation quite easy now, so i managed get stack > > backtrace with that error. > > What i need to do now? I have some expirience with gbd now but i have no > > idea where to look next. > > Now that you know what query is causing the problem: > > > #9 0x0000000000673d43 in ProcessQuery (plan=0xdd0998890, > > sourceText=0xdd09c5830 "UPDATE ONLY bill.ctrl_servers SET opt = opt > > WHERE ctid=ANY($1) RETURNING ctid", params=0xdd09c58c0, > > dest=0xdd09de5c8, completionTag=0x7fffffffd4e0 "") at pquery.c:196 > > it shouldn't be too hard to prepare a self-contained test case so that > others can look at this. > > regards, tom lane > Sorry, but it's very unlikely I can create self-contained test case. That error doesn't happen on stand alone idle server. It's only happen at random time on table with very high update rate in production environment, and happen over 1-30 minutes calling my storable procedure in endless loop (e.g. once per 1000+ calls). I was long ago sure about exact place where that error happens (becuase my storable procedure contains only one real sql query), but because I can't create self contained test case I was asked use gdb and try to get backtrace at point of error. So now I can examine and provide variable values at that point to give a clue about what happens here. -- Maxim Boguk Senior Postgresql DBA. Skype: maxim.boguk Jabber: maxim.bo...@gmail.com LinkedIn profile: http://nz.linkedin.com/in/maximboguk If they can send one man to the moon... why can't they send them all? МойКруг: http://mboguk.moikrug.ru/ Сила солому ломит, но не все в нашей жизни - солома, да и сила далеко не все.
