Re: Small SSI issues

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: drkp(at)csail(dot)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Small SSI issues
Date: 2011-06-12 20:01:10
Message-ID: 4DF51B06.8030701@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2011-06-12 20:56:54 Re: Detailed documentation for external calls (threading, shared resources etc)
Previous Message Robert Haas 2011-06-12 19:57:08 reducing the overhead of frequent table locks, v3