Re: [BUGS] BUG #5653: Error reading the C:/Program Files/PostgreSQL/8.4/data/postgresql.conf"
On Mon, Sep 13, 2010 at 4:48 AM, Kesavan wrote: > Hi > > OS : Windows XP Professional SP3. > Due to some of our product limitation, right now we can't migrate to > 8.4.4. Hence we have to stick to 8.4.0-1. > > Kindly provide me the root causes of this issue so that I can avoid > those pitfalls. Also if the issue comes, is there any script to complete > the installation manually. I don't recall all of the root causes - but suffice it to say that some of them are not necessarily feasible to work around anyway. There are numerous other fixes in 8.4.4, which is 100% compatible with 8.4.0 (we have a strict bug-fix only policy for minor releases, unlike some other DBMSs). There really is no good reason to not use the newer version, especially as you haven't installed yet. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5653: Error reading the C:/Program Files/PostgreSQL/8.4/data/postgresql.conf"
On 13/09/10 17:10, Dave Page wrote: > On Mon, Sep 13, 2010 at 4:48 AM, Kesavan wrote: >> Hi >> >> OS : Windows XP Professional SP3. >> Due to some of our product limitation, right now we can't migrate to >> 8.4.4. Hence we have to stick to 8.4.0-1. >> >> Kindly provide me the root causes of this issue so that I can avoid >> those pitfalls. Also if the issue comes, is there any script to complete >> the installation manually. > > I don't recall all of the root causes - but suffice it to say that > some of them are not necessarily feasible to work around anyway. > > There are numerous other fixes in 8.4.4, which is 100% compatible with > 8.4.0 (we have a strict bug-fix only policy for minor releases, unlike > some other DBMSs). There really is no good reason to not use the newer > version, especially as you haven't installed yet. I've added a FAQ entry for this, as we've had more people with odd ideas about updates lately. It needs a shorter title ;-) but otherwise should cover things. As usual, check/editing appreciated. http://wiki.postgresql.org/wiki/FAQ#A_bug_I.27m_encountering_is_fixed_in_a_newer_minor_release_of_PostgreSQL.2C_but_I_don.27t_want_to_upgrade._Can_I_get_a_patch_for_just_this_issue.3F -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5653: Error reading the C:/Program Files/PostgreSQL/8.4/data/postgresql.conf"
On Mon, Sep 13, 2010 at 11:12 AM, Craig Ringer wrote: > On 13/09/10 17:10, Dave Page wrote: >> On Mon, Sep 13, 2010 at 4:48 AM, Kesavan wrote: >>> Hi >>> >>> OS : Windows XP Professional SP3. >>> Due to some of our product limitation, right now we can't migrate to >>> 8.4.4. Hence we have to stick to 8.4.0-1. >>> >>> Kindly provide me the root causes of this issue so that I can avoid >>> those pitfalls. Also if the issue comes, is there any script to complete >>> the installation manually. >> >> I don't recall all of the root causes - but suffice it to say that >> some of them are not necessarily feasible to work around anyway. >> >> There are numerous other fixes in 8.4.4, which is 100% compatible with >> 8.4.0 (we have a strict bug-fix only policy for minor releases, unlike >> some other DBMSs). There really is no good reason to not use the newer >> version, especially as you haven't installed yet. > > I've added a FAQ entry for this, as we've had more people with odd ideas > about updates lately. It needs a shorter title ;-) but otherwise should > cover things. > > As usual, check/editing appreciated. Thanks Craig. I wonder if it's worth mentioning that patching your own build will also take more time/effort, and will require the same amount of downtime as a normal upgrade. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5653: Error reading the C:/Program Files/PostgreSQL/8.4/data/postgresql.conf"
Craig: > I've added a FAQ entry for this, as we've had more people with odd ideas > about updates lately. It needs a shorter title ;-) but otherwise should > cover things. > > As usual, check/editing appreciated. http://wiki.postgresql.org/wiki/FAQ#A_bug_I.27m_encountering_is_fixed_in_a_newer_minor_release_of_PostgreSQL.2C_but_I_don.27t_want_to_upgrade._Can_I_get_a_patch_for_just_this_issue.3F I wanna suggest to have some words other DB-Vendors use for what is similiar to our ..x releases; as in equivalent to what O and MS calls "patchset", and I calls "WarpLevel", and My calls "whatever"; way less intrusive then what MS calls "ServicePacks" Is somebody fluent enough in O/MS/I-speak to know those words? Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5653: Error reading the C:/Program Files/PostgreSQL/8.4/data/postgresql.conf"
Hi OS : Windows XP Professional SP3. Due to some of our product limitation, right now we can't migrate to 8.4.4. Hence we have to stick to 8.4.0-1. Kindly provide me the root causes of this issue so that I can avoid those pitfalls. Also if the issue comes, is there any script to complete the installation manually. Thanks in advance. Regards S.Kesavan On 9/13/2010 12:15 AM, Dave Page wrote: > On Sun, Sep 12, 2010 at 7:32 PM, John R Pierce wrote: > >> On 09/12/10 8:23 AM, Kesavan wrote: >> >>> PostgreSQL version: 8.4.0-1 >>> Operating system: Windows >>> >> >> 8.4.0? thats rather old 8.4.4 is the current build of the 8.4 family, >> and the bug fixes listed in the release notes for each of the interrim >> versions (8.4.1, .2, .3, .4) are fairly long. >> > Yeah - the installer has also had numerous bug fixes since then; at > least some of which address many of the common causes of this > particular error. > > signature.asc Description: OpenPGP digital signature
[BUGS] BUG #5654: Deferred Constraints don't work
The following bug has been logged online: Bug reference: 5654 Logged by: Daniel Howard Email address: cheesero...@yahoo.com PostgreSQL version: 8.4.4 Operating system: Linux (Ubuntu 10.04.1) Description:Deferred Constraints don't work Details: The command SET CONSTRAINTS ALL DEFERRED seems to have no effect. According to the manual here: http://www.postgresql.org/docs/8.4/interactive/sql-set-constraints.html If a constraint is defined as deferrable, then you can instruct postgres to wait until the end of a transaction block before checking the constraint. This is supposed to work for foreign key constraints. The simple test case below demonstrates that postgres ignores the set constraint command and checks the constraint in the middle of a transaction. -- Setup two tables, users and items. One user can have many items. CREATE TABLE users (id serial PRIMARY KEY, name text NOT NULL); --NOTICE: CREATE TABLE will create implicit sequence "users_id_seq" for serial column "users.id" --NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "users_pkey" for table "users" --CREATE TABLE INSERT INTO users (id, name) VALUES (1,'Daniel'); --INSERT 0 1 CREATE TABLE items (id serial PRIMARY KEY, user_id integer NOT NULL REFERENCES users ON DELETE RESTRICT DEFERRABLE, itemname text); --NOTICE: CREATE TABLE will create implicit sequence "items_id_seq" for serial column "items.id" --NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "items_pkey" for table "items" --CREATE TABLE INSERT INTO items (user_id, itemname) VALUES (1,'hat'); --INSERT 0 1 -- -- Expect the following to fail because of the foreign key constraint DELETE FROM users; --ERROR: update or delete on table "users" violates foreign key constraint "items_user_id_fkey" on table "items" --DETAIL: Key (id)=(1) is still referenced from table "items". -- -- Try it in a transaction with the constraint deferred BEGIN; --BEGIN SET CONSTRAINTS ALL DEFERRED; --SET CONSTRAINTS -- This time it should work, because the constraint shouldn't be checked until the end of the transaction DELETE FROM users; --ERROR: update or delete on table "users" violates foreign key constraint "items_user_id_fkey" on table "items" --DETAIL: Key (id)=(1) is still referenced from table "items". ROLLBACK; --ROLLBACK -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5654: Deferred Constraints don't work
"Daniel Howard" writes: > The command > SET CONSTRAINTS ALL DEFERRED > seems to have no effect. Yes it does. For instance, in your example setting the mode to deferred will allow you to insert an items row that doesn't match any users row: regression=# insert into items(user_id) values(42); ERROR: insert or update on table "items" violates foreign key constraint "items_user_id_fkey" DETAIL: Key (user_id)=(42) is not present in table "users". regression=# begin; BEGIN regression=# SET CONSTRAINTS ALL DEFERRED; SET CONSTRAINTS regression=# insert into items(user_id) values(42); INSERT 0 1 regression=# commit; ERROR: insert or update on table "items" violates foreign key constraint "items_user_id_fkey" DETAIL: Key (user_id)=(42) is not present in table "users". regression=# What you wrote is > CREATE TABLE items (id serial PRIMARY KEY, user_id integer NOT NULL > REFERENCES users ON DELETE RESTRICT DEFERRABLE, itemname text); The ON DELETE RESTRICT part is a "referential action", not a constraint as such. Our reading of the SQL standard is that referential actions happen immediately regardless of deferrability of the constraint part. So that's why you get an error on deletion of a users row. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.0 Bug: cannot build against python3.1, with two versions of python in the environment
The correct way to do what he wants to do is configure PYTHON=/usr/local/bin/python3.1 ... other options ... On lör, 2010-09-11 at 17:22 -0700, Josh Berkus wrote: > I discussed this report with James Pye already, and he beleives it's a > configure script bug which should be fixed before release. Anyone > capable of taking it on? > > Original Message > Subject: [TESTERS] Configure/Build 9.0 rc1 - cannot build against > python3.1, with two versions of python in the environment > Date: Sat, 11 Sep 2010 13:12:13 -0400 > From: Lou Picciano > To: pgsql-test...@postgresql.org > > > > *[TEST REPORT]* > *[Release]:* 9.0 RC1 > *[Test Type]:* Install (Build) > *[Test]:* Configure/Build 9.0 rc1 - cannot build against python3.1, with > two versions of python in the environment > *[Platform]:* Solaris 10 Sparc E450 Quad > *[Parameters]:* > --with-python \ > * > --with-includes=/usr/local/include/python3.1:/usr/local/include:/usr/local/ssl/include > > > \ > --with-libraries=/usr/local/lib/python3.1:/usr/local/lib:/usr/local/ssl/lib > \ > CONFIGURE OUTPUT: - > checking for python... /usr/bin/python > checking Python configuration directory... /usr/lib/python2.4/config > checking how to link an embedded Python application... -L/usr/lib > -lpython2.4 -lresolv -lsocket -lnsl -lrt -ldl -lm > configure: using CPPFLAGS= -I/usr/local/include/libxml2 > -I/usr/local/include/python3.1 -I/usr/local/include -I/usr/local/ssl/include > configure: using LDFLAGS= -L/usr/local/lib -L/usr/local/lib/python3.1 > [Failure]:* Can't seem to definitively config PG to a specific version > of python - v3.1, at /usr/local/bin/python3 > *[Results]:* configure seems to pick up python 2.4 configuration, but > apparently links to (desired) python 3.1 libs. > # ldd plpython2.so > libpython2.4.so.1.0 => /usr/lib/libpython2.4.so.1.0 > *[Comments]:* Tried first to see if configure picks up the PYTHONPATH > env variable to find python's configuration. No joy. Using this variable > might be a reasonable approach for configure? > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.0 Bug: cannot build against python3.1, with two versions of python in the environment
Peter Eisentraut writes: > The correct way to do what he wants to do is > configure PYTHON=/usr/local/bin/python3.1 ... other options ... Hm, maybe this isn't adequately documented? Or at least should be cross-referenced where we talk about python2 vs python3? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5655: Composite Type Handles Null Incorrectly
The following bug has been logged online:
Bug reference: 5655
Logged by: Nate Carson
Email address: nate1...@gmail.com
PostgreSQL version: 8.4.4
Operating system: linux 2.6.33-sabayon (gentoo)
Description:Composite Type Handles Null Incorrectly
Details:
I have been using a composite type to handle the different fields of name
i.e. last name, first name, etc. This has been a good solution for handling
names that come from different formats while checking for duplicates.
However, I have found behavior that I do not believe is correct. Selecting
with a not null condition always returns 0 rows with null values for the
type, but querying 'is not null' in a column expression produces expected
results. I can coerce expected behavior by sub-querying 'is not null' on the
type in the inner query and select from the boolean condition in the outer
query.
Below is a script to reproduce behavior.
-- Composite Type Handles Null Incorrectly
drop type if exists t_person_test cascade;
create type t_
person_test as (
fname text,
finit char(1),
mname text,
minit char(1),
lname text,
suffix text
);
drop table if exists test;
create table test ( p t_person_test);
insert into test values
(('Charles','C',null,null,'Dickens',null)::t_person_test),
(null)
;
select p, p is null as pnull from test;
select * from test where p is null;
select * from (select p, p is null as pnull from test) as t where t.pnull =
false;
select * from (select p, p is null as pnull from test) as t where t.pnull =
true;
\echo 'This puts out 0 rows? Should output 1.'
select * from test where p is not null;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
