Databases
StackOverflow2013
Postsdbo
POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
    primarykey
    data
    text
    <p>You can see the combination of software components I'm using in the title of the question. </p> <p>I have a simple 10-table database running on a Postgres server (Win 7 Pro). I have client apps (python using psycopg to connect to Postgres) who connect to the database at random intervals to conduct relatively light transactions. There's only one client app at a time doing any kind of heavy transaction, and those are typically &lt; 500ms. The rest of them spend more time connecting than actually waiting for the database to execute the transaction. The point is that the database is under light load, but the load is evenly split between reads and writes.</p> <p>My client apps run as servers/services themselves. I've found that it is pretty common for me to be able to (1) take the Postgres server completely down, and (2) ruin the database by killing the client app with a keyboard interrupt.</p> <p>By (1), I mean that the Postgres process on the server aborts and the service needs to be restarted.</p> <p>By (2), I mean that the database crashes again whenever a client tries to access the database after it has restarted and (presumably) finished "recovery mode" operations. I need to delete the old database/schema from the database server, then rebuild it each time to return it to a stable state. (After recovery mode, I have tried various combinations of Vacuums to see whether that improves stability; the vacuums run, but the server will still go down quickly when clients try to access the database again.)</p> <p>I don't recall seeing the same effect when I kill the client app using a "taskkill" - only when using a keyboard interrupt to take the python process down. It doesn't happen all the time, but frequently enough that it's a major concern (25%?).</p> <p>Really surprised that <em>anything</em> on a client would actually be able to take down an "enterprise class" database. Can anyone share tips on how to improve robustness, and hopefully help me to understand why this is happening in the first place? Thanks, M</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USMayur Patel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. USunutbu
      1. VTFavorite
    2. VO
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. This table or related slice is empty.
      1. VTDownMod
    3. VO
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis may sound stupid but do you have the possibility to try it on Linux (even only with a virtual maschine/box)? If there are no errors there you know what the problem is...
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. USDrColossos
    2. COSo, what do the various logs have to say? Have you turned up logging levels? What exact error messages are you getting? Are you sure you're not kill -9ing a postgres process or something when killing a client process? This isn't a general robustness issue. I run pg servers that handle 100s of queries a second for years without pause, they never crash, unless something's gone wrong, like a bad drive sector or something.
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. USScott Marlowe
    3. COOh yeah, what version of pg are you running? If you have in fact found a bug, and you're running an older version, trying a newer version might fix that. And it's good to know what version you're on. Looks like someone found a very real bug in 9.0.2 just this week. If you have found a bug you can usually get a patch from the developers on the pgsql-general list pretty quick to keep production working. I've gotten two different patches in the past that got me back up and running in less than a day.
      singulars
      1. POPostgres 8.4.4 + psycopg2 + python 2.6.5 + Win7 instability
      1. USScott Marlowe
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload