"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> What about a string representation? Something like
> sessionId/localTransactionId? Should we ever decide that indeed this
> *should* get it's own datatype, a string representation would allow
> for a very painless transition...
Yeah, that's probabl
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
What about the following.
.) Remove the right-hand side XID from pg_locks (The one holder or waiter
of the lock). It seems to make more sense to store a RID here,
Yeah, we have to do that since there might not *be* an XID holdi
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> What about the following.
> .) Remove the right-hand side XID from pg_locks (The one holder or waiter
> of the lock). It seems to make more sense to store a RID here,
Yeah, we have to do that since there might not *be* an XID holding the
lock.
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
their lifetime is coupled to the lifetime of a transaction's toplevel
resource owner) seems to be to way to go for lazx xid assignment, I need
to find a way t
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
> their lifetime is coupled to the lifetime of a transaction's toplevel
> resource owner) seems to be to way to go for lazx xid assignment, I need
> to find a way to represent
Hi
Since generating transient XIDs (named ResourceOwnerIDs in my patch, since
their lifetime is coupled to the lifetime of a transaction's toplevel
resource owner) seems to be to way to go for lazx xid assignment, I need
to find a way to represent them in the pg_locks view.
ResourceOwnerIds are
