On 06/24/2014 05:47 PM, Alvaro Herrera wrote:
diff --git a/src/backend/storage/smgr/md.c b/src/backend/storage/smgr/md.c
index 3c1c81a..4264373 100644
--- a/src/backend/storage/smgr/md.c
+++ b/src/backend/storage/smgr/md.c
@@ -219,6 +219,16 @@ mdinit(void)
Heikki Linnakangas wrote:
> On 06/21/2014 01:58 PM, Heikki Linnakangas wrote:
> >It's a bit difficult to attach the mark to the palloc calls, as neither
> >the WAL_DEBUG or LWLOCK_STATS code is calling palloc directly, but
> >marking specific MemoryContexts as sanctioned ought to work. I'll take a
Hello,
The patch on compilation gives following error,
mcxt.c: In function ‘MemoryContextAllowInCriticalSection’:
mcxt.c:322: error: ‘struct MemoryContextData’ has no member named
‘allowInCriticalSection’
The member in MemoryContextData is defined as 'allowInCritSection' while
the MemoryContextA
On 2014-06-23 12:58:19 +0300, Heikki Linnakangas wrote:
> On 06/21/2014 01:58 PM, Heikki Linnakangas wrote:
> >It's a bit difficult to attach the mark to the palloc calls, as neither
> >the WAL_DEBUG or LWLOCK_STATS code is calling palloc directly, but
> >marking specific MemoryContexts as sanction
On 06/21/2014 01:58 PM, Heikki Linnakangas wrote:
It's a bit difficult to attach the mark to the palloc calls, as neither
the WAL_DEBUG or LWLOCK_STATS code is calling palloc directly, but
marking specific MemoryContexts as sanctioned ought to work. I'll take a
stab at that.
I came up with the
On 06/15/2014 12:26 AM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
Alvaro Herrera writes:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
no-p
Andres Freund wrote:
> On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > I noticed that HEAD crashes at startup with assertions disabled and
> > > WAL_DEBUG turned on:
> >
> > I'm beginning to think we're going to have to give up on that
> > no-pallocs-in-critical-sec
Andres Freund writes:
> On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
>> I'm beginning to think we're going to have to give up on that
>> no-pallocs-in-critical-sections Assert. It was useful to catch
>> unnecessarily-dangerous allocations in mainline cases, but getting rid
>> of every last corne
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > I noticed that HEAD crashes at startup with assertions disabled and
> > WAL_DEBUG turned on:
>
> I'm beginning to think we're going to have to give up on that
> no-pallocs-in-critical-sections Assert. It was useful to cat
On 2014-06-14 16:53:12 -0400, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > I noticed that HEAD crashes at startup with assertions disabled and
> > WAL_DEBUG turned on:
>
> > I'm using an interim fix by excepting the startup process (see attached
> > patch), like the current code does for chec
Alvaro Herrera writes:
> I noticed that HEAD crashes at startup with assertions disabled and
> WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
no-pallocs-in-critical-sections Assert. It was useful to catch
unnecessarily-dangerous allocations in mainline cases,
Alvaro Herrera wrote:
> I noticed that HEAD crashes at startup with assertions disabled and
> WAL_DEBUG turned on:
> I'm using an interim fix by excepting the startup process (see attached
> patch), like the current code does for checkpointer, but I guess a more
> robust solution should be sought.
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
#2 0x007af987 in ExceptionalCondition (
conditionName=conditionName@entry=0x974448 "!(CritSectionCount == 0 ||
(CurrentMemoryContext) == ErrorContext || (MyAuxProcType ==
CheckpointerProcess))",
13 matches
Mail list logo
