Re: [HACKERS] How do we create the releases?
Magnus Hagander wrote: On Thu, Jun 07, 2007 at 01:12:06PM +0200, Peter Eisentraut wrote: Magnus Hagander wrote: Is this script in CVS somewhere? I know it's not in the main backend repo. Most of what these scripts have done in the past has been systematized and folded into the make dist target in the mean time, and AFAICT, we could integrate the documentation preparation as well, now that it works automatically in a reliable fashion. That would reduce the answer to the original question to something like ./configure make dist[check] If we can do that, that makes it even better. But is it something we can reasonably backpatch? Otherwise we still need both documentation and scripts to deal with back branches. Marc, how's this coming? We still need this documented somewhere, if it's not being put into CVS. And documenting what it is could be a good starting point for somebody else to put it into the Makefile, if you don't have the time to work on that part yourself. But not having it documented *or* in the Makefile just sucks... //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Magnus Hagander wrote: That won't help; that would introduce the embarrassment of having a known default password. No it wouldn't unless the packagers set it up to do that. My point is that when a packager (or source) runs initdb, it would prompt for the postgres user password. Practically every existing packaging of PG tries to run initdb as a hidden, behind-the-scenes, definitely not-interactive procedure. afaik, practically every existing packaging of pg has *already* solved the problem and does not set trust as default anyway. ident sameuser I think is the most common. One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice. Since nobody comemnted on this, let me turn it around and ask: Does anybody have any reason *not* to do this? If not, I'll just make it happen... (that should at least make people speak up :P) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Magnus Hagander wrote: Magnus Hagander wrote: That won't help; that would introduce the embarrassment of having a known default password. No it wouldn't unless the packagers set it up to do that. My point is that when a packager (or source) runs initdb, it would prompt for the postgres user password. Practically every existing packaging of PG tries to run initdb as a hidden, behind-the-scenes, definitely not-interactive procedure. afaik, practically every existing packaging of pg has *already* solved the problem and does not set trust as default anyway. ident sameuser I think is the most common. One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice. Since nobody comemnted on this, let me turn it around and ask: Does anybody have any reason *not* to do this? If not, I'll just make it happen... (that should at least make people speak up :P) It will break the buildfarm. Of course I can unbreak it by adding --auth=trust to the initdb args (and if we go this route we'll need to do that for the regression temp installs too), but we'd need every buildfarm member to have upgraded before we put it in. Is that really the sort of disruption you want right now? cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. I'll object if no one else does: this will break existing installation habits and processes to no real benefit. The benefit would be that PostgreSQL would be secure by default. Which we are *not* today. No, we would NOT be secure by default. We'd only be secure by default if we forced the user to pick a secure auth method, for whatever value of secure is politically correct. A change like this will make exactly 0 difference to users of prepackaged installations, since AFAIK all packages make their own decisions about what default auth method to use (and since they are targeting specific platforms, they have more context to make this choice than we do). It will also be useless and annoying to experienced users of the source code, since they already know what to do. The only group that will be affected will be newbie installers-from-source (which I bet is a mighty small group these days). And those people will find that Postgres' first demand on them is to read and understand some rather complex documentation to try to pick a default auth method. You really think that this group is particularly likely to get it right? If it were an open-and-shut decision we'd probably just move to a non-trust default. I would also argue that trust auth is not such an evil option that we mustn't allow it to be the default. On a single-user machine it's actually perfectly sane, seeing that we don't allow TCP connections by default. I think what this change would mostly do is put still another barrier in the way of people trying out Postgres. There's already a darn steep learning curve; we don't need a cliff at the very start. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice. Since nobody comemnted on this, let me turn it around and ask: Does anybody have any reason *not* to do this? I'll object if no one else does: this will break existing installation habits and processes to no real benefit. The benefit would be that PostgreSQL would be secure by default. Which we are *not* today. As a comparison, that's been one of the most common complaints against Windows earlier - stuff is installed and enabled by default, and only if you already know the system do you know that you should disable it. The same thing applies here - if you don't already know how PostgreSQL works, you will by default install a database that's completely without authentication. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Magnus Hagander [EMAIL PROTECTED] writes: One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice. Since nobody comemnted on this, let me turn it around and ask: Does anybody have any reason *not* to do this? I'll object if no one else does: this will break existing installation habits and processes to no real benefit. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Andrew Dunstan wrote: Magnus Hagander wrote: Magnus Hagander wrote: That won't help; that would introduce the embarrassment of having a known default password. No it wouldn't unless the packagers set it up to do that. My point is that when a packager (or source) runs initdb, it would prompt for the postgres user password. Practically every existing packaging of PG tries to run initdb as a hidden, behind-the-scenes, definitely not-interactive procedure. afaik, practically every existing packaging of pg has *already* solved the problem and does not set trust as default anyway. ident sameuser I think is the most common. One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. Packagers can then just use that to set ident or whatever. and interactive users can pick trust if they really need it, but it will be a known choice. Since nobody comemnted on this, let me turn it around and ask: Does anybody have any reason *not* to do this? If not, I'll just make it happen... (that should at least make people speak up :P) It will break the buildfarm. Of course I can unbreak it by adding --auth=trust to the initdb args (and if we go this route we'll need to do that for the regression temp installs too), but we'd need every buildfarm member to have upgraded before we put it in. Is that really the sort of disruption you want right now? Ouch. No. Didn't think of that. If we want to do that, we should probably do it right at the start of the 8.4 cycle then? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] tsearch in core patch
Alvaro Herrera wrote:
What I was really suggesting was having a table mapping locale names
into tsearch languages. Then the configuration could be made based on
the language, not on the locale name. So the stopword list is for
russian, regardless of whether the locale is Russian_Russia or ru_RU.
Agreed. But I'm afraid we couldn't map all of the locale names in a
right way. Man, it's a large list. ;)
Is this only for the stopword list, or does it also affect selecting a
stemmer?
Both.
Note: it's possible that the stopword list is different for brazilian
portuguese than portuguese portuguese, which is why I was suggesting
using a language portuguese_brazil and not just postuguese. Whereas
you need a single stopword list for all the countries speaking spanish,
which is why you need only one language called spanish.
Indeed it's possible for portuguese, because we have some words that are
written in different ways, e.g.,
pt_BR pt_PT english
MônicaMónicaMonica
ação acção action
Irã Irão Iran
.
.
.
Will it be possible to disable stemming or stopwords removal? I'm asking
this 'cause sometimes stemming doesn't lead to good results and/or
stopwords are relevant. Maybe it could be an GUC variables
('enable_stemming' and 'enable_stopwords').
--
Euler Taveira de Oliveira
http://www.timbira.com/
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
On Jun 23, 2007, at 11:03 AM, Magnus Hagander wrote: I would also argue that trust auth is not such an evil option that we mustn't allow it to be the default. On a single-user machine it's actually perfectly sane, seeing that we don't allow TCP connections by default. Is there really such a thing as a single-user machine running PostgreSQL? Maybe single human user, but if you're not running some other services on it (webserver, mailserver, whatever) it's not very likely to be running pg, I think. My laptop and dev boxes are all single user (and all do trust on unix sockets). I have several webserver boxes that use local postgresql installations. Again, trust works just fine for that. There's no security issue unless someone has compromised the box (probably via the webapp), and if they've done that they already have the keys to the castle. Mailserver, ditto. We deploy CRM systems, running on dedicated boxes, to customers. While they tend to get configured with md5 access, just because it's tidy and easy to explain to IT security folks, they'd actually be just as secure with trust auth. Out of curiosity, how do other databases deal with this? The only one I've been installing recently is MSSQL which basically lets you chose between SSPI (ident-sameuser-over-sockets-and-kerberos-over-network-equivalent) or password (md5 equivalent, AFAIK). It does *not* let you use empty passwords, which is what would be equivalent with our trust. But that's not an installation from source. That's a packaged installation, provided by the distribution owner. It's much more comparable to, say, a Debian package. MySQL installs with an empty root password for access from localhost or the machines own IP address. It also installs an account with network access to any database beginning with test and possibly some more ill-defined accounts with local access. Part of the suggested post-install process for mysql involves deleting some of those accounts and setting password for root. Cheers, Steve ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] tsearch in core patch
On Sat, 23 Jun 2007, Euler Taveira de Oliveira wrote:
Will it be possible to disable stemming or stopwords removal? I'm asking
this 'cause sometimes stemming doesn't lead to good results and/or
stopwords are relevant. Maybe it could be an GUC variables
('enable_stemming' and 'enable_stopwords').
Just use another configuration.
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [Fwd: Re: [HACKERS] tsearch in core patch]
Tatsuo Ishii wrote:
japanese '{ja_JP, C}'
How would we know C - japanese?
You can't do that. You can't have different languages (not locales)
mapping to the same 'tsearch language' because the stemmer doesn't know
that a specific word is in english or japanese. So you have two options:
(a) disable stemming (b) leave the language set to 'japanese' and see if
it plays well.
--
Euler Taveira de Oliveira
http://www.timbira.com/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] Bugtraq: Having Fun With PostgreSQL
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: One thing I've thought about doing is to remove the default in initdb completely and *force* the user to choose auth type. I'll object if no one else does: this will break existing installation habits and processes to no real benefit. The benefit would be that PostgreSQL would be secure by default. Which we are *not* today. No, we would NOT be secure by default. We'd only be secure by default if we forced the user to pick a secure auth method, for whatever value of secure is politically correct. Good point. But we'd at least force the user to read up on things. (Or guess, but there's nothing we can do about that at all) A change like this will make exactly 0 difference to users of prepackaged installations, since AFAIK all packages make their own decisions about what default auth method to use (and since they are targeting specific platforms, they have more context to make this choice than we do). Agreed. It will also be useless and annoying to experienced users of the source code, since they already know what to do. Well, it would help them not to forget an important step, but agreed in principle. The only group that will be affected will be newbie installers-from-source (which I bet is a mighty small group these days). And those people will find that Postgres' first demand on them is to read and understand some rather complex documentation to try to pick a default auth method. You really think that this group is particularly likely to get it right? If it were an open-and-shut decision we'd probably just move to a non-trust default. In that case, md5 would seem to be the reasonable choice - unless we want something platform specific somehow set by autoconf or so (I'd say ident sameuser over unix sockets make a lot of sense on platforms that support it). I would also argue that trust auth is not such an evil option that we mustn't allow it to be the default. On a single-user machine it's actually perfectly sane, seeing that we don't allow TCP connections by default. Is there really such a thing as a single-user machine running PostgreSQL? Maybe single human user, but if you're not running some other services on it (webserver, mailserver, whatever) it's not very likely to be running pg, I think. I think what this change would mostly do is put still another barrier in the way of people trying out Postgres. There's already a darn steep learning curve; we don't need a cliff at the very start. Didn't we just say that these users are most likely running a pre-packaged version anyway? Either way, it's not critical, given that the majority of our users use some kind of pre-packaged deal, but I still think we could do better. Out of curiosity, how do other databases deal with this? The only one I've been installing recently is MSSQL which basically lets you chose between SSPI (ident-sameuser-over-sockets-and-kerberos-over-network-equivalent) or password (md5 equivalent, AFAIK). It does *not* let you use empty passwords, which is what would be equivalent with our trust. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] fast stop before database system is ready
On Fri, 2007-06-22 at 16:25 -0500, Kevin Grittner wrote: I apologize for not grabbing more information before the evidence was gone, but I think there may be a vulnerability to database corruption on PITR recovery if a stop is done with the fast option right after a database logs archive recovery complete. We normally have about 17 seconds between that and the database system is ready message for a particular database. Someone was watching the log and issued a fast stop about 1.5 seconds after the archive recovery is complete message. When the database came back up, it was corrupted. (The first problem message was about a bad sibling pointer, but the wheels pretty much fell off after that.) He deleted the database instance, got a fresh dump, and tried again without stopping the server at that point, and all is well. The message is issued too early. It should be issued after the shutdown checkpoint that occurs following recovery. However, that only matters if you issue a shutdown immediate and would not occur with fast shutdown. So I suspect your DBA has Oracle training and thinks that -m immediate is a fast shutdown. It certainly is fast, but not the same thing as -m fast. For -m fast, this should issue a normal shutdown checkpoint, which will secure the backup. If you do -m immediate, this means crash the server, please, which we interrupt the shutdown checkpoint issued at the end of recovery, leading to an incomplete archive recovery. I'll re-arrange the message until after the checkpoint occurs, so that the timing window for -m immediate is removed. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Worries about delayed-commit semantics
On Fri, 22 Jun 2007, Tom Lane wrote: What's wrong with synchronous_commit? It's accurate and simple. It's kind of a big word that not a lot of people understand the subtleties of, and I'd be concerned it will sow confusion with the terminology used for WAL synchronous writes. When I explain to people the difference between transactions that have just been committed and written to disk (but possibly still sitting in a buffer) vs. ones that are known to have made it all the way through to the platters via fsync, the word I use is that the writes have been confirmed. If I were picking a GUC name to describe the current behavior I'd want to call it confirmed_commit=on. I think people easily understand the idea that just because something wasn't confirmed, that doesn't mean it didn't happen, you just can't be sure--and therefore there's a possibility it could be lost. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
