Have you tried doing a VACUUM FULL on it? It might be that you aren't
vacuuming (plain vacuum, not full) often enough, and the number of dead
tuples gets so large that the database slows down and the application
times out.
Also, you could have a problem with index growth, so you might need to
reindex whatever indexes are on your data if they have monotonically
growing/deleting keys.
Also, you should upgrade as soon as possible to 7.3.5, or better yet, 7.4.
On Thu, 11 Dec 2003, Greenwich Support wrote:
> Hi All,
>
> I have a very weird problem which is occurring with a VB.Net app and
> PostgreSQL 7.3.1. There is a form that has a standard .Net datagrid on it
> that contains some data from a table in PostgreSQL.
>
> Now, the datagrid has functionality to allow the developer to
> programmatically determine what changes (if any) that have been made to the
> grid by the user -- i.e. determine if any new rows has been added, any rows
> modified or deleted.
>
> These changes are then written back into the database by simply calling an
> update function on a DataAdapter object.
>
> Now here's the problem.....the application is working fine for a couple of
> months with all inserts, updates and deletes carried out on the database
> table without any problems. Now updates do not work with the dataAdapter
> update where a 'DBConcurrencyException' is thrown -- i.e. the dataAdapter
> object will check that the underlying row(s) to be updated (in the database)
> have not been changed since the dataGrid was populated with the data. This
> you can imagine, can be an issue if there are a number of users working on
> the same data / form, however, I am getting this problem with only *ONE*
> user. This problem seems to be isolated to a particular table as I have had
> no problems with any of the other datagrids in the application that perform
> insert / update / delete operations.
>
> The bizarre thing is that if I backup the database, drop it, and recreate it
> from the backup, then the application works fine again.....what is up with
> that!?!?
>
> This lead me to think it may have been a maintenance thing, so I tried to
> VACUUM-ANALYZE the table in question, but that has had no effect.
>
> Does anyone have any thoughts, suggestions?
> TIA
> -simon
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>