On Fri, Apr 3, 2015 at 9:57 PM, Fujii Masao wrote:
> On Fri, Apr 3, 2015 at 8:37 PM, Michael Paquier
> wrote:
>> On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
>>> Regarding the second patch, you added the checks of the return value of
>>> XLogReaderAllocate(). But it seems half-baked. XLogRe
On Fri, Apr 3, 2015 at 8:37 PM, Michael Paquier
wrote:
> On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
>> Regarding the second patch, you added the checks of the return value of
>> XLogReaderAllocate(). But it seems half-baked. XLogReaderAllocate() still
>> uses palloc(), but don't we need to
On Fri, Apr 3, 2015 at 6:35 PM, Fujii Masao wrote:
> Regarding the second patch, you added the checks of the return value of
> XLogReaderAllocate(). But it seems half-baked. XLogReaderAllocate() still
> uses palloc(), but don't we need to replace it with palloc_extended(), too?
Doh, you are right.
On Fri, Apr 3, 2015 at 2:30 PM, Michael Paquier
wrote:
> On Fri, Apr 3, 2015 at 12:56 PM, Fujii Masao wrote:
>> The first patch looks good to me basically. But I have one comment:
>> shouldn't we expose pg_malloc_extended as a global function like
>> we did pg_malloc? Some frontends might need to
On Fri, Apr 3, 2015 at 12:56 PM, Fujii Masao wrote:
> The first patch looks good to me basically. But I have one comment:
> shouldn't we expose pg_malloc_extended as a global function like
> we did pg_malloc? Some frontends might need to use it in the future.
Yes, it makes sense as the other funct
On Thu, Feb 12, 2015 at 4:02 PM, Michael Paquier
wrote:
> On Wed, Feb 11, 2015 at 2:13 AM, Robert Haas wrote:
>>
>> On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
>> wrote:
>> > On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao
>> > wrote:
>> >> MemoryContextAllocExtended() was added, so isn't it ti
On Thu, Apr 2, 2015 at 9:10 AM, Bruce Momjian wrote:
> Where are we on this?
>
If we want to have allocate_recordbuf error out properly on frontend side,
we are going to need a equivalent of MemoryContextAllocExtended for
frontends in the shape of palloc_extended able to take control flags.
That
On Thu, Feb 12, 2015 at 04:02:52PM +0900, Michael Paquier wrote:
> Yes, why not using palloc_extended instead of palloc_noerror that has been
> clearly rejected in the other thread. Now, for palloc_extended we should copy
> the flags of MemoryContextAllocExtended to fe_memutils.h and have the same
On Wed, Feb 11, 2015 at 2:13 AM, Robert Haas wrote:
> On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
> wrote:
> > On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao
> wrote:
> >> MemoryContextAllocExtended() was added, so isn't it time to replace
> palloc()
> >> with MemoryContextAllocExtended(Curren
On Mon, Feb 9, 2015 at 7:02 AM, Michael Paquier
wrote:
> On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao wrote:
>> MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
>> with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
>> in allocate_recordbuf()?
>
> Y
On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao wrote:
> MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
> with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
> in allocate_recordbuf()?
Yeah, let's move on here, but not with this patch I am afraid as
On Mon, Jan 5, 2015 at 1:25 PM, Michael Paquier
wrote:
> On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas wrote:
>> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
>> wrote:
>>> Hmm. There is no way to check beforehand if a palloc() will fail because of
>>> OOM. We could check for MaxAllocSize, t
Hi,
On 2015-01-05 14:18:35 +0900, Michael Paquier wrote:
> Note that for 9.4, I think that we should complain about an OOM in
> logical.c where malloc is used as now process would simply crash if
> NULL is returned by XLogReaderAllocate. That's the object of the
> second patch.
Yes, that's clearl
On Mon, Dec 29, 2014 at 8:14 PM, Heikki Linnakangas
wrote:
> On 12/26/2014 09:31 AM, Fujii Masao wrote:
>>
>> Hi,
>>
>> While reviewing FPW compression patch, I found that allocate_recordbuf()
>> always returns TRUE though its source code comment says that FALSE is
>> returned if out of memory. It
On Thu, Jan 1, 2015 at 1:10 AM, Robert Haas wrote:
> On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
> wrote:
>> Hmm. There is no way to check beforehand if a palloc() will fail because of
>> OOM. We could check for MaxAllocSize, though.
>
> I think we need a version of palloc that returns NU
On Mon, Dec 29, 2014 at 6:14 AM, Heikki Linnakangas
wrote:
> Hmm. There is no way to check beforehand if a palloc() will fail because of
> OOM. We could check for MaxAllocSize, though.
I think we need a version of palloc that returns NULL instead of
throwing an error. The error-throwing behavior
On 12/26/2014 09:31 AM, Fujii Masao wrote:
Hi,
While reviewing FPW compression patch, I found that allocate_recordbuf()
always returns TRUE though its source code comment says that FALSE is
returned if out of memory. Its return value is checked in two places, but
which is clearly useless.
alloc
Hi,
While reviewing FPW compression patch, I found that allocate_recordbuf()
always returns TRUE though its source code comment says that FALSE is
returned if out of memory. Its return value is checked in two places, but
which is clearly useless.
allocate_recordbuf() was introduced by 7fcbf6a, an
18 matches
Mail list logo
