On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
There seems like a number of ways that unresolved prepared transactions
can cause problems. We really need to have startup mention how many
prepared transactions there are, so we have some chance of understanding
and resolving potential
On Thursday 12 July 2007 04:19, Simon Riggs wrote:
On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
There seems like a number of ways that unresolved prepared transactions
can cause problems. We really need to have startup mention how many
prepared transactions there are, so we have
Simon Riggs wrote:
On Wed, 2007-07-11 at 18:09 -0400, Tom Lane wrote:
There seems like a number of ways that unresolved prepared transactions
can cause problems. We really need to have startup mention how many
prepared transactions there are, so we have some chance of understanding
and
On Wed, Jul 11, 2007 at 10:47:25PM +0100, Simon Riggs wrote:
expertise to isolate this as the error. I would prefer to explicitly
avoid this kind of error, so that we can return to the idea that
removing pg_twophase is never a requirement.
This was pretty much my point. It's one thing to say,
On Wed, Jul 11, 2007 at 06:09:55PM -0400, Tom Lane wrote:
This is really pretty silly to be getting worked up about. The command
in question wouldn't have been allowed at all except to a superuser,
and there are plenty of ways to catastrophically destroy your database
when you are superuser;
Andrew Sullivan [EMAIL PROTECTED] writes:
But the other problem I see here is that the solution hits more than
just the problematic state. If we have bad pages on disk, for
instance, we zero pages; we don't drop the table. Similarly, it
seems that all that's necessary here is an external
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jul 11, 2007 at 12:38:09AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
[...]
It might make sense then to clear the pg_twophase directory on DB
startup.
blink I fear you have 100% misunderstood the point. The *only*
reason for
[EMAIL PROTECTED] writes:
On Wed, Jul 11, 2007 at 12:38:09AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
[...]
It might make sense then to clear the pg_twophase directory on DB
startup.
blink I fear you have 100% misunderstood the point. The *only*
reason for that feature is to
On Wed, Jul 11, 2007 at 10:43:23AM -0400, Chris Browne wrote:
The right resolution to this is not, a priori, evident yet.
_A posteriori_, though, it seems to me the right resolution is don't
do that ;-)
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Users never remark, Wow, this software may be
Chris Browne wrote:
If one locks certain vital system resources, as part of that PREPAREd
transaction, that evidently causes some problems, alas...
The right resolution to this is not, a priori, evident yet.
It's not? I agree with Tom here; this is just one of the numerous things
you can do
On Wed, Jul 11, 2007 at 04:44:12PM +0100, Heikki Linnakangas wrote:
FWIW, deleting the files from pg_twophase is safe when the system is
shut down.
Is it safe for the PREPAREd TRANSACTIONs? I assume not. That is, in
Peter's presumably experimental case, it might be ok to delete the
files,
Andrew Sullivan wrote:
On Wed, Jul 11, 2007 at 04:44:12PM +0100, Heikki Linnakangas wrote:
FWIW, deleting the files from pg_twophase is safe when the system is
shut down.
Is it safe for the PREPAREd TRANSACTIONs? I assume not. That is, in
Peter's presumably experimental case, it might be ok
On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote:
It's effectively the same as manually issuing a ROLLBACK PREPARED. It
will brake the atomicity of the global transaction, if some branches of
that global transaction in other resource managers have already been
committed.
Heikki Linnakangas wrote:
It's not? I agree with Tom here; this is just one of the numerous
things you can do to screw up your database as a superuser. Why would
you LOCK the pg_auth table, or any other system table for that
matter, in the first place? Let alone in a distributed transaction.
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
It's not? I agree with Tom here; this is just one of the numerous
things you can do to screw up your database as a superuser. Why would
you LOCK the pg_auth table, or any other system table for that
matter, in the first place? Let alone in a
Heikki Linnakangas [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
It's not? I agree with Tom here; this is just one of the numerous
things you can do to screw up your database as a superuser. Why would
you LOCK the pg_auth table, or any other system table for that
Andrew Sullivan [EMAIL PROTECTED] writes:
On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote:
It's effectively the same as manually issuing a ROLLBACK PREPARED.
But how do you know which file to delete?
You don't. In extremis you could probably throw together some
inspection
Heikki Linnakangas wrote:
Why does the application LOCK pg_auth?
It does it with NOWAIT to determine if some other connection had already
locked it (because it was modifying some roles) in order not to lock up
the program. This (or something like it, because this doesn't work,
after all) is
Andrew Sullivan wrote:
On Wed, Jul 11, 2007 at 06:15:12PM +0100, Heikki Linnakangas wrote:
It's effectively the same as manually issuing a ROLLBACK PREPARED. It
will brake the atomicity of the global transaction, if some branches of
that global transaction in other resource managers have
On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote:
The xid is encoded in the filename. If you can't start up the database
and look at pg_locks, you can't do much other than guess.
So then in this sort of case, it isn't _really_ safe to delete those
files, because the
Andrew Sullivan wrote:
On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote:
The xid is encoded in the filename. If you can't start up the database
and look at pg_locks, you can't do much other than guess.
So then in this sort of case, it isn't _really_ safe to delete those
On Tue, 2007-07-10 at 10:41 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The following command sequence appears to lock up the database system:
BEGIN;
LOCK pg_authid;
PREPARE TRANSACTION 'foo';
\q
After that you can't connect anymore, even in single-user mode.
On Wed, 2007-07-11 at 22:33 +0100, Heikki Linnakangas wrote:
Andrew Sullivan wrote:
On Wed, Jul 11, 2007 at 09:26:34PM +0100, Heikki Linnakangas wrote:
The xid is encoded in the filename. If you can't start up the database
and look at pg_locks, you can't do much other than guess.
So
Simon Riggs [EMAIL PROTECTED] writes:
I'd be much more comfortable if LOCK TABLE caused a message to the log
if it is executed on any system table.
Enabled by set training_wheels = on, perhaps?
This is really pretty silly to be getting worked up about. The command
in question wouldn't have
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I'd be much more comfortable if LOCK TABLE caused a message to the log
if it is executed on any system table.
Enabled by set training_wheels = on, perhaps?
This is really pretty silly to be getting worked up about. The command
in
The following command sequence appears to lock up the database system:
BEGIN;
LOCK pg_authid;
PREPARE TRANSACTION 'foo';
\q
After that you can't connect anymore, even in single-user mode. The only way
I could find is to clear out the pg_twophase directory, but I'm not sure
whether it is safe
is it good to allow locks on system tables at all?
i am not so sure. have seen some disaster in the past with that. just
consider somebody placing ACCESS EXCLUSIVE LOCK on a system table. it
is basically denial of service.
best regards,
hans
On Jul 10, 2007, at
Peter Eisentraut [EMAIL PROTECTED] writes:
The following command sequence appears to lock up the database system:
BEGIN;
LOCK pg_authid;
PREPARE TRANSACTION 'foo';
\q
After that you can't connect anymore, even in single-user mode. The
only way I could find is to clear out the pg_twophase
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Jul 10, 2007 at 10:41:31AM -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The following command sequence appears to lock up the database system:
BEGIN;
LOCK pg_authid;
PREPARE TRANSACTION 'foo';
\q
After that
[EMAIL PROTECTED] writes:
On Tue, Jul 10, 2007 at 10:41:31AM -0400, Tom Lane wrote:
Right offhand, clearing pg_twophase while the system is stopped should
be safe enough.
It might make sense then to clear the pg_twophase directory on DB
startup.
blink I fear you have 100% misunderstood the
30 matches
Mail list logo
