| Lists: | pgsql-hackers |
|---|
| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | <drkp(at)csail(dot)mit(dot)edu>,<pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Small SSI issues |
| Date: | 2011-06-12 14:59:42 |
| Message-ID: | 4DF48E0E020000250003E502@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
> 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?
>> Do checks such as that argue for keeping the volatile flag, or do
>> you think we can drop it if we make those changes? (That would
>> also allow dropping a number of casts which exist just to avoid
>> warnings.)
>
> I believe we can drop it, I'll double-check.
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.
-Kevin
| Attachment | Content-Type | Size |
|---|---|---|
| ssi-nocast-1.patch | application/octet-stream | 8.2 KB |
| 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 |
| 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