Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id B9B131FA2A4C for ; Thu, 26 Jul 2012 11:46:06 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SuPKG-0005Eg-L6 for pgsql-admin@postgresql.org; Thu, 26 Jul 2012 14:46:06 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q6QEjp23020496; Thu, 26 Jul 2012 10:45:52 -0400 (EDT) From: Tom Lane To: Thomas Markus cc: pgsql-admin@postgresql.org Subject: Re: problems with access into system catalogs In-reply-to: <5011260F.2060105@proventis.net> References: <5010F555.9020209@proventis.net> <5010FEF2.3050901@ringerc.id.au> <5011025B.7050003@proventis.net> <50110E39.1040601@ringerc.id.au> <5011260F.2060105@proventis.net> Comments: In-reply-to Thomas Markus message dated "Thu, 26 Jul 2012 13:12:15 +0200" Date: Thu, 26 Jul 2012 10:45:51 -0400 Message-ID: <20495.1343313951@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201207/92 X-Sequence-Number: 39809 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 this. regards, tom lane