Re: [BUGS] BUG #3868: Unattended install fails
On Fri, Jan 11, 2008 at 02:30:20PM +, Jan Arne Hansen wrote: > > The following bug has been logged online: > > Bug reference: 3868 > Logged by: Jan Arne Hansen > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.6 > Operating system: Windows Vista > Description:Unattended install fails > Details: > > mkdir c:\postgres > msiexec /i postgresql-8.2-int.msi /qr INTERNALLAUNCH=1 DOSERVICE=0 > ADDLOCAL=server,psql,binfiles,jdbc,psqlodbc SUPERPASSWORD="sitt0" > BASEDIR="c:\postgres" /L* log.txt > > I am not able to install PostgreSQL as a service. The user is not created. > XP is ok, Vista is not. This example fails as well, even when I am not > installing the service. User creation on Vista is not supported on 8.2. It is be supported in 8.3. I think you can also get it working if you use the EnterpriseDB Postgres distribution for 8.2, which uses the installer code from 8.3. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #3868: Unattended install fails
The following bug has been logged online: Bug reference: 3868 Logged by: Jan Arne Hansen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Windows Vista Description:Unattended install fails Details: mkdir c:\postgres msiexec /i postgresql-8.2-int.msi /qr INTERNALLAUNCH=1 DOSERVICE=0 ADDLOCAL=server,psql,binfiles,jdbc,psqlodbc SUPERPASSWORD="sitt0" BASEDIR="c:\postgres" /L* log.txt I am not able to install PostgreSQL as a service. The user is not created. XP is ok, Vista is not. This example fails as well, even when I am not installing the service. Please advise. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3852: Could not create complex aggregate
Joe Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think we could make enforce_generic_type_consistency() clearer by >> adding an additional argument "bool allow_poly" which specifies >> whether polymorphic "actual" argument and result types are allowed. > This sounds like a reasonable plan to me. >> Although this problem really goes quite far back, I think it's probably >> not interesting to back-patch further than 8.2, because AFAICS the >> interesting cases involve aggregates with more than one argument. > I agree, especially since this is the first time anyone has complained. I've applied a patch along these lines, although I desisted from back-patching it. It seems a bit like a new feature, and also I'm not 100% sure we have all the bases covered even yet. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] [SQL] (possible) bug with constraint exclusion
"Rajesh Kumar Mallah" <[EMAIL PROTECTED]> writes: > looks like constraint exclusion is being too aggressive in excluding null > values Hmm, you're right. Looks like I broke it here: http://archives.postgresql.org/pgsql-committers/2007-05/msg00187.php > although its well known that check constraints apply on not null values only. No, that is not a correct statement either --- it's exactly that type of sloppy thinking that got me into trouble with this patch :-( The problem is that predicate_refuted_by_simple_clause() is failing to distinguish whether "refutes" means "proves false" or "proves not true". For constraint exclusion we have to use the stricter "proves false" interpretation, and in that scenario a clause "foo IS NULL" fails to refute a check constraint "foo > 0", because the latter will produce NULL which isn't false and therefore doesn't cause the check constraint to fail. The motivation for that patch was to support IS NULL as one partition of a partitioned table. Thinking about it I see that if the other partitions have check constraints like "foo > 0" then the partitioning is actually incorrect, because the other check constraints are failing to exclude NULLs. The right way to set up such a partitioned table is to include "foo IS NOT NULL" as part of the check constraint, or as a special-purpose NOT NULL flag, except in the IS NULL partition. The current constraint exclusion logic fails to notice attnotnull, though. So the correct fix seems to be: * Fix predicate_refuted_by_simple_clause to not suppose that a strict operator is proved FALSE by an IS NULL clause. * Fix relation_excluded_by_constraints to add "foo IS NOT NULL" clauses to the constraint list for attnotnull columns (perhaps this should be pushed into get_relation_constraints?). This buys back the loss of exclusion from the other change, so long as the partitioning is done correctly. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
