Re: [BUGS] BUG #1567: can't hide password with pg_autovacuum

2005-04-03 Thread Bruno Wolff III
On Tue, Mar 29, 2005 at 03:54:48 +0100,
  Olivier Thauvin <[EMAIL PROTECTED]> wrote:
> 
> Maybe I will workaround by setting postgres user access as 'trust' for local 
> connection only, but I have to reread the doc before :).

Ident is better if you can use domain sockets and the equivalent of
getpeerid on your OS.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [BUGS] BUG #1576: Function UPPER does not give back the awaited results

2005-04-03 Thread Magnus Hagander
>Bug reference:  1576
>Logged by:  Sergio Luis SÃÂnchez
>Email address:  [EMAIL PROTECTED]
>PostgreSQL version: 7.4.3 and 8.0.1
>Operating system:   linux (7.4.3) and WinXP (8.0.1)
>Description:Function UPPER does not give back the 
>awaited results
>Details: 
>
>Hi. 
>
>I'm from Spain, and I am using a PostgreSQL as database 
>system. Sorry for my
>English.
>
>I launch a select with the upper function to retrieve a text in capital
>letters. When I launch the function to text with accents 
>(Usual in Spanish
>language), I get the marked words in lowercase, and it's wrong.
>
>To test it I launh this query:
>
>select upper('aeiouÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ');
>
>And the result was: "AEIOUÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂÃÂ", when it 
>must be
>"AEIOUÃÂÃâÃÂÃâÃÅÃâÃËÃÅÃâÃâ".
>
>I try this function with UNICODE and LATIN1 encodings, and I 
>retrieve same result.

It shouldn't work in UNICODE - see 
http://pginstaller.projects.postgresql.org/FAQ_windows.html#2.6.

It should work in LATIN1 though. I've never had any problems with that part 
(use it for swedish chars all the time). Make sure you really switched the 
server side encoding (new initdb), and not just the client side.

//Magnus

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [BUGS] windows installation

2005-04-03 Thread Magnus Hagander
>ok. 
>i succesfully installed postgresql 8 on my windows xp sp2 machine, few
>weeks ago. i am a newbie to sql generally, as well as to postrges
>i configured my server to run on localhost, everything was fine. i
>need to mention that the machine is part of a active directory
>network, corporate 350+ machines, policies, etc.
>the thing is that i haven't started postrges for about a week, during
>wich time i have not made changes to the machine, nor installed any
>software that could affect the performance/security/policy allready
>running on my machine, a p4 -3,2 HT, 512 DDR, 80 GBsata, a rather nice
>machine, otherwise.
>when i tried to connect to the database, i received an error, that i
>cannot connect to the database as a superuser. i have configured
>.\postgre to run automatically on system start, and worked just fine.
>i only modifyed the tmplate to logon to a custom test database, but i
>worked fine everytime before the pause i already mentioned.
>after varoius error messages, error log, etc i discovered the service
>to have been disabled, and set for deletion.

This usually happens at *uninstall*. Postgresql never reconfigures it's
own service entry - it doesn't even have permissions to do it.

> as i could not modify
>it's state through "normal" procedure - mmc console, i
>regedit-modifyed the service's state to autimatic from disabled.

This is a bit dangerous. You need to modify service stuff through the
service control manager. There is a commandline tool called "sc" that
can do this for you.
The service control keys in the registry are not supposed to be
concurrent-editing safe.

>the thing is, that when i attempt to start, i get an error message that
>the service could not start because it is eighter disabled, or has no
>devices attached to it. in the service's propeties box, at the
>start parameters box - blank. if i need start parameters can u please
>give me some feedback on this regard, or if there's something else,
>please let me know.
>i checked with the network admin, and there is no change 
>lately in the pilocies.

Again, a lot of this looks like an uninstall of the product that did not
complete all the way (if you rebooted at this point, it would probably
be completely gone from the service list)

