[HACKERS] Passwords in PSQL

2005-04-24 Thread Rafaqat Ali
Hello All I am using \c [database] [user-name] to connect to any database. Any one can connect to any database. If any one knows user name, he/she connect to db. I want to provide some security that no one can connect without providing passwords. postg

Re: [HACKERS] CVS regression test problem

2005-04-24 Thread Tom Lane
Oleg Bartunov writes: > On Sun, 24 Apr 2005, Alvaro Herrera wrote: >>> error messages like ! ERROR: unrecognized node type: 516 >> >> I assume you make distclean'd ... > aha, make distclean helps ! Sorry for bothering I added/removed some node types, so if you didn't do a full rebuild you'd pr

Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?

2005-04-24 Thread Tom Lane
Josh Berkus writes: > Tom, how does our heuristic sampling work? Is it pure random sampling, or > page sampling? Manfred probably remembers better than I do, but I think the idea is to approximate pure random sampling as best we can without actually examining every page of the table.

Re: [HACKERS] Old-style OR indexscan slated for destruction

2005-04-24 Thread Christopher Kings-Lynne
For all index types? Even lossy ones? Can't see that a lossy index would make any difference ... OK, was just checking :) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's dataty

Re: [HACKERS] Old-style OR indexscan slated for destruction

2005-04-24 Thread Tom Lane
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > I am about to rip out the code that supports multiple indexscans for OR > conditions inside a single IndexScan plan node. As best I can tell, > the new-style bitmap-OR code is as fast or faster than the old way > even in fully cached test cases

Re: [HACKERS] Old-style OR indexscan slated for destruction

