From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Flanagan" <kevin-f(at)linkprior(dot)com> |
Cc: | "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Access violation from palloc, Visual Studio 2005, C-language function |
Date: | 2010-03-10 18:50:30 |
Message-ID: | 18814.1268247030@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Flanagan" <kevin-f(at)linkprior(dot)com> writes:
>>> Hard to tell without seeing the actual code and a stack trace, but I'd
>>> bet that you haven't fully resolved the build process problems you
>>> mentioned earlier.
> I've attached a zip of the (tiny) project, and a text file with the contents
> of the module containing the C-language functions. The only difference from
> sample code is that (as pointed out by Takahiro Itagaki in his post here of
> 8th March) the function implementations need decorating with
> __declspec(dllexport).
Mph. I don't actually believe that, nor do I believe the #define
BUILDING_DLL you put in, because neither of those are needed in any of
our contrib modules. What I suspect at this point is that the reference
to CurrentMemoryContext in the palloc() macro is being bollixed by
having the wrong value for BUILDING_DLL. However, not having a Windows
build environment to experiment with, I'll have to defer to somebody
with more experience in that.
(I wonder BTW if we should rename BUILDING_DLL, because it seems a bit
misnamed. AIUI it's supposed to be set while building the core backend,
not while building loadable modules.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-03-10 18:59:50 | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | David Fetter | 2010-03-10 18:43:54 | Re: [patch] build issues on Win32 |