On Mon, Jun 8, 2009 at 12:25 PM, Ioana Danes<ioanasoftw...@yahoo.ca> wrote: > > Well, I guess I have my answer... > > I tried to narrow down an issue I get on one of the production sites, where > using a similar transaction I get the same error. > > In my production environment the group id is actually a unique number for the > terminal (terminalid) and the same transaction CANNOT be called for the same > terminalid. So this should never happen because each terminal has its own ID > and this procedure is called on login operation for each terminal... At least > that's what I thought so... > > But it does happen during the nightly online backup (pg_dump). > It looks like when the client logs in, the request is sent from the client to > the db, the backup (pg_dump) slows down the server (or holds the lock on that > table?) and the user does not have patience and restarts the client and logs > in again. > In this case I can get two parallel transactions for the same terminal...
You mentioned earlier you're using slony for replication, so the answer is obvious, run the backup against a read slave, and set the users, during backup, to only have access to the written to master. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
