> From: Richard Huxton [mailto:dev@xxxxxxxxxxxx] > > MessageContext: 1946198040 total in 258 blocks; 26624 free (43 > > chunks); > > 1946171416 used > > Well, I don't have to be a developer to know that if there's > a memory problem it's that big number starting 1946... that's > the problem. If that's bytes, it's ~ 1.9GB > > Do you see a backend process growing to 2GB+ before failure? I'm running PG 8.2.4 on WinXP. I used the task manager (as a quick and dirty utility) to watch the memory usage of the backend and it seemed to peak around 1.2GB. My server only has 1.5GB installed memory, so that would seem to verify that the process does indeed run out of memory. > > A quick rummage through the source and I find this file, > backend/utils/mmgr/README containing: > > MessageContext --- this context holds the current command > message from the frontend, as well as any derived storage > that need only live as long as the current message (for > example, in simple-Query mode the parse and plan trees can > live here). This context will be reset, and any children > deleted, at the top of each cycle of the outer loop of PostgresMain. > This is kept separate from per-transaction and per-portal > contexts because a query string might need to live either a > longer or shorter time than any single transaction or portal. > > Hmm - I can't think how that could reach 1.9GB in size, > especially since it has to be something different between a > "raw" connection and how ODBC is doing things. > > Can you reproduce this immediately (connect, query, crash), > or does the system have to run for a while first? I rebooted my server (thankfully I don't have very many clients at all, so that helps) and before anybody else connected to it, ran the query and observed the same result. This seems to be a problem with the ODBC driver? How can I narrow that down further? Mike ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
