Tom Lane wrote:
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
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. Oth
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 c
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 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 s
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 "publi
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 availa
> -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 av
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 Cy
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 prefered/recomm
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 contr
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
-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 v
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
anythin
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 whethe
Reini Urban <[EMAIL PROTECTED]> writes:
> Somethink like the attached patch is easier.
> Just replace symlink() for dirs with link() #ifdef __CYGWIN__
Wouldn't it be cleaner to #define symlink as link?
regards, tom lane
---(end of broadcast)--
=?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 i
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.
An
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 a
On Mon, Oct 04, 2004 at 01:55:21PM -0500, 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 t
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, c
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
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
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.
Anyone got any ideas?
Wh
Josh Berkus wrote:
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
On Mon, 4 Oct 2004, Andrew Dunstan wrote:
I trust those of us using CVSup will see the right thing, if we pick up the
new CVSROOT/modules file?
it will most likely require a new checkout for you as well, since you'll
be still using teh 'old paths' ...
cheers
andrew
Marc G. Fournier wrote:
On Mon
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
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
http://developer.postgresql.org/cvsweb.cgi/pgsq
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 a
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.
We're
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 bre
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
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,
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, 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 M
=?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
> fromt_product,t_pri
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
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? i
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 M
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 th
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( sele
On Mon, 4 Oct 2004, Reini Urban wrote:
> Reini Urban schrieb:
> > no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK.
>
> oops, sorry for the noise. of course CYGWIN has it defined in pg_config.h.
> CYGWIN can only do hardlinks (junctions) on directories of course.
>
> maybe HAVE_S
On Mon, 4 Oct 2004, Reini Urban wrote:
> 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 -lpg
Reini Urban schrieb:
no HAVE_SYMLINK defined, though CYGWIN should added -DHAVE_SYMLINK.
oops, sorry for the noise. of course CYGWIN has it defined in pg_config.h.
CYGWIN can only do hardlinks (junctions) on directories of course.
maybe HAVE_SYMLINKS should be extended to HAVE_DIR_SYMLINKS when you
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 ta
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 t
> > >>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
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 bad
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 permissi
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 direc
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 the
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]
>
> 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
> > 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 broad
54 matches
Mail list logo