2005-04-24 Thread Christopher Kings-Lynne
I am about to rip out the code that supports multiple indexscans for OR conditions inside a single IndexScan plan node. As best I can tell, the new-style bitmap-OR code is as fast or faster than the old way even in fully cached test cases (ie, with no allowance for improved efficiency of disk acce

Re: [HACKERS] idea for concurrent seqscans

2005-04-24 Thread Bruce Momjian
TODO description added: * Allow sequential scans to take advantage of other concurrent sequentiqal scans, also called "Synchronised Scanning" One possible implementation is to start sequential scans from the lowest numbered buffer in the sha

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Bruce Momjian
Joshua D. Drake wrote: > >> > >>Very close. We don't use the WAL (yet, slated for probably 8.1) but we > >>do use a transaction log shipping method. So the implementation is > >>almost the same. > > > > > > Can you run queries on the slave? If so, how do you handle xid collisions? > > You can

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Joshua D. Drake
Very close. We don't use the WAL (yet, slated for probably 8.1) but we do use a transaction log shipping method. So the implementation is almost the same. Can you run queries on the slave? If so, how do you handle xid collisions? You can run any query that does not modify data on a replicated ta

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Bruce Momjian
Joshua D. Drake wrote: > Alvaro Herrera wrote: > > On Sun, Apr 24, 2005 at 08:10:34AM +0200, Hans-J?rgen Sch?nig wrote: > > > > > >>The idea: We are looking for a way to implement a synchronous > >>single-master / multiple slaves systems. > >>Meanwhile we are able to serialize / deserialize WAL

Re: [HACKERS] CVS regression test problem

2005-04-24 Thread Oleg Bartunov
On Sun, 24 Apr 2005, Alvaro Herrera wrote: On Mon, Apr 25, 2005 at 01:18:29AM +0400, Oleg Bartunov wrote: Just for information. I see many regression tests failed (26 of 96). regression.diffs shows many error messages like ! ERROR: unrecognized node type: 516 Did you initdb? I see no such problem

Re: [HACKERS] CVS regression test problem

2005-04-24 Thread Alvaro Herrera
On Mon, Apr 25, 2005 at 01:18:29AM +0400, Oleg Bartunov wrote: > Just for information. > I see many regression tests failed (26 of 96). regression.diffs shows many > error messages like ! ERROR: unrecognized node type: 516 Did you initdb? I see no such problem with today's tip and my shared row

[HACKERS] CVS regression test problem

2005-04-24 Thread Oleg Bartunov
Just for information. I see many regression tests failed (26 of 96). regression.diffs shows many error messages like ! ERROR: unrecognized node type: 516 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster

Re: [HACKERS] Old-style OR indexscan slated for destruction

2005-04-24 Thread Oleg Bartunov
On Sun, 24 Apr 2005, Tom Lane wrote: I am about to rip out the code that supports multiple indexscans for OR conditions inside a single IndexScan plan node. As best I can tell, the new-style bitmap-OR code is as fast or faster than the old way even in fully cached test cases (ie, with no allowance

Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?

2005-04-24 Thread Marko Ristola
Here is my opinion. I hope this helps. Maybe there is no one good formula: On boolean type, there are at most 3 distinct values. There is an upper bound for fornames in one country. There is an upper bound for last names in one country. There is a fixed number of states and postal codes in one coun

Re: [HACKERS] Postgres: pg_hba.conf, md5, pg_shadow, encrypted

2005-04-24 Thread Antoine Martin
On Sat, 2005-04-23 at 09:02 -0400, Stephen Frost wrote: > * Antoine Martin ([EMAIL PROTECTED]) wrote: > > Basically, multiple input data that have the same output hash, which is > > of no use when what you are trying to find is the input. > > Finding collisions quicker for a known input is one thin

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread Magnus Hagander
That is pretty much where we are ;-) I think we're fine for 8.0.x with this, because if you actually need UTF-8 (and can live with sorting broken, no upper/lower etc), you can do it using a manual initdb. For 8.1, I think the ICU approach looks a lot more promising than trying to do "on the fly co

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread John Hansen
Right, they were meant as a starting point, but if you can point me to how I can obtain the current locale, then I can fix them to cover the remaining 15 special cases. ... John > -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: Monday, April 25, 2005 2:01 AM > To:

Re: [HACKERS] W[i/e]rd performance issue with 8.1cvs

2005-04-24 Thread Josh Berkus
Tom, > I concur with the upthread suggestion that it may come from not doing > checkpoints in a realistic fashion, thereby allowing too much queued > I/O work to build up. ÂWhat happens if you set the checkpoint interval > to 5 or 10 minutes? I'll test. Keep in mind that it takes me a couple of

Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?

2005-04-24 Thread Josh Berkus
Folks, > I wonder if this paper has anything that might help: > http://www.stat.washington.edu/www/research/reports/1999/tr355.ps - if I > were more of a statistician I might be able to answer :-) Actually, that paper looks *really* promising. Does anyone here have enough math to solve for D(s

Re: [HACKERS] W[i/e]rd performance issue with 8.1cvs

2005-04-24 Thread Tom Lane
Josh Berkus writes: > I'm seeing this kind of "performance plunge" on 8.1cvs in one of every 3 > runs. > It's obviously a serious stability issue, whatever is causing it. I concur with the upthread suggestion that it may come from not doing checkpoints in a realistic fashion, thereby allowing

Re: [HACKERS] W[i/e]rd performance issue with 8.1cvs

2005-04-24 Thread Josh Berkus
Guys, > >> "Weird" is spelled "weird". Not "wierd". OK, spelling errors taken into account. Now could we perhaps address the **postgresql** errors? I'm seeing this kind of "performance plunge" on 8.1cvs in one of every 3 runs. It's obviously a serious stability issue, whatever is causing

[HACKERS] Old-style OR indexscan slated for destruction

2005-04-24 Thread Tom Lane
I am about to rip out the code that supports multiple indexscans for OR conditions inside a single IndexScan plan node. As best I can tell, the new-style bitmap-OR code is as fast or faster than the old way even in fully cached test cases (ie, with no allowance for improved efficiency of disk acce

Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?

2005-04-24 Thread Josh Berkus
Andrew, > The math in the paper does not seem to look at very low levels of q (= > sample to pop ratio). Yes, I think that's the failing. Mind you, I did more testing and found out that for D/N ratios of 0.1 to 0.3, the formula only works within 5x accuracy (which I would consider acceptable)

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Joshua D. Drake
Alvaro Herrera wrote: On Sun, Apr 24, 2005 at 08:10:34AM +0200, Hans-Jürgen Schönig wrote: The idea: We are looking for a way to implement a synchronous single-master / multiple slaves systems. Meanwhile we are able to serialize / deserialize WAL records and send them to a group communication sy

Re: [HACKERS] [PERFORM] Bad n_distinct estimation; hacks suggested?

2005-04-24 Thread Andrew Dunstan
Tom Lane wrote: Josh Berkus writes: Overall, our formula is inherently conservative of n_distinct. That is, I believe that it is actually computing the *smallest* number of distinct values which would reasonably produce the given sample, rather than the *median* one. This is contrary to

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Alvaro Herrera
On Sun, Apr 24, 2005 at 08:10:34AM +0200, Hans-Jürgen Schönig wrote: > The idea: We are looking for a way to implement a synchronous > single-master / multiple slaves systems. > Meanwhile we are able to serialize / deserialize WAL records and send > them to a group communication system which tra

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Alvaro Herrera
On Sun, Apr 24, 2005 at 11:41:17AM -0400, Tom Lane wrote: > Klaus Naumann <[EMAIL PROTECTED]> writes: > >> what. Allowing that to be turned off would be interesting for a number > >> of purposes, such as burning a database onto CD. > > > FWIW, Oracle suggests a "transportable tablespace" for this

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread Tom Lane
"John Hansen" <[EMAIL PROTECTED]> writes: > Look at the upper/lower I sent to the list, they should be able to > replace upper/lower for the utf8 encoding (and works independent of > locale).. I was under the impression we couldn't use these, precisely because they weren't locale-aware. ("It

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Tom Lane
Klaus Naumann <[EMAIL PROTECTED]> writes: >> what. Allowing that to be turned off would be interesting for a number >> of purposes, such as burning a database onto CD. > FWIW, Oracle suggests a "transportable tablespace" for this feature. > Which is a tablespace that is not written too and which

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread John Hansen
Ehmm,... No the upper/lower replacements I sent to -hackers ICU was not me Tho for win32 you're better off writing wrapper classes for the win32 native functions. > -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 24, 2005 10:50 PM > To: John

Re: [HACKERS] Woo hoo ... a whole new set of compiler headaches!!

2005-04-24 Thread Neil Conway
Alvaro Herrera wrote: We have plenty of very ugly macros anyway. See fastgetattr(), HeapKeyTest(), HeapTupleSatisfies(), HeapTupleHeaderSetXmax and friends, Assert() and friends. I don't think Assert() is too bad, but I agree some of the others are a bit ugly. In some places where we would like t

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread John Hansen
Look at the upper/lower I sent to the list, they should be able to replace upper/lower for the utf8 encoding (and works independent of locale).. ... John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian > Sent: Sunday, April 24, 20

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread Bruce Momjian
John Hansen wrote: > Look at the upper/lower I sent to the list, they should be able to > replace upper/lower for the utf8 encoding (and works independent of > locale).. You mean ICU? Yes, it seems like a good approach for 8.1.

[HACKERS] I know I am behind

2005-04-24 Thread Bruce Momjian
I know I am behind in applying patches. I plan to work all through May to apply recent patches and those held over from the 8.0 beta period. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard d

Re: [HACKERS] [pgsql-hackers-win32] UNICODE/UTF-8 on win32

2005-04-24 Thread Bruce Momjian
Where are we on this? As far as I can tell, we never disabled UTF8 on Win32 in our code. The only thing we did do was to disable UTF8 in pginstaller. See this FAQ item: http://pginstaller.projects.postgresql.org/faq/FAQ_windows.html#2.6 Is the current setup OK? Should we allow UTF8 o

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread Thomas Hallgren
Oleg Bartunov wrote: On Sun, 24 Apr 2005, Thomas Hallgren wrote: Oleg Bartunov wrote: I think it's quite useful to correct, because many of us use english only when reading mailing lists and documentation :) I think that it's important to refrain from corrections on a public forum as long as th

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread Oleg Bartunov
On Sun, 24 Apr 2005, Thomas Hallgren wrote: Oleg Bartunov wrote: I think it's quite useful to correct, because many of us use english only when reading mailing lists and documentation :) I think that it's important to refrain from corrections on a public forum as long as the essence of the messag

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread John Hansen
> I appreciate getting corrected by people I know in a limited > forum. I would not expect it when I do a mistakes here. Can't > say it ever has happend although there's often good grounds > for it so I have nothing to complain about. :-) I think you meant to say 'I Can't say it ever has happen

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread Thomas Hallgren
Oleg Bartunov wrote: I think it's quite useful to correct, because many of us use english only when reading mailing lists and documentation :) I think that it's important to refrain from corrections on a public forum as long as the essence of the message is clear. Some people might get offended,

Re: [HACKERS] Constant WAL replay

2005-04-24 Thread Klaus Naumann
what. Allowing that to be turned off would be interesting for a number of purposes, such as burning a database onto CD. FWIW, Oracle suggests a "transportable tablespace" for this feature. Which is a tablespace that is not written too and which can be read by any database. Would that solve the pur

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread Oleg Bartunov
On Sun, 24 Apr 2005, Christopher Kings-Lynne wrote: Permit me a digression for a pet peeve... "Weird" is spelled "weird". Not "wierd". Yes, I know the nursery rhyme as well as you do --- i before e except after c, etc etc. But weird is spelled weirdly. Appropriate, isn't it? It's also my pet pee

Re: [HACKERS] Wierd performance issue with 8.1cvs

2005-04-24 Thread Christopher Kings-Lynne
Permit me a digression for a pet peeve... "Weird" is spelled "weird". Not "wierd". Yes, I know the nursery rhyme as well as you do --- i before e except after c, etc etc. But weird is spelled weirdly. Appropriate, isn't it? It's also my pet peeve, but I long ago stopped bothering to correct peop