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 externa
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 superuse
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 sa
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 resolvin
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 w
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 pote
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 qu
"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
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.
>
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 sing
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
files
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 commi
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 alread
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 <[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
inspec
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 t
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 dist
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
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
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 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, b
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 t
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
[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.
>>
>> I fear you have 100% misunderstood the point. The *only*
>> reason for that featu
-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.
>
> I fear you have 100% misunderstood the point. The *only*
> reason for
[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.
I fear you have 100% misunderstood th
-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
>
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_t
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 3:
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 t
30 matches
Mail list logo
