Re: [HACKERS] Win32 hard crash problem
> >> My bet is something depending on GetTickCount to measure elapsed > time > >> (and no, it's not used in the core Postgres code, but you've got > >> plenty of other possible culprits in that stack). > > > This doesn't quite make sense. The only reason we have to reboot > is > > because PostgreSQL no longer responds. The system itself is fine. > > The Windows kernel may still work, but that doesn't mean that > everything Postgres depends on still works. I'm wondering about > (a) the TCP stack (and that includes 3rd party firewalls and such, > not only the core Windows code); (b) timing or threading stuff > inside the application that's using libpq, which the only thing we > know about so far is that it's *not* JDBC/Hibernate. How about getting a simple backtrace from a couple of the stuck postgres processes? And from the postmaster which should be accepting new connections... Or does that also hang completely? How to get one? Well, since we don't have the MSVC build yet (yeah, yeah, eventually), you can only get a semi-backtrace that only looks at exported symbols. You can get this using process explorer (thread tab, click stack), using WinDBG or using Visual Studio (you'll need VS 2005, and you need to check the option for "Load DLL exports" in options->debugging->native). Oh, btw, if there is a 3rd firewall on the box the standard recommendation of uninstalling it definitely sounds like a good plan :-) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Prepared statements considered harmful
On Fri, Sep 01, 2006 at 09:26:24AM +0200, Lukas Kahwe Smith wrote: > AFAIK since Oracle 9i planning is always deferred until the first > execution. This way they hope to get a better plan, which would > obviously not be possible if the selectivity varies greatly. Interesting. > So are the plans generated without taking any bound values into account > more stable in performance (albeit at times slower than what would have > been produced if the value would have been known)? Possibly, though they might uniformly suck or be uniformly good... > Either way mixing the question of when to prepare the plan with the > prepared statement being named or unnamed seems unexpected. Yes, well, when the V3 protocol designed it wasn't considered to seperate the parse and plan phases. The exact commit that got us to where we are now is here: http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c#rev1.420 That was over two years ago, I'm not sure whether any of the ideas mentioned in there have been implemented since. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Prepared statements considered harmful
> >>> I'd wish that we reconsider when and how prepared statements are
> >>> used. The JDBC interface and PL/pgSQL are frequently noticed
> >>> perpetrators, but the problem is really all over the place.
> >> AFAIK those are the only two places where preparation is
> the default
> >> ... what else were you thinking of?
> >
> > Perl DBI (DBD::Pg) defaults to prepared plans when connecting to a
> > version 8.0 or higher server.
> >
> > Or at least, that's the way I read the documentation.
Yea, but if you close the statement or leave the scope of the statement
variable the plan is gone. So it is doing exactly what I would expect.
It is written $stmt->prepare('select 1') what else would you expect ?
There are enough other functions to get a result without a plan sticking
around, like $db->selectrow_array
Andreas
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Prepared statements considered harmful
Martijn van Oosterhout wrote: On Thu, Aug 31, 2006 at 07:04:07PM -0400, Gregory Stark wrote: The server has to prepare the query sometime. The v3 protocol just gives you control over when that happens, but it doesn't force you to do it at any particular time. Not really. All named prepares are planned straight away, all unnamed ones are planned at bind time. Therefore you cannot have more than one parsed-but-not-planned prepared query at a time. In a connection pool scenario there's no way to share such plans since you can't tell which query has been prepared. That's not forcing, but it's an asymmetry we could do with out. AFAIK since Oracle 9i planning is always deferred until the first execution. This way they hope to get a better plan, which would obviously not be possible if the selectivity varies greatly. So are the plans generated without taking any bound values into account more stable in performance (albeit at times slower than what would have been produced if the value would have been known)? Either way mixing the question of when to prepare the plan with the prepared statement being named or unnamed seems unexpected. regards, Lukas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
