tqueue.c's record-typmod hashtables need the HASH_BLOBS option.
The keys are integers, not strings. The code accidentally worked on little-endian machines, at least up to 256 distinct record types within a session, but failed utterly on big-endian. This was unexpectedly exposed by a test case added by commit 4452000f3, which apparently is the only parallelizable query in the regression suite that uses more than one anonymous record type. Fortunately, buildfarm member mandrill is big-endian and is running with force_parallel_mode on, so it failed.
This commit is contained in:
parent
69995c3b3f
commit
e1a93dd6ae
@ -402,7 +402,8 @@ tqueueSendTypmodInfo(TQueueDestReceiver *tqueue, int typmod,
|
||||
ctl.entrysize = sizeof(int);
|
||||
ctl.hcxt = TopMemoryContext;
|
||||
tqueue->recordhtab = hash_create("tqueue record hashtable",
|
||||
100, &ctl, HASH_ELEM | HASH_CONTEXT);
|
||||
100, &ctl,
|
||||
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
|
||||
}
|
||||
|
||||
/* Have we already seen this record type? If not, must report it. */
|
||||
@ -877,7 +878,8 @@ TupleQueueHandleControlMessage(TupleQueueReader *reader, Size nbytes,
|
||||
ctl.entrysize = sizeof(RecordTypemodMap);
|
||||
ctl.hcxt = CurTransactionContext;
|
||||
reader->typmodmap = hash_create("typmodmap hashtable",
|
||||
100, &ctl, HASH_ELEM | HASH_CONTEXT);
|
||||
100, &ctl,
|
||||
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
|
||||
}
|
||||
|
||||
/* Create map entry. */
|
||||
|
Loading…
x
Reference in New Issue
Block a user