On 12.06.2011 17:59, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>> On 10.06.2011 18:05, Kevin Grittner wrote:
>>> Heikki Linnakangas wrote:
>>>> o There is no safeguard against actually wrapping around the
>>>> SLRU, just the warning
>>>
>>> Any thoughts on what we should do instead? If someone holds open a
>>> transaction long enough to burn through a billion transaction IDs
>>> (or possibly less if someone uses a smaller BLCKSZ), should we
>>> generate a FATAL error?
>>
>> FATAL is a bit harsh, ERROR seems more appropriate.
>
> If we don't cancel the long-running transaction, don't we continue to
> have a problem?
Yes, but ERROR is enough to kill the transaction. Unless it's in a
subtransaction, I guess. But anyway, there's no guarantee that the
long-running transaction will hit the problem first, or at all. You're
much more likely to kill an innocent new transaction that tries to
acquire its first locks, than an old long-running transaction that's
been running for a while already, probably idle doing nothing, or doing
a long seqscan on a large table with the whole table locked already.
> I see you committed a patch for this, but there were some casts which
> become unnecessary with that change that you missed. Patch attached
> to clean up the ones I could spot.
Ah, thanks, applied. I didn't realize those were also only needed
because of the volatile qualifier.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
