Store the snapshot for the initial load in the correct memory context.

Although the correct context (TopMemoryContext) is set explicitly, it appears
that DecodingContextFindStartpoint() (PG core) can change it to
TopTransactionContext. This can happen if cache invalidations are processed at
certain stage of the setup of the logical decoding system. In practice, cache
invalidations take place when DDL commands are executed.

If the wrong memory context is used, the snapshot for the initial load can get
corrupted, which in turn can cause ERROR (i.e. failure complete the squeezing,
in which case all the work done by the extension gets rolled
back). Unfortunately, at specific circumstances, data loss might probably take
place instead, although I haven't heard about such a case so far.

This bug only affects "manual" processing of tables, i.e. cases where the
squeeze.squeeze_table() function is used. It does not affect cases where the
scheduler worker is involved (shared memory is used then).

Author: Antonin Houska

worker.c

@@ -1560,6 +1560,8 @@ create_replication_slots(int nslots, MemoryContext mcxt)
 		 * transactions to finish, so it should not be done by the workers.
 		 */
 		DecodingContextFindStartpoint(ctx);
+		/* The call above could have changed the memory context.*/
+		MemoryContextSwitchTo(mcxt);
 
 		/* Get the values the caller is interested int. */
 		res_ptr->confirmed_flush = slot->data.confirmed_flush;
@@ -1588,7 +1590,8 @@ create_replication_slots(int nslots, MemoryContext mcxt)
 		{
 			res_ptr->snap_seg = NULL;
 			res_ptr->snap_handle = DSM_HANDLE_INVALID;
-			snap_dst = res_ptr->snap_private = (char *) palloc(snap_size);
+			snap_dst = (char *) MemoryContextAlloc(mcxt, snap_size);
+			res_ptr->snap_private = snap_dst;
 		}
 		/*
 		 * XXX Should we care about alignment? The function doesn't seem to