CurTransactionContext freed before transaction COMMIT ???

From: Gaddam Sai Ram <gaddamsairam(dot)n(at)zohocorp(dot)com>
To: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Cc: "thomasmunro" <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: CurTransactionContext freed before transaction COMMIT ???
Date: 2017-10-24 14:12:13
Message-ID: 15f4eba00ea.ee4594fb875.2293399837734324844@zohocorp.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello people,

We are implementing in-memory index. As a part of that, during index callbacks, under CurTransactionContext, we cache all the DMLs of a transaction in dlist(postgres's doubly linked list).

We registered transaction callback, and in transaction pre-commit event(XACT_EVENT_PRE_COMMIT), we iterate through all cached DMLs(dlist) and populate in my in-memory data structure.

--&gt; For detailed explanation of our implementation, please look into below thread.

https://www.postgresql.org/message-id/15f4ea99b34.e69a4e1b633.8937474039794097334%40zohocorp.com

--&gt; It was working fine until I was greeted with a segmentation fault while accessing dlist!

--&gt; On further examining I found that dlist head is not NULL and it is pointing to some address, but the container I extracted is pointing to 0x7f7f7f7f7f7f7f5f, and I was not able to access any members in my container.

--&gt; https://wiki.postgresql.org/wiki/Developer_FAQ#Why_are_my_variables_full_of_0x7f_bytes.3F

From the above wiki, we came to a conclusion that the memory context in which that dlist was present was freed.

And yes CLOBBER_FREED_MEMORY is enabled by passing --enable-cassert to enable asserts in my code.

--&gt; Normally the memory context inside XACT_EVENT_PRE_COMMIT is TopTransactionContext but in this particular case, the memory context was 'MessageContext'. Little unusual! Not sure why!

--&gt; So basically CurTransactionContext shouldn't get freed before transaction COMMIT.

--&gt; So what has actually happened here??? Kindly help us with your insights!

For your reference, a code snippet of our implementation is pasted below:

Sample code snippet:

/*** Code snippet starts ***/

dlist_head DMLInfo = {{NULL, NULL}};

Insert_callback()

{

old_context = MemoryContextSwitchTo(CurTransactionContext);

GraphIndex_InsertInfo *current;

current = (GraphIndex_InsertInfo *)palloc(sizeof(GraphIndex_InsertInfo));

current-&gt;tableOid = tableOid;

current-&gt;subTransactionID = GetCurrentSubTransactionId();

current-&gt;colValue = (long)values[0]; // Varies with column type

current-&gt;ctid = ctid;

dlist_push_head(&amp;DMLInfo, &amp;current-&gt;list_node);

MemoryContextSwitchTo(old_context);

return TRUE;

}

static void GraphIndex_xactCallback(XactEvent event, void *arg)

{

GraphIndex_Table *tableInfo;

GraphIndex_InsertInfo *current;

dlist_iter iter;

switch (event)

{

case XACT_EVENT_PRE_PREPARE:

case XACT_EVENT_PRE_COMMIT:

PG_TRY();

{

if(DMLInfo.head.next)

{

dlist_reverse_foreach(iter, &amp;DMLInfo)

{

current = dlist_container(GraphIndex_InsertInfo, list_node, iter.cur);

DMLProcessingFunction(current); // This is giving me the ERROR (while accessing members of current)

}

DMLInfo.head.next = NULL;

}

}

PG_CATCH();

{

/* Do cleanup */

}

PG_END_TRY();

break;

case XACT_EVENT_ABORT:

case XACT_EVENT_PARALLEL_ABORT:

/* No cleanup Necessary(No structure created) */

break;

default:

return;

}

}


/*** Code snippet ends ***/

Regards

G. Sai Ram

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message johannes graën 2017-10-24 14:15:59 Re: performance drop after upgrade (9.6 > 10)
Previous Message Tom Lane 2017-10-24 14:09:09 Re: Current int & float overflow checking is slow.