Have you tried using cc_r for that compile line? Does that help?
Alas, that is not an option available.
cc_r is specific to the AIX xlc compiler; we're using GCC, and xlc
is not available to us.
What is missing is a -lpthread .
Andreas
---(end of
Merlin Moncure
The name max_locks_per_transaction indicates a limit of some kind. The
documentation doesn't mention anything about whether that limit is
enforced
or not.
I suggest the additional wording:
This parameter is not a hard limit: No limit is enforced on the
number of
Bruce, while we're pondering on how to solve this, can you put this up
on the open items list so we don't miss it? It's a pretty major issue.
//Magnus
-Original Message-
From: Dave Page [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 30, 2004 11:35 PM
To: [EMAIL PROTECTED]
Bruce Momjian schrieb:
Fabien COELHO wrote:
Dear hackers,
I'm happy to do the pg_dump changes, assuming Tom gets the SET stuff sorted
out.
ISTM that the tablespace handling or ignoring in pg_dump/pg_restore is
still an open issue in current CVS head... waiting for a proper
implementation after
On Mon, 4 Oct 2004, Reini Urban wrote:
But the regression test fails: (the only failing test against cvs HEAD)
This is not only a pg_dump/pg_restore issue, or?
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION '/no/such/location';
ERROR: could not set permissions on directory
Gavin Sherry schrieb:
On Mon, 4 Oct 2004, Reini Urban wrote:
But the regression test fails: (the only failing test against cvs HEAD)
This is not only a pg_dump/pg_restore issue, or?
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION '/no/such/location';
ERROR: could not set
On Mon, 4 Oct 2004, Reini Urban wrote:
Gavin Sherry schrieb:
On Mon, 4 Oct 2004, Reini Urban wrote:
But the regression test fails: (the only failing test against cvs HEAD)
This is not only a pg_dump/pg_restore issue, or?
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION
But the regression test fails: (the only failing test
against cvs
HEAD)
This is not only a pg_dump/pg_restore issue, or?
-- Will fail with bad path
CREATE TABLESPACE badspace LOCATION '/no/such/location';
ERROR: could not set permissions on directory
/no/such/location:
No
OK, added:
o fix MinGW libpq to export only required symbols
o fix MSVC build to export SSL symbols
---
Magnus Hagander wrote:
Bruce, while we're pondering on how to solve this, can you put this up
on
Gavin Sherry schrieb:
On Mon, 4 Oct 2004, Reini Urban wrote:
I cannot recreate on Linux. What platform, etc, are you on?
hmm, I'll investigate then.
postgresql latest CVS with 2 minor shlib building patches left
(added -lpgport)
cygwin-1.5.11
gcc-3.4.1
Hmm.. sounds like we're trying to support
Folks,
Last week one of my students confronted me with a nice little SQL
statement which made me call gdb ...
Consider the following scenario:
[EMAIL PROTECTED] bug]$ cat q1.sql
create temporary sequence seq_ab;
select * from (Select nextval('seq_ab') as nv,
* from(
Gavin Sherry [EMAIL PROTECTED] writes:
I though this may have been the problem. configure.in defines HAVE_SYMLINK
to 1 if we are win32. It seems that for Reini's case we are setting our
template (and PORTNAME) to win32 when I suspect it should be cygwin.
Anyone got any ideas?
What are the
I have found a problem with int64 detection on MinGW. MinGW defines
int64_t but not int64, but configure only looks for int64:
AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar],
[AC_TRY_RUN(
[typedef $1 int64;
What is the proper test? int64 or int64_t?
--
Bruce
Bruce Momjian wrote:
I have found a problem with int64 detection on MinGW. MinGW defines
int64_t but not int64, but configure only looks for int64:
AC_CACHE_CHECK([whether $1 is 64 bits], [Ac_cachevar],
[AC_TRY_RUN(
[typedef $1 int64;
What is the proper test? int64 or
I was comparing the oprofile results of our OLTP workload between
7.5devel and 8.0beta3 test and noticed a new FunctionCall2 in the
8.0beta3 profile that's on the top of the list for PostgreSQL. I
see about an 32% decrease in overall performance. Any suggestions
for determining if FunctionCall2
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
Consider the following scenario:
select * from (Select nextval('seq_ab') as nv,
* from( select
t_product.id,t_text.value,t_price.price
from
On Mon, 4 Oct 2004, Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 04 October 2004 17:17
To: Marc G. Fournier
Cc: Dave Page; PostgreSQL WWW Mailing List
Subject: Re: [pgsql-www] Contrib/earthdistance missing from cvsweb.
Marc G. Fournier wrote:
On
Marc G. Fournier wrote:
If I correctly remember the issue, if I merge earthdistance back into
the main source tree (which is a simple mv operation and cvs update
on the modules file), it will potentially break everyone's currently
checked out CVS source, since the 'paths' will change in the
On Mon, 4 Oct 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
If I correctly remember the issue, if I merge earthdistance back into
the main source tree (which is a simple mv operation and cvs update
on the modules file), it will potentially break everyone's currently
checked out CVS source,
David,
Please find enclosed an example of what I hope to make into a
generalized way of accessing external tabular data via SQL.
This is very cool, and I look forward to playing with it.
However,it seems to me that pgFoundry is the place for it and not /contrib.
We're really trying not to
Marc G. Fournier wrote:
On Mon, 4 Oct 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
If I correctly remember the issue, if I merge earthdistance back into
the main source tree (which is a simple mv operation and cvs update
on the modules file), it will potentially break
Josh Berkus wrote:
David,
Please find enclosed an example of what I hope to make into a
generalized way of accessing external tabular data via SQL.
This is very cool, and I look forward to playing with it.
However,it seems to me that pgFoundry is the place for it and not /contrib.
Tom,
I don't think there's any very clean way to fix this sort of problem in
general. We could make this particular example work if
Frankly, I don't think there *is* any safe way to use volatile functions in
subqueries -- I certainly avoid it, except now() and random() which as
discussed are
On Mon, 4 Oct 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
as far as I know, the only thing that is 'broken' is cvsweb ... and since
it looks directly *at* teh cvs repository, not sure how it breaks that ...
The problem is that
I trust those of us using CVSup will see the right thing, if we pick up
the new CVSROOT/modules file?
cheers
andrew
Marc G. Fournier wrote:
On Mon, 4 Oct 2004, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
as far as I know, the only thing that is 'broken' is cvsweb ... and
since
it
Mark Wong [EMAIL PROTECTED] writes:
Links to results are here:
7.5devel - http://www.osdl.org/projects/dbt2dev/results/dev4-010/128/
8.0beta3 - http://www.osdl.org/projects/dbt2dev/results/dev4-010/180/
Are those cyclic spikes an artifact of the load of the tests? Or are they
artifacts of the
While we're discussing things that will possibly mean a different system
than the current function language, I have another request: Can we have
a means of defining procedures/functions that doesn't involve using
quotes? Having to double-quote everything is extremely annoying and
prone to errors.
I am confused. CVS has in port.h:
#if defined(WIN32) || defined(__CYGWIN__)
/*
* Win32 doesn't have reliable rename/unlink during concurrent access,
* and we need special code to do symlinks.
*/
extern int pgrename(const char *from,
Jim C. Nasby wrote:
While we're discussing things that will possibly mean a different system
than the current function language, I have another request: Can we have
a means of defining procedures/functions that doesn't involve using
quotes? Having to double-quote everything is extremely annoying
Reini Urban schrieb:
Tom Lane schrieb:
Gavin Sherry [EMAIL PROTECTED] writes:
I though this may have been the problem. configure.in defines
HAVE_SYMLINK
to 1 if we are win32. It seems that for Reini's case we are setting our
template (and PORTNAME) to win32 when I suspect it should be cygwin.
=?UTF-8?B?SGFucy1Kw7xyZ2VuIFNjaMO2bmln?= [EMAIL PROTECTED] writes:
Josh Berkus wrote:
Frankly, I don't think there *is* any safe way to use volatile functions in
subqueries -- I certainly avoid it, except now() and random() which as
discussed are special cases.Perhaps a WARNING is in
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused. CVS has in port.h:
so you should already be calling the junction code on Cygwin.
Yeah, I'm sure he is, but it looks from the regression results like it
doesn't quite work on Cygwin. Is that fixable? If so, we'd have a
choice of whether
Tom,
It'd be easy enough to put in the anti-flattening defenses (checks (1)
and (2) in my prior message) but I've got mixed emotions about whether
this is really a good thing to do. Any opinions out there?
If my opinion wasn't clear, I was suggesting adding a WARNING and not doing
anything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This seems very complicated. Why not simply delete the lock files as an
earlier part of the boot process?
Also, I've done a bunch of work on the init script we use here in
production to run multiple backends. It supports the concept of having
multiple
Andrew Hammond [EMAIL PROTECTED] writes:
This seems very complicated. Why not simply delete the lock files as an
earlier part of the boot process?
Primarily because it's not very reasonable to expect rc.sysinit to know
all the places where Postgres data directories might be hiding. I'd
push
FYI:
Soon an experimantal cygwin package will be available via the cywin
setup.exe installer, based on a post-beta3 cvs snapshot from today.
i.e.
* tablespace issues - junctions - not yet solved.
* without the missing earthdistance
Just to gather more feedback from the cygwin folks.
This time
this one got caught by the testfarm as well - it looks like the
openbsd-specific makefile is missing a -fPIC for the Sparc platform(I
would assume that at least NetBSD/sparc is affected too but I don't have
access to such a system to test on).
And I also think that -shared is now
Tom Lane schrieb:
Bruce Momjian [EMAIL PROTECTED] writes:
I am confused. CVS has in port.h:
so you should already be calling the junction code on Cygwin.
true. didn't thought of that. very strange.
Yeah, I'm sure he is, but it looks from the regression results like it
doesn't quite work on
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban
Sent: 04 October 2004 22:17
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [HACKERS] cygwin test package available
FYI:
Soon an experimantal cygwin package will be available
Dave Page schrieb:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Reini Urban
Sent: 04 October 2004 22:17
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [HACKERS] cygwin test package available
FYI:
Soon an experimantal cygwin package will be
Anyone interested ?
Regards
Gaetano Mendola
Gaetano Mendola wrote:
Hi all,
in my development server running a 7.4.5 I can replicate
continuously this error:
ERROR: left link changed unexpectedly
I obtain this with a vacuum full:
test=# vacuum full verbose ua_user_data_exp;
INFO: vacuuming
On Tue, Oct 05, 2004 at 12:08:26AM +0200, Gaetano Mendola wrote:
Anyone interested ?
I saw the code involved, and I think the only way this can happen is if
the index file itself was corrupted by previous operation. How could
that happen elludes me; maybe a previous VACUUM changed a sibling's
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
this one got caught by the testfarm as well - it looks like the
openbsd-specific makefile is missing a -fPIC for the Sparc platform(I
would assume that at least NetBSD/sparc is affected too but I don't have
access to such a system to test on).
Alvaro Herrera wrote:
On Tue, Oct 05, 2004 at 12:08:26AM +0200, Gaetano Mendola wrote:
Anyone interested ?
I saw the code involved, and I think the only way this can happen is if
the index file itself was corrupted by previous operation. How could
that happen elludes me; maybe a previous VACUUM
Why doesn't pg_dump include blob by default? I understand that older
pg_dump didn't deal with blobs, and blobs are now kind of obsolete in
favor of BYTEA/TEXT, but blobs are every bit a part of a database.
Perhaps only exclude blobs when -t is specified? Then -b is required to
include blob.
45 matches
Mail list logo
