Thomas Markus writes:
> a rollback prepared on these does the job
If you aren't intentionally using prepared transactions, it's a good
idea to disable them by setting max_prepared_transactions to zero
(DB restart required). That prevents you from accidentally shooting
yourself in the foot like t
Hi Craig,
thanks, that was the tip
a rollback prepared on these does the job
best regards
Thomas
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
On 07/26/2012 04:39 PM, Thomas Markus wrote:
Hi,
see below
Am 26.07.2012 10:25, schrieb Craig Ringer:
- Do you have any uncommitted two phase transactions? Run:
SELECT * from pg_prepared_xacts ;
hm yes, i stopped all applications this morning but this query shows:
transaction | gid
Hi,
see below
Am 26.07.2012 10:25, schrieb Craig Ringer:
First, thank-you for an excellent complete question with versions,
EXPLAIN ANALYZE, and exact messages.
;)
- Do you have any uncommitted two phase transactions? Run:
SELECT * from pg_prepared_xacts ;
hm yes, i stopped all applicati
First, thank-you for an excellent complete question with versions,
EXPLAIN ANALYZE, and exact messages.
My reply is interleaved below.
On 07/26/2012 03:44 PM, Thomas Markus wrote:
I have 2 systems with CentOS 5.5 (2.6.18) x86_64, postgresql-9.0.6 64bit
both systems contains the same content.
Hi,
I have 2 systems with CentOS 5.5 (2.6.18) x86_64, postgresql-9.0.6 64bit
both systems contains the same content. But one system make troubles.
some system tables (eg pg_catalog.pg_class or pg_attribute) contain much
dead rows and all simple query take much time on one system. the other
on
