| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Arbitary file size limit in twophase.c |
| Date: | 2008-05-16 10:00:22 |
| Message-ID: | 482D5B36.8020706@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> If we're going to check for file length, we should definitely check the
>> file length when we write it, so that we fail at PREPARE time, and not
>> at COMMIT time.
>
> I think this is mere self-delusion, unfortunately. You can never be
> certain at prepare time that a large alloc will succeed sometime later
> in a different process.
>
> Gavin's complaint is essentially that a randomly chosen hard limit is
> bad, and I agree with that. Choosing a larger hard limit doesn't make
> it less random.
>
> It might be worth checking at prepare that the file size doesn't exceed
> MaxAllocSize, but any smaller limit strikes me as (a) unnecessarily
> restrictive and (b) not actually creating any useful guarantee.
Hmm, I guess you're right.
Patch attached. I can't commit it myself right now, but will do so as
soon as I can, unless there's objections.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| remove-twophase-file-size-limit-1.patch | text/x-diff | 1.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kenneth Marshall | 2008-05-16 13:04:42 | Re: [GSoC08]some detail plan of improving hash index |
| Previous Message | Pavan Deolasee | 2008-05-16 08:53:09 | Re: deadlock while doing VACUUM and DROP |