Search Postgresql Archives

What effect does destroying database related threads have on system resources?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



An application I have written connects to a remote Postgresql 8.3/8.4 database using  Lazarus/FreePascal components, Zeoslib, but it has been timing out too often as the network gets busy in a bursty mode. When the network times out, restarting the app retrieves the data quickly, it is always available in good time. The problem with some of the busier networks is that timeout dialogs happen too often and it annoys the users who have to restart the app.

My approach then is to run the database for displaying locally (which is actually the original design) and fetch the data from the remote database in background thread or in a background helper utility and insert it into the local database, where the timeouts do not occur.

This creates 2 problems

1. When the connection times out

2. When the query itself times out.

Since handling connection timeouts and query timeouts can be fraught,what I want to do is to create the whole process of retrieving the data in a thread within the main program or in a helper utility, and destroying the thread if it times out, but I can't be sure of what happens to the resources created by the thread when it is destroyed, both in the program code itself, the libpq libraries and on the server.

What are the consequences of working this way with lipql and the server?

Any ideas on what is likely to happen?

/voipfcGuy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux