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: | Raw Message | Whole Thread | 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 |