OK. I see now. It looks like it wouldn't have worked right anyhow,
since the file is installed in $(DESTDIR)$(pkglibdir)/$(POSTGRES_IMP).
So either we need to change backend/Makefile or Makefile.aix, to be
consistent with each other. I would suggest Makefile.aix, since
historically its been ins
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Attached is a revised patch. It became very simple, but I worry that
> one magic number (BUFFERS_PER_ABSORB) is still left.
Have you checked that this version of the patch fixes the problem you
saw originally? Does the problem come back if you change
"Rocco Altier" <[EMAIL PROTECTED]> writes:
> If we take the DESTDIR out of here, where should we get the POSTGRES_IMP
> file from?
In the PGXS case, $(bindir) has been gotten from pg_config, and it's
correct as-is by definition. Adding $(DESTDIR) to it cannot be right.
re
Patch applied, with minor space adjustments to HEAD and 8.1.X. I also
noticed a few earlier examples were missing paragraph formatting.
---
David Fetter wrote:
> Folks,
>
> Please find enclosed a doc patch that adds an exa
On Thu, Jan 19, 2006 at 11:48:54AM -0800, David Fetter wrote:
> On Thu, Jan 19, 2006 at 07:08:28PM +0100, Peter Eisentraut wrote:
> > David Fetter wrote:
> > > It's paper bag time for me. How about a new patch which gives
> > > each contrib project its own directory and places them there?
> >
> >
On Thu, 2006-01-19 at 15:33 -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > The difference between Magnus's and Andrew's is
> > that Magnus used MODULE_big (which means create a shared library), while
> > Andrew used MODULES. So, Magnus's only worked because he was creating a
> > DLL and that
If I understand correctly, atleast for the AIX case, the reason that
Makefile.aix is referencing DESTDIR is for the PGXS case.
I thought that PGXS was supposed to be able to be run after things were
installed, and you might not have the compile tree anymore. Basically,
if you wanted to build some
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What about the question of whether $(DESTDIR) belongs there or not?
> >> I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
> >> because that's only for install-time stuff.
>
> > I considered that a separate issue and
Removed at submitter request.
---
David Fetter wrote:
> On Mon, Jan 16, 2006 at 12:13:11AM -0500, Neil Conway wrote:
> > On Sun, 2006-01-15 at 20:08 -0800, David Fetter wrote:
> > >
> > > ifdef USE_PGXS
> >
> > The ch
Bruce Momjian writes:
> Tom Lane wrote:
>> What about the question of whether $(DESTDIR) belongs there or not?
>> I think we had concluded that PGXS shouldn't ever use $(DESTDIR),
>> because that's only for install-time stuff.
> I considered that a separate issue and didn't explore it, but I thin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> David Fetter wrote:
>> It's paper bag time for me. How about a new patch which gives each
>> contrib project its own directory and places them there?
> This would presumably imply that the installation scripts would be
> renamed to install.sql. On
Tom Lane wrote:
> Bruce Momjian writes:
> > The difference between Magnus's and Andrew's is
> > that Magnus used MODULE_big (which means create a shared library), while
> > Andrew used MODULES. So, Magnus's only worked because he was creating a
> > DLL and that brought in the -L from MODULE_big.
Bruce Momjian writes:
> The difference between Magnus's and Andrew's is
> that Magnus used MODULE_big (which means create a shared library), while
> Andrew used MODULES. So, Magnus's only worked because he was creating a
> DLL and that brought in the -L from MODULE_big.
Ah, good catch.
> I have
OK, I found the cause. Using tests from Magnus and Andrew, I could
reproduce Magnus's success and Andrew's failure in an 8.1.2 pginstaller
install using MinGW. The difference between Magnus's and Andrew's is
that Magnus used MODULE_big (which means create a shared library), while
Andrew used MOD
On Thu, Jan 19, 2006 at 07:08:28PM +0100, Peter Eisentraut wrote:
> David Fetter wrote:
> > It's paper bag time for me. How about a new patch which gives
> > each contrib project its own directory and places them there?
>
> This would presumably imply that the installation scripts would be
> rena
David Fetter wrote:
> It's paper bag time for me. How about a new patch which gives each
> contrib project its own directory and places them there?
This would presumably imply that the installation scripts would be
renamed to install.sql. On a green field this might make sense but as
it is may
Neil Conway <[EMAIL PROTECTED]> writes:
> On Tue, 2006-01-17 at 09:36 -0500, Tom Lane wrote:
>> I suspect you'll find that it's convenient to treat typcache's own
>> link to a tupdesc as a reference count too, so it's not strictly
>> "external" references that should be counted.
> The problem wit
On Thu, Jan 19, 2006 at 02:22:17PM +0100, Peter Eisentraut wrote:
> Am Montag, 16. Januar 2006 06:55 schrieb David Fetter:
> > Oops. My FM R'ing skills need some work. This patch includes the
> > files.
>
> This patch is rather useless because all the uninstall.sql files
> install on top of each
Am Montag, 16. Januar 2006 06:55 schrieb David Fetter:
> Oops. My FM R'ing skills need some work. This patch includes the
> files.
This patch is rather useless because all the uninstall.sql files install on
top of each other. I suggest naming them cube_uninstall.sql
dblink_uninstall.sql etc.
On Tue, 2006-01-17 at 09:36 -0500, Tom Lane wrote:
> I suspect you'll find that it's convenient to treat typcache's own
> link to a tupdesc as a reference count too, so it's not strictly
> "external" references that should be counted.
The problem with this is that incrementing a TupleDesc's refco
Attached is a patch that changes memset to use 'long' instead of 'int32'.
I will also send a test program.
As far as I know, setting memory by 64bit unit is faster than 32bit unit on
64bit CPUs. While there are no changes on 32bit CPUs because 'long' and 'int32'
are same length on them.
The foll
21 matches
Mail list logo