>i guess it's useful to know that there is a concurrent-login
>prohibiton policy, and event log says

As long as you only run one service, Windows only makes one login for
the user, so this shouldn't be the problem. Do you get this error every
time you try to start the service?

//Magnus

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


[BUGS] Bad mis-costing of Merge Left Join in 8.0.1

2005-04-03 Thread Andrew - Supernews
This came up from a user in the IRC channel; while examining his EXPLAIN
ANALYZE output, we found some rather radical discrepancies in the costs
for a merge join, which was resulting in very suboptimal plans. I was
able to reduce his data to a test case as follows:

create table mjtest1 (id integer primary key, value1 integer,
  padding float8[]);
create table mjtest2 (id integer primary key, value2 integer);
create index mjtest1_idx on mjtest1(value1);
insert into mjtest1
  select i,i%100,
 ARRAY[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
  from generate_series(1,8) as s(i);
insert into mjtest2 select i,i from generate_series(1,10) as s(i);
analyze;
set enable_mergejoin=true;
explain analyze select * from mjtest1 left join mjtest2 using (id)
  where mjtest1.value1 = 5;
set enable_mergejoin=false;
explain analyze select * from mjtest1 left join mjtest2 using (id)
  where mjtest1.value1 = 5;

On my 8.0.1 test setup, I get the following plans:

  QUERY PLAN
   
---
 Merge Left Join  (cost=1.27..6.98 rows=779 width=276) (actual 
time=0.318..114.686 rows=800 loops=1)
   Merge Cond: ("outer".id = "inner".id)
   ->  Index Scan using mjtest1_pkey on mjtest1  (cost=0.00..4402.00 rows=779 
width=272) (actual time=0.103..103.150 rows=800 loops=1)
 Filter: (value1 = 5)
   ->  Sort  (cost=1.27..1.29 rows=10 width=8) (actual time=0.144..0.185 
rows=10 loops=1)
 Sort Key: mjtest2.id
 ->  Seq Scan on mjtest2  (cost=0.00..1.10 rows=10 width=8) (actual 
time=0.019..0.068 rows=10 loops=1)
 Total runtime: 118.181 ms
(8 rows)

 QUERY PLAN 


 Hash Left Join  (cost=1.12..2785.16 rows=779 width=276) (actual 
time=0.314..15.002 rows=800 loops=1)
   Hash Cond: ("outer".id = "inner".id)
   ->  Index Scan using mjtest1_idx on mjtest1  (cost=0.00..2780.13 rows=779 
width=272) (actual time=0.027..6.032 rows=800 loops=1)
 Index Cond: (value1 = 5)
   ->  Hash  (cost=1.10..1.10 rows=10 width=8) (actual time=0.122..0.122 rows=0 
loops=1)
 ->  Seq Scan on mjtest2  (cost=0.00..1.10 rows=10 width=8) (actual 
time=0.018..0.065 rows=10 loops=1)
 Total runtime: 18.415 ms
(7 rows)


The cost for the Merge Left Join is clearly preposterous, since the join
cost can't be lower than the cost of the left branch, as it is an outer
join and therefore that branch must be run to completion. I do not fully
understand the cost estimation code for the merge join, but it appears to
be reducing its total cost estimate below that of the child nodes on the
assumption that the join can be aborted early, which is clearly not the
case for outer joins.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [BUGS] Bad mis-costing of Merge Left Join in 8.0.1

2005-04-03 Thread Tom Lane
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> The cost for the Merge Left Join is clearly preposterous, since the join
> cost can't be lower than the cost of the left branch, as it is an outer
> join and therefore that branch must be run to completion. I do not fully
> understand the cost estimation code for the merge join, but it appears to
> be reducing its total cost estimate below that of the child nodes on the
> assumption that the join can be aborted early, which is clearly not the
> case for outer joins.

Yeah, you're right ... it needs to consider whether the join is OUTER.
This bug has been there for a long time ...

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings