Re: Two-phase commit security restrictions - Mailing list pgsql-hackers

From Oliver Jowett
Subject Re: Two-phase commit security restrictions
Date
Msg-id 416DEEFE.9040802@opencloud.com
Whole thread Raw
In response to Re: Two-phase commit security restrictions  (David Garamond <lists@zara.6.isreserved.com>)
List pgsql-hackers
David Garamond wrote:
> Oliver Jowett wrote:
> 
>> Heikki Linnakangas wrote:
>>
>>> Another approach I've been thinking about is to allow anyone that 
>>> knows the (user-supplied) global transaction identifier to finish the 
>>> transaction, and hide the gids of running transactions from regular 
>>> users. That way, the gid acts as a secret token that's only known by 
>>> the transaction manager, much like the cancel key.
>>
>>
>> Doesn't this break recovery? The TM needs to find all outstanding GIDs 
>> for a particular resource.
> 
> 
> Isn't it the TM's job to remember all the outstanding GIDs?

At a minimum it has to know how to contact all resources that might be 
involved in in-doubt transactions. Whether it also knows all the GIDs 
seems to depend somewhat on the TM's transaction log implementation 
(e.g. it may not be logging start-of-prepare).

My concern was more along the lines of how to implement Java's 
XAResource interface, which has 'Xid[] XAResource.recover(int flags)' 
i.e. the TM does not request recovery for specific transactions, it 
requests recovery for a whole resource. I think this is just a mapping 
of how the underlying XA system works, so presumably it'll be a problem 
for other XA-based APIs too.

-O


pgsql-hackers by date:

Previous
From: David Garamond
Date:
Subject: Re: Two-phase commit security restrictions
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Fix breakage in hashjoin from recent