Re: [PATCH] Windows x64 [repost] - Mailing list pgsql-hackers

From Tsutomu Yamada
Subject Re: [PATCH] Windows x64 [repost]
Date
Msg-id 20091204194251.2ac4c1f1.tsutomu@sraoss.co.jp
Whole thread Raw
In response to [PATCH] Windows x64  (Tsutomu Yamada <tsutomu@sraoss.co.jp>)
Responses Re: [PATCH] Windows x64 [repost]  (Magnus Hagander <magnus@hagander.net>)
Re: [PATCH] Windows x64 [repost]  (Magnus Hagander <magnus@hagander.net>)
Re: [PATCH] Windows x64 [repost]  (Magnus Hagander <magnus@hagander.net>)
Re: [PATCH] Windows x64 [repost]  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Thanks to suggestion.
I send pathces again by another mailer for the archive.

Sorry to waste resources, below is same content that I send before.

Tsutomu Yamada
SRA OSS, Inc. Japan

#####

The following patches support Windows x64.

1) use intptr_t for Datum and pointer macros. (to support Windows LLP64)
   almost the same as that post before.
   http://archives.postgresql.org/pgsql-hackers/2009-06/threads.php#01364

2) use appropriate macro and datatypes for Windows API.
   enables more than 32bits shared memory.

3) Build scripts for MSVC, this came from
   http://archives.postgresql.org/pgsql-hackers/2008-07/msg00440.php
   add new parameters to config.pl.
   You need define "platform" to "x64" for 64bit programs.

-----

Windows x64 binary that applied patch and build with MSVS2005 can pass
all regression tests (vcregress.bat).

I was checked where the string converted with "%ld" is used.
An especially fatal part is not found excluding one of plperl.

But there is still a possibility that elog messages output a incorrect value.
(I thought it is not fatal, ignored these for the present.)

(eg) src/backend/port/win32_shmem.c, line 167
     'size' is 'size_t' = 64bit value.
| ereport(FATAL,
|  (errmsg("could not create shared memory segment: %lu", GetLastError()),
|   errdetail("Failed system call was CreateFileMapping(size=%lu, name=%s).",
|             (unsigned long) size, szShareMem)));

The code that becomes a problem of plperl is the following.
The address is converted into the string, and it is used as hash key.

However, there is really little possibility that two address values
become the same low word, and the problem will not occur.
(Of course, it is necessary to fix though the problem doesn't occur.)


--- src/pl/plperl/plperl.c      2009-11-30 18:56:30.000000000 +0900
+++ /tmp/plperl.c       2009-12-01 18:46:43.000000000 +0900
@@ -95,7 +95,7 @@
  **********************************************************************/
 typedef struct plperl_query_desc
 {
-       char            qname[sizeof(long) * 2 + 1];
+       char            qname[sizeof(void *) * 2 + 1];
        void       *plan;
        int                     nargs;
        Oid                *argtypes;
@@ -2343,7 +2343,8 @@
         ************************************************************/
        qdesc = (plperl_query_desc *) malloc(sizeof(plperl_query_desc));
        MemSet(qdesc, 0, sizeof(plperl_query_desc));
-       snprintf(qdesc->qname, sizeof(qdesc->qname), "%lx", (long) qdesc);
+       /* XXX: for LLP64, use %p or %ll */
+       snprintf(qdesc->qname, sizeof(qdesc->qname), "%p", qdesc);
        qdesc->nargs = argc;
        qdesc->argtypes = (Oid *) malloc(argc * sizeof(Oid));
        qdesc->arginfuncs = (FmgrInfo *) malloc(argc * sizeof(FmgrInfo));


Attachment

pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: [GENERAL] Installing PL/pgSQL by default
Next
From: Simon Riggs
Date:
Subject: Re: Hot standby and removing VACUUM FULL