Tom Lane <[EMAIL PROTECTED]> writes:
> (Your proposed fix seems entirely useless ...
While there are reasons to argue that's Perl fault, IMO, an
environment that reflects the current state of the host program is a
good compromise, and behave environment-consistent is also a good
compromise for l
That was it. There were two in there. I rolled 'em back and everything is
smooth now. Thanks a lot.
Jess
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, December 19, 2005 10:03 PM
To: Jess Balint
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Lock issue
From contrib/lo I found that it has something difference between old and new version of PostgreSQL. And I'm sure that I already tick on Large Object (lo) option when I install.
How can I manage on difference function?
:::New Version:::
DOMAIN lo AS pg_catalog.oid;
FUNCTION lo_oid(lo)
Manuel Sugawara writes:
> Some fprintf's around the regex code shows that someone is changing
> the localization parameters by those found in the enviroment, at least
> for the LC_CTYPE and LC_COLLATE categories, and plperl seems to be the
> culprit.
Indeed. Please file a bug with the Perl peopl
Here is a test case for a previously reported bug (see
http://archives.postgresql.org/pgsql-general/2005-11/msg01235.php):
initdb using es_MX.ISO-8859-1, start postgres using es_MX.UTF-8 and
execute:
create procedural language plperl;
create or replace function foo() returns int as 'return 1' lan
"Jess Balint" <[EMAIL PROTECTED]> writes:
> Hi, I have a database that had a large table in it. I dropped the table, but
> when I try to full vacuum the db, it just freezes indefinitely. There are
> shared locks held on this that I can't identify. I've tried bouncing this
> instance and ran some qu
I've already implemented this in phpPgAdmin trivially using the md5()
function. I can't be bothered using a C library function :D
IIRC the whole point of this exercise was to avoid passing the password
to the server in the first place. Unless you are talking about a PHP
md5() password of cours
Christopher Kings-Lynne wrote:
> By the way,
>
> I've already implemented this in phpPgAdmin trivially using the md5()
> function. I can't be bothered using a C library function :D
IIRC the whole point of this exercise was to avoid passing the password
to the server in the first place. Unless
By the way,
I've already implemented this in phpPgAdmin trivially using the md5()
function. I can't be bothered using a C library function :D
Chris
Dave Page wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 19 December 2005 05:37
To: Christopher Kings-
On Mon, Dec 19, 2005 at 06:34:38PM -0500, Tom Lane wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> > On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
> >> Perhaps a more relevant question is why ecpg/preproc is including
> >> that header.
>
> > #include with -D_REENTRANT includes it.
Albert Chin <[EMAIL PROTECTED]> writes:
> On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
>> Perhaps a more relevant question is why ecpg/preproc is including
>> that header.
> #include with -D_REENTRANT includes it.
> preproc.c:
> #include "postgres_fe.h"
> #include "c.h"
>
Hi, I have a database that had a large table in it. I dropped the table, but
when I try to full vacuum the db, it just freezes indefinitely. There are
shared locks held on this that I can't identify. I've tried bouncing this
instance and ran some queries immediately after starting up. The results a
On Mon, Dec 19, 2005 at 05:59:12PM -0500, Tom Lane wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> > The problem is that /usr/include/arpa/nameser_compat.h defines a
> > struct named HEADER. This conflicts with the use of preproc.y in
> > src/interfaces/ecpg/preproc/preproc.y.
>
> > What should
Albert Chin <[EMAIL PROTECTED]> writes:
> The problem is that /usr/include/arpa/nameser_compat.h defines a
> struct named HEADER. This conflicts with the use of preproc.y in
> src/interfaces/ecpg/preproc/preproc.y.
> What should it be renamed to?
Perhaps a more relevant question is why ecpg/prepr
This would be handy for testing high-concurrency workloads.
http://blogs.sun.com/roller/page/jonathan/20051218
-Mike
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Martijn van Oosterhout writes:
Are there any reasons why we shouldn't change the libname with every
release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new f
While building 8.1.1 on Tru64 UNIX 5.1:
gmake[5]: Leaving directory `/opt/build/postgresql-8.1.1/src/port'
cc -O2 -ieee -msym -readonly_strings -pthread --thread-safe
-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I./../include
-I. -I../../../../src/include -I/opt/TWWfsw/gettext014/includ
On Sat, Dec 17, 2005 at 01:07:10PM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > Is cardinality the only thing we'd need to worry about? My idea was
> > actually to track the amount of work normally required by a stored query
> > plan, and if a query uses that plan but requires a very diffe
Peter Eisentraut said:
>
> So it appears that pg_md5_encrypt is not officially exported from
> libpq. Does anyone see a problem with adding it to the export list
> and the header file?
>
Well, these changes have broken the windows build, so something needs to
change.I don't see a reason in pr
Martin,
On 12/19/05 3:37 AM, "Martijn van Oosterhout" wrote:
> I'm not sure whether we have a conclusion here, but I do have one
> question: is there a significant difference in the number of times the
> comparison routines are called? Comparisons in PostgreSQL are fairly
> expensive given the f
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 15:00
> To: Martijn van Oosterhout
> Cc: Dave Page; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side p
Martijn van Oosterhout writes:
> Are there any reasons why we shouldn't change the libname with every
> release like for UNIX? I can't think of any, but you never know...
Surely that cure is far worse than the disease. You'd be trading a
might-break risk (app using new function will fail if used
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 14:50
> To: Dave Page; Martijn van Oosterhout
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: RE: [HACKERS] [pgadmin-hacke
> > Yes.
> > If FooApp is compiled against 8.0, it will then be unable to run if
> > you upgrade libpq to 8.1. IIRC on Unix it will "fall
> forward" to the
> > new version if it's just a minor version upgrade (correct me if I'm
> > wrong).
> > On windows, it will break with an ugly dialog box.
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 12:07
> To: Martijn van Oosterhout; Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: RE: [HACKERS] [pgadmin-hacke
Martijn van Oosterhout wrote:
So it's only an issue if you have a policy of removing old versions of
libpq on upgrades... I'm not sure what's "best practice" on windows in
this area.
When removing the application (in this case: pgsql), you'd remove that
old lib as well if it's the only app u
On Mon, Dec 19, 2005 at 01:07:26PM +0100, Magnus Hagander wrote:
> If FooApp is compiled against 8.0, it will then be unable to run if you
> upgrade libpq to 8.1. IIRC on Unix it will "fall forward" to the new
> version if it's just a minor version upgrade (correct me if I'm wrong).
> On windows, i
> > > As for Windows DLL hell, I don't know a lot about that, but if
> > > that's such a problem, why didn't the original creators of the
> > > windows port stick the version number in there from the start. On
> > > UNIX, libpq is half versioned (the library is, but not
> the symbols)
> > > so
On Fri, Dec 16, 2005 at 10:43:58PM -0800, Dann Corbit wrote:
> I am actually quite impressed with the excellence of Bentley's sort out
> of the box. It's definitely the best library implementation of a sort I
> have seen.
I'm not sure whether we have a conclusion here, but I do have one
question:
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 10:42
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side p
On Mon, Dec 19, 2005 at 10:32:03AM -, Dave Page wrote:
>
> > As for Windows DLL hell, I don't know a lot about that, but if that's
> > such a problem, why didn't the original creators of the windows port
> > stick the version number in there from the start. On UNIX, libpq is
> > half versioned
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 09:38
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side p
On Mon, Dec 19, 2005 at 09:16:19AM -, Dave Page wrote:
> > > > Something like
> > > > char *pg_gen_encrypted_passwd(const char *passwd, const
> > > > char *user)
> > > > with malloc'd result (or NULL on failure) seems more future-proof.
> > If programs are really worried about it, the
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 08:59
> To: Dave Page
> Cc: Tom Lane; Christopher Kings-Lynne; Peter Eisentraut;
> pgsql-hackers@postgresql.org; Andreas Pflug
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side p
On Mon, Dec 19, 2005 at 08:51:23AM -, Dave Page wrote:
> > Something like
> > char *pg_gen_encrypted_passwd(const char *passwd, const
> > char *user)
> > with malloc'd result (or NULL on failure) seems more future-proof.
>
> Changing the API is likely to cause fun on Windows for new apps
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 19 December 2005 05:37
> To: Christopher Kings-Lynne
> Cc: Peter Eisentraut; pgsql-hackers@postgresql.org; Andreas
> Pflug; Dave Page
> Subject: Re: [HACKERS] [pgadmin-hackers] Client-side password
> encryption
>
Tom Lane wrote:
>OKADA Satoshi <[EMAIL PROTECTED]> writes:
>
>
>>The loss of log was simulated by deleting the latest xlog file.
>>
>>
>
>What does that have to do with reality? Postgres is very careful not to
>use an xlog file until it's been fully metadata-synced. You might as
>well com
37 matches
Mail list logo
