I said:
> Other than that, it seems like it'd work, and it'd allow us to do a
> normal transaction commit internally in VACUUM, which is a lot cleaner
> than what VACUUM does now.
I punted on actually changing repair_frag's RecordTransactionCommit()
call into CommitTransactionCommand()/StartTrans
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> We'd still want XID keys for the locks that are used to wait for a
>> particular transaction to complete (eg when waiting to update
>> a tuple). I think that's OK since VACUUM doesn't need to hold any
>> such locks, but it'd probably mean making sep
> We'd still want XID keys for the locks that are used to wait for a
> particular transaction to complete (eg when waiting to update
> a tuple). I think that's OK since VACUUM doesn't need to hold any
> such locks, but it'd probably mean making separate lmgr API entry
> points for those locks as
> I can work on this if you don't have time to...
I have no -:)
Vadim
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Use BackendID instead of XID in XIDTAG?
> Add internal (ie per backend) hash of locks that should not be
> released at commit time?
> And couple additional funcs in lmgr API?
I think that would work. I'm inclined to use backend PID instead of
Backen
