Michael Glaesemann wrote:
During Josh Berkus' presentation at the JPUG PostgreSQL Conference, I
was particularly struck by the fact that 8.1 had a shorter beta period
than previous releases, rolled out on time, and enjoyed a longer period
before the first post-release bug was reported. The Post
> >> I will add some trace writes when I get a chance. I was
> rather hoping
> >> something would jump out at you, but obviously it hasn't, so I'll
> >> have to dig into it the slow way. *sigh*
> >
> >
> >
> > Just eyeballing the code it looks to me like the problem is
> this line:
> >
> >
During Josh Berkus' presentation at the JPUG PostgreSQL Conference, I
was particularly struck by the fact that 8.1 had a shorter beta
period than previous releases, rolled out on time, and enjoyed a
longer period before the first post-release bug was reported. The
PostgreSQL Build Farm play
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
I agree with you for production environments, but for development,
test, support (and pre-sales) machines there are reasonable
requirements for several.
I still have to ask what *specifically* you
In the last exciting episode, [EMAIL PROTECTED] (Mark Kirkwood) wrote:
> Mark Woodward wrote:
>> I'm not sure that I agree. At least in my experience, I wouldn't
>> have more than one installation of PostgreSQL in a production
>> machine. It is potentially problematic.
>
> I agree with you for prod
Mark Woodward wrote:
I'm not sure that I agree. At least in my experience, I wouldn't have more
than one installation of PostgreSQL in a production machine. It is
potentially problematic.
I agree with you for production environments, but for development, test,
support (and pre-sales) machine
Quoth [EMAIL PROTECTED] ("Mark Woodward"):
>> Mark Woodward wrote:
>>> As a guy who administers a lot of systems, sometimes over the span of
>>> years, I can not understate the need for "a" place for the admin to
>>> find
>>> what databases are on the machine and where they are located.
>>>
>>> Yo
> Mark Woodward wrote:
>
>> As a guy who administers a lot of systems, sometimes over the span of
>> years, I can not understate the need for "a" place for the admin to
>> find
>> what databases are on the machine and where they are located.
>>
>> Your assertion that this file would "only works fo
Caught exceptions in PL/pgSQL appear to leak memory -- is that
expected? Here's a contrived test case:
CREATE FUNCTION foo(n integer) RETURNS void AS $$
BEGIN
FOR i IN 1 .. n LOOP
BEGIN
RAISE EXCEPTION 'test';
EXCEPTION
WHEN OTHERS THEN
NULL;
I have just noticed some major wrongness about the way initdb handles
userids and the -U argument, dating apparently from an attempted bug fix
in July 2004 at version 1.42 (and thus present in both 8.0 and 8.1)
Illustration below.
I'm too tired to fix it now - will try on the weekend if I ge
Andrew Dunstan wrote:
I wrote:
I will add some trace writes when I get a chance. I was rather hoping
something would jump out at you, but obviously it hasn't, so I'll
have to dig into it the slow way. *sigh*
Just eyeballing the code it looks to me like the problem is this line:
Mark Woodward wrote:
As a guy who administers a lot of systems, sometimes over the span of
years, I can not understate the need for "a" place for the admin to find
what databases are on the machine and where they are located.
Your assertion that this file would "only works for one root-made
in
Albe Laurenz wrote:
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes lon
On Tue, Feb 07, 2006 at 04:11:07PM +0100, Csaba Nagy wrote:
> pg_wal (
> name text,
> walrecords blob,
> iscurrent boolean
> )
ISTM that a current_wal_file() function would be better than a boolean
on the view...
> So, all this said, I'm not too familiar with either C programming or the
>
I wrote:
I will add some trace writes when I get a chance. I was rather hoping
something would jump out at you, but obviously it hasn't, so I'll have
to dig into it the slow way. *sigh*
Just eyeballing the code it looks to me like the problem is this line:
strcat(cmdline, *" --rest
Mark Woodward wrote:
> OK, maybe pg_service.conf is not the right place for this, and that
> maybe a valid argument, but the mechanics involved would be a great
> asset to the admin. Perhaps pg_servers.conf?
I can see that being useful, in terms of providing pg_ctl with a list of
instances to sta
Tom Lane wrote:
> > I don't mind a mechanism that pg_ctl can start more than one
> > database cluster.
>
> You mean "pg_ctl start -D pgdatalocation", no?
No, I mean pg_ctl start -D location1 -D location2, better yet controlled
by a configuration file.
--
Peter Eisentraut
http://developer.postgr
> >Are you running this with an admin account or a non-admin
> account? If
> >admin, what are the permissions on the initdb.exe file and libpq.dll?
> >
> >
>
> Should be unprivileged - it's the account I use to run
> buildfarm. (and which has therefore in each case just
> successfully run "
> "Mark Woodward" <[EMAIL PROTECTED]> writes:
>>> pg_config --sysconfdir
>
>> Hmm, that doesn't show up with pg_config --help.
>
> It's in 8.1.
>
>> One of my difficulties with PostgreSQL is that there is no
>> "standardized"
>> location for where everything is located, i.e. self documenting. If yo
Magnus Hagander wrote:
I get a popup box that says:
initdb.exe has encountered a problem and needs to close.
We are sorry for the inconvenience.
Clicking a link gives this info:
AppName: initdb.exe AppVer: 8.2.0.6051 ModName: msvcrt.dll
ModVer: 7.0.2600.1106Offset: 00033830
I
> >>This took me hours to find ...
> >>
> >>On my Windows box, CVS HEAD gets an execution failure on
> "initdb foo"
> >>but succeeds happily with "initdb -D foo".
> >>
> >>This is not true for REL8_1_STABLE, nor is it true for all Windows
> >>machines/environments, apparently, otherwise we woul
Magnus Hagander wrote:
This took me hours to find ...
On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
but succeeds happily with "initdb -D foo".
This is not true for REL8_1_STABLE, nor is it true for all
Windows machines/environments, apparently, otherwise we would
b
On Tue, 21 Feb 2006, Mark Woodward wrote:
> > Mark Woodward wrote:
> >> The pg_config program needs to display more information, specifically
> >> where the location of pg_service.conf would reside.
> >
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
>
> [EMAIL PRO
"Mark Woodward" <[EMAIL PROTECTED]> writes:
>> pg_config --sysconfdir
> Hmm, that doesn't show up with pg_config --help.
It's in 8.1.
> One of my difficulties with PostgreSQL is that there is no "standardized"
> location for where everything is located, i.e. self documenting. If you
> know that
On Tue, Feb 21, 2006 at 11:14:58AM -0500, Mark Woodward wrote:
> > pg_config --sysconfdir
>
> Hmm, that doesn't show up with pg_config --help.
What version are you using? If I type pg_config without argument it
appears in the list.
> pg_service.conf may currently be considered a "client side" ut
> Mark Woodward wrote:
>> The pg_config program needs to display more information, specifically
>> where the location of pg_service.conf would reside.
>
> pg_config --sysconfdir
Hmm, that doesn't show up with pg_config --help.
[EMAIL PROTECTED]:~$ pg_config --sysconfdir
pg_config: invalid argume
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> pg_ctl -S service_name start
> I don't mind a mechanism that pg_ctl can start more than one database
> cluster.
You mean "pg_ctl start -D pgdatalocation", no?
regards, tom lane
--
> This took me hours to find ...
>
> On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
> but succeeds happily with "initdb -D foo".
>
> This is not true for REL8_1_STABLE, nor is it true for all
> Windows machines/environments, apparently, otherwise we would
> be seeing fa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Mark Woodward wrote:
>> Also, I know I've been harping on this for years (literally), but
>> since the PosgteSQL programs already have the notion that there is
>> some static directory for which to locate files (pg_service.conf),
>> couldn't we also us
"R, Rajesh (STSD)" <[EMAIL PROTECTED]> writes:
> Patch for getaddrinfo.c to recognize ipv6 addresses.
Is this really interesting? Are there machines out there that have
usable support for IPv6 and yet haven't got getaddrinfo?
We've deliberately avoided trying to support ipv6 in our src/port/
sub
On 2/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > On 2/20/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> >> This seems like a pretty bad idea: if the SPI_connect fails you lose
> >> control without having unwound the subtransaction. That's unlikely,
> >> bu
On Tue, Feb 21, 2006 at 09:39:16AM -0500, Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
AIUI it's supposed to be in SYSCONFDIR which is displayed by pg_config.
I believe you can place the other con
Mark Woodward wrote:
> The pg_config program needs to display more information, specifically
> where the location of pg_service.conf would reside.
pg_config --sysconfdir
> Also, I know I've been harping on this for years (literally), but
> since the PosgteSQL programs already have the notion that
The pg_config program needs to display more information, specifically
where the location of pg_service.conf would reside.
Also, I know I've been harping on this for years (literally), but since
the PosgteSQL programs already have the notion that there is some static
directory for which to locate f
This took me hours to find ...
On my Windows box, CVS HEAD gets an execution failure on "initdb foo"
but succeeds happily with "initdb -D foo".
This is not true for REL8_1_STABLE, nor is it true for all Windows
machines/environments, apparently, otherwise we would be seeing failures
from t
Hi,
Late last year I posted some patches for psql but they were deferred
pending the release of 8.2. However, they are not in the patch queue
so I thought I'd bring them up again now the release is done.
1. Dealing with a buggy readline on some platforms w.r.t. --as-needed.
The serious arguments
On Tue, Feb 21, 2006 at 10:02:58AM +0100, Albe Laurenz wrote:
> Thank you also for drawing my attention to pg_service.conf - I have not
> been aware of it.
> There are two 'shortcomings':
> - It still means that you have to change the config file on every
> client.
Well yes. However, you could gen
Thanks to everybody who answered.
Maybe it is really the best thing to use a tool like postgresql-relay or
pgpool - I will investigate these.
I'm not eager to reinvent the wheel.
We have considered relocating DNS entries, but the problem is that a
changed
DNS entry takes long to propagate; in par
38 matches
Mail list logo
