On Tue, Oct 18, 2016 at 11:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote:
>> The cleanest fix might be to change those various "long" variables
>> to uint32. You'd have to think about how to handle the ntohl/htonl
>> calls that are used on them, though.
> Or actually, no, you wouldn't have to think very hard. I was supposing
> that those calls were declared to traffic in "long"s, but they aren't
> and never have been, at least not since SUSv2:
> uint32_t htonl(uint32_t hostlong);
> uint16_t htons(uint16_t hostshort);
> uint32_t ntohl(uint32_t netlong);
> uint16_t ntohs(uint16_t netshort);
> So s/long/uint32/ would probably fix it just fine.
The pg_strong_random patch has been reverted, what's done is done.
FWIW only doing that is needed to fix the problem as already mentioned
diff --git a/src/backend/utils/init/globals.c b/src/backend/utils/init/globals.c
index f232083..634578d 100644
@@ -38,7 +38,7 @@ volatile uint32 CritSectionCount = 0;
struct Port *MyProcPort;
diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h
index 78545da..5e623a1 100644
@@ -162,7 +162,7 @@ extern PGDLLIMPORT int MyProcPid;
extern PGDLLIMPORT pg_time_t MyStartTime;
extern PGDLLIMPORT struct Port *MyProcPort;
extern PGDLLIMPORT struct Latch *MyLatch;
-extern long MyCancelKey;
+extern uint32 MyCancelKey;
extern int MyPMChildSlot;
extern char OutputFileName;
I'll send an update for that, as well as a solution for the pademelon
problem on the SCRAM thread.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: