Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Florian G. Pflug wrote:
>> So, in essence, you get the old pg_locks format back by doing
>> select l1.*, l2.transactionid as "transaction" from pg_locks l1,
>> pg_locks l2
>> where l1.vxid = l2.vxid and l2.locktype = 'transaction'
>> and l2.mode='exclus
Andrew Dunstan wrote:
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as "transaction" from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and l2.granted=true.
Hm
Florian G. Pflug wrote:
So, in essence, you get the old pg_locks format back by doing
select l1.*, l2.transactionid as "transaction" from pg_locks l1,
pg_locks l2
where l1.vxid = l2.vxid and l2.locktype = 'transaction'
and l2.mode='exclusive' and l2.granted=true.
Hm.. Maybe we should pu
Robert Treat wrote:
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
However, none of these are very strong reasons - certainly weaker than
doing what ensures to cause the least confusion. I'm therefore
starting to think that we should remove
Robert Treat <[EMAIL PROTECTED]> writes:
> ISTM that by removing the transaction column, there is no way to see the XID
> for relations thats have been updated (which by definition will have locks on
> them). Am I mis-reading the docs, or have we lost that functionality?
Huh? What do you me
On Wednesday 05 September 2007 12:56, Tom Lane wrote:
> "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > However, none of these are very strong reasons - certainly weaker than
> > doing what ensures to cause the least confusion. I'm therefore
> > starting to think that we should remove transactio
[EMAIL PROTECTED] ("Florian G. Pflug") writes:
> Chris Browne wrote:
>> Similarly, does it seem likely that Slony-I users would need to worry
>> about this?
> No.. it should have zero negative effects for Slony-I. In fact, it will
> be an advantage in some cases I think. I remember something about
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Applied with revisions --- mostly cosmetic, but
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Here is an updated patch, following the discussion.
> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
> (I seems I still can't get attachments through to this list)
Applied with revisions --- mostly cosmetic, but there were a c
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> However, none of these are very strong reasons - certainly weaker than
> doing what ensures to cause the least confusion. I'm therefore
> starting to think that we should remove transaction, and keep the name
> virtualtransaction for the VXID. That w
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
1) 2PC was broken in V3. I added code that skips
LOCKTYPE_VIRTUALTRANSACTION
locks when writing the locks to the 2PC state file, but I didn't
add the same exception to the code that reassigns the locks to
a dummy PGROC afterwards. So the locks we
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
I've been working through this, and found a couple items that seem like
judgment calls:
* Is there a good re
Florian G. Pflug wrote:
> 1) 2PC was broken in V3. I added code that skips
> LOCKTYPE_VIRTUALTRANSACTION
> locks when writing the locks to the 2PC state file, but I didn't
> add the same exception to the code that reassigns the locks to
> a dummy PGROC afterwards. So the locks weren't released at P
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Here is an updated patch, following the discussion.
> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
I've been working through this, and found a couple items that seem like
judgment calls:
* Is there a good reason for formatt
Chris Browne wrote:
Similarly, does it seem likely that Slony-I users would need to worry
about this?
No.. it should have zero negative effects for Slony-I. In fact, it will
be an advantage in some cases I think. I remember something about
troubles with Slony-I if the in-use xids on a intermedia
[EMAIL PROTECTED] ("Florian G. Pflug") writes:
> Pavan Deolasee wrote:
>> On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>>> Hi
>>>
>>> Here is an updated patch, following the discussion.
>>> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
>>> (I seems I still can't ge
On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
>
> I don't think so. The interactions should be pretty minimal.
Thats good news!
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
Pavan Deolasee wrote:
On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
Hi
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
I haven't been able to follow
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>> Here is an updated patch, following the discussion.
>> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
>> (I seems I still can't get attachments through to this list)
>>
>
On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
>
> Hi
>
> Here is an updated patch, following the discussion.
> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
> (I seems I still can't get attachments through to this list)
>
>
I haven't been able to follow the discussi
Hi
Here is an updated patch, following the discussion.
The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch
(I seems I still can't get attachments through to this list)
Most changes are just small fixes and tweaks. Those are
.) Introduced %v for log_line_prefix
.) I missed a few
21 matches
Mail list logo
