Re: [HACKERS] tsearch bug in 7.2.1?
Ross and Chris,
I was reading too fast :-)
The problem is actually more complex:
We have to distinguish 4 cases when Query could returns zero result:
1. normal - there are no such words
2. query consists of stop-words only
3. query consists of lexems of non-indexed clasess (specified in parser currently)
4. combination of 2 and 3
Ideally, we want to inform middleware all these cases.
Oleg
On Thu, 15 Aug 2002, Ross J. Reedstrom wrote:
On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
tsearch has compiled-in stop-list, it's currently just not flexible
as OpenFTS does. We plan to move most functionality to tsearch but
currently have no time. Feel free to join us to speedup tsearch
development.
Oleg -
I think Chris's issue might be the same one I ran into just last night.
(BTW, thanks for tsearch and the OpenFTS work, it's really great)
My problem is that queries with only stopwords throw an ERROR, rather
than a WARNING or NOTICE. This means We've got to deal with catching an
exception so our middleware doesn't spew ugly errors and tracebacks at
our endusers, and I've got to deal with cleaning up the transaction.
Having the behavior be issue a notice and return no match would give
us a reasonably functional interface: if I don't implement reading the
NOTICE, I get confused users ('huh? the doesn't match anything?')
rather than irate users ('Your search interface sucks! It keeps
crashing!')
Oh, well, off to implement some try: catch: logic.
Ross
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of broadcast)---
TIP 3: 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: [HACKERS] Inheritance
It's nonlocal constraints that are the problem, and here foreign keys and UNIQUE constraints are certainly the canonical examples. Both of these would be largely solved with table-spanning indexes I think. Note that the other obvious way to solve this would be to store all of the information inherited from the parent in the parent table, so that you don't have to do anything special to make all of the constraints and whatnot apply. Seems with above you are not able to constrain what qualifies for a supertable row, you would only be able to specify constraints that apply to all it's subtables. To me, the current implementation looks superior and more efficient. The SQL inheritance is a class/subclass thing. All tables have instances (==rows) that are not (by itself) related. (Even if they happen to share all attribute values with another row of a supertable.) If you want that, then you need to resort to 3NF (or ROWREF's which iirc is another SQL99 feature). Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Companies involved in development
Bruce Momjian wrote: I am willing to talk to anyone about this. There is a reason my phone number is in my signature (note new phone number; I just moved.) Also, I am willing to make trips to companies to talk about PostgreSQL. I can't make 100's of trips a year, but I try to do at least on a month. I just did one last week. If your company is interested in funding or a visit to talk about PostgreSQL, I am ready. Also, for the advocacy site, I will be putting together a list of people around the world who are ready to talk via phone or visit about PostgreSQL. I am a little bogged down on the pre-beta issue, but plan to hit this full force once beta begins. I have the feeling that PostgreSQL needs a bit more of a PR effort. I started thinking about this some time ago and then I asked Bruce why Great Bridge failed. Then he started this thread. But I think the issue is bigger. When we started using PostgreSQL we tried to find success stories and study cases. There were almost none. If you go to the MySQL web site - the study cases are there. I find it crucial for new users - especially corporations - to read study cases before taking a decision. Decisions in big corporations are taken my managers and managers need more than just technical assurance that this works. Managers study MBA and MBA is one year reading day and night about what other companies did right or wrong. Developers tend not to like managers, but that's the wrong way. Both can not do without the other. Instead of trying to work without 'them' it is better to see how to work with them. If PostgreSQL has a management oriented section - the developers who want to implement PostgreSQL will have better food to feed their managers. This will improve the climate a lot. I see this effort by starting collecting and writing high quality study cases - who uses it, why do they use it, how did they started using it, what were the pros and cons, how did it go, etc. There are not much technical details in that. But a lot a manager needs in order to take a decision. Iavor -- Iavor Raytchev very small technologies (a company of CEE Solutions) in case of emergency - call: + 43 676 639 46 49 or write to: [EMAIL PROTECTED] www.verysmall.org ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Companies involved in development
I think the areas are at least two - - funding - who funds it and areas that need funding - PR - what I described in my previous mail These are pretty separated. Iavor ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
On Thu, 15 Aug 2002, Bruce Momjian wrote: I have seen some negative reactions to the feature. I am willing to ask for a vote, if that is what people want. If not, I will apply the patch in the next day or two. So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The more we discuss it the worse it looks. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] tsearch bug in 7.2.1?
No you can use:
regression=# select 'the'::mquery_txt;
ERROR: Your query contained only stopword(s), ignored
regression=# select 'good'::mquery_txt;
mquery_txt
'good'
(1 row)
I suggest:
1.
regression=# select 'the'::mquery_txt;
NOTICE: Your query contained only stopword(s), ignored
mquery_txt
-
(1 row)
2. any operation with void query returns false:
select t from tbl where t ## 'the';
NOTICE: Your query contained only stopword(s), ignored
tbl
-
(0 row)
Christopher Kings-Lynne wrote:
Ross - maybe we could work on a little function for tsearch - parse_query()
or something like that. It could return true or false depending on whether
it would cause tsearch to error or not...
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ross J.
Reedstrom
Sent: Friday, 16 August 2002 4:59 AM
To: Oleg Bartunov
Cc: Christopher Kings-Lynne; Hackers
Subject: Re: [HACKERS] tsearch bug in 7.2.1?
On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
tsearch has compiled-in stop-list, it's currently just not flexible
as OpenFTS does. We plan to move most functionality to tsearch but
currently have no time. Feel free to join us to speedup tsearch
development.
Oleg -
I think Chris's issue might be the same one I ran into just last night.
(BTW, thanks for tsearch and the OpenFTS work, it's really great)
My problem is that queries with only stopwords throw an ERROR, rather
than a WARNING or NOTICE. This means We've got to deal with catching an
exception so our middleware doesn't spew ugly errors and tracebacks at
our endusers, and I've got to deal with cleaning up the transaction.
Having the behavior be issue a notice and return no match would give
us a reasonably functional interface: if I don't implement reading the
NOTICE, I get confused users ('huh? the doesn't match anything?')
rather than irate users ('Your search interface sucks! It keeps
crashing!')
Oh, well, off to implement some try: catch: logic.
Ross
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 3: 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
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] pg_restore and user defined types, several other pg_restore problems
Hi, I'm using the ltree module and located several problems, I think not all problems are really ltree related but might be a pg_dump/pg_restore problem. Here are the problems I've encountered: * pg_restore tries to create a table with ltree and ltree[] datatypes before the type itself is created, so it fails. * several functions are already defined in template1, so create database will restore these functions. pg_restore will try to restore those functions as well and fails. Maybe create or replace function can be used here? I'm willing to do this if it's ok. * I've gist indices on ltree[] columns, and when pg_restore tries to restore it it will report: pg_restore: [archiver (db)] could not execute query: ERROR: data type ltree[] has no default operator class for access method gist You must specify an operator class for the index or define a default operator class for the data type It seems those extra functions for index support are not restored. Removing the commit/end from ltree.sql and running it again (will report a lot of errors, but a few inserts as well) will make this work again. However it requires a lot of DBA assistance to restore. All other problems are solvable by using pg_restore -L and using a modified archiv index, but IMO this should work out of the box. Best regards, Mario Weilguni ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_restore and user defined types, several other
This is known problem with pg_dump. Don't remember if it's solved in 7.3 Regards, Oleg On Fri, 16 Aug 2002, Mario Weilguni wrote: Hi, I'm using the ltree module and located several problems, I think not all problems are really ltree related but might be a pg_dump/pg_restore problem. Here are the problems I've encountered: * pg_restore tries to create a table with ltree and ltree[] datatypes before the type itself is created, so it fails. * several functions are already defined in template1, so create database will restore these functions. pg_restore will try to restore those functions as well and fails. Maybe create or replace function can be used here? I'm willing to do this if it's ok. * I've gist indices on ltree[] columns, and when pg_restore tries to restore it it will report: pg_restore: [archiver (db)] could not execute query: ERROR: data type ltree[] has no default operator class for access method gist You must specify an operator class for the index or define a default operator class for the data type It seems those extra functions for index support are not restored. Removing the commit/end from ltree.sql and running it again (will report a lot of errors, but a few inserts as well) will make this work again. However it requires a lot of DBA assistance to restore. All other problems are solvable by using pg_restore -L and using a modified archiv index, but IMO this should work out of the box. Best regards, Mario Weilguni ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] tsearch bug in 7.2.1?
On Fri, 16 Aug 2002, Christopher Kings-Lynne wrote:
Ross - maybe we could work on a little function for tsearch - parse_query()
or something like that. It could return true or false depending on whether
it would cause tsearch to error or not...
In principle, the right way is to use the same parser and the same dictionaries
for query parse, which were used in indexing ! That's the way OpenFTS does
its work, so OpenFTS knows if resulted query would be void and return
warning message *before* sending query to db. That's why we were didn't
concerned about error message returned by tsearch. But current implementation of
tsearch doesn't have api to their parser and dictionaries, so you couldn't
write parse_query(). I'd suggest to write check_query() which could use
Teodor's suggesting (see his message) - very cheap select like
select 'good query'::mquery_txt;
This will works after applying patch, we'll submit if you agree with
Teodor's suggestion.
The right way will be possible in new incarnation of tsearch with all
functionality of OpenFTS.
Regards,
Oleg
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ross J.
Reedstrom
Sent: Friday, 16 August 2002 4:59 AM
To: Oleg Bartunov
Cc: Christopher Kings-Lynne; Hackers
Subject: Re: [HACKERS] tsearch bug in 7.2.1?
On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
tsearch has compiled-in stop-list, it's currently just not flexible
as OpenFTS does. We plan to move most functionality to tsearch but
currently have no time. Feel free to join us to speedup tsearch
development.
Oleg -
I think Chris's issue might be the same one I ran into just last night.
(BTW, thanks for tsearch and the OpenFTS work, it's really great)
My problem is that queries with only stopwords throw an ERROR, rather
than a WARNING or NOTICE. This means We've got to deal with catching an
exception so our middleware doesn't spew ugly errors and tracebacks at
our endusers, and I've got to deal with cleaning up the transaction.
Having the behavior be issue a notice and return no match would give
us a reasonably functional interface: if I don't implement reading the
NOTICE, I get confused users ('huh? the doesn't match anything?')
rather than irate users ('Your search interface sucks! It keeps
crashing!')
Oh, well, off to implement some try: catch: logic.
Ross
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Admin nice-to-have's
Neil Conway [EMAIL PROTECTED] writes: I don't see a major problem with allowing postgres to login if the connection limit is hit (although I'm not sure it's worth the worry, when 'kill a backend executing SELECT ; psql template1 postgres' works as-is). max_connections is a hard limit; you do not have the option of letting people in anyway, because there'll be no PROC slot for them. We could consider establishing a soft connection limit that's somewhat less than max_connections, and allowing non-superusers to log in only if the soft limit hasn't been exceeded. This does not guarantee that superusers can always get in: the extra slots might have been filled by other superuser connections. But it'd give them better odds than the rabble. I tend to concur with Neil that the usefulness of such a feature is dubious. But OTOH such a practice has always existed for Unix disk space --- maybe we should respect that precedent. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
Vince Vielhaber [EMAIL PROTECTED] writes: So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The trouble with putting it in contrib is that that makes it effectively unavailable to anyone who installs from RPMs, or otherwise doesn't build from source for themselves. Putting a patch diff in contrib is a bad idea anyway since the patch will suffer bit-rot in no time, as the referenced files change. Since the patch is small and doesn't change behavior or performance if you don't enable the feature, I don't think there's a good reason to push it off to contrib just because it's ugly. The more we discuss it the worse it looks. I still like the other way better --- but I'm still not prepared to do the legwork to make it happen, so I have to defer to whatever Bruce is willing to implement. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_restore and user defined types, several other pg_restore problems
Mario Weilguni [EMAIL PROTECTED] writes: Here are the problems I've encountered: * pg_restore tries to create a table with ltree and ltree[] datatypes before the type itself is created, so it fails. Odd; what are the OIDs of the table and the datatypes? * several functions are already defined in template1, so create database will restore these functions. pg_restore will try to restore those functions as well and fails. Maybe create or replace function can be used here? No. Use pg_restore per the documentation: make an empty database for it to restore into (by cloning template0 instead of template1). pg_restore: [archiver (db)] could not execute query: ERROR: data type ltree[] has no default operator class for access method gist You must specify an operator class for the index or define a default operator class for the data type Are you using recent sources? As of two weeks or so ago, pg_dump should know how to dump operator classes. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Coding help
Matthew T. O'Connor wrote: Hello, I'm playing with creating an auto vacuum daemon, but it is my first time inside the pg source code and I'm a bit lost. I have gotten as far as having a vacuum daemon created on postmaster startup. It's just a fork from the postmaster, cribbed mostly from the stat collector code. I recall that there has been discussion and so far the conclusion that an automatic vacuum daemon is not the solution everyone needs. If you really want to spend the effort on doing this, can we please see some proposal about possible configuration options, how the daemon decides what to vacuum when and the like? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items, with names
Bruce Momjian [EMAIL PROTECTED] writes: Reindex/btree shrinkage - does reindex need work, can btree be shrunk? I think there is zero probability that anything will be finished on this in the next two weeks, considering that (a) no one is working on it, and (b) it's not a small task. Push it back to TODO. Schema handling - ready? interfaces? client apps? You can put my name on this for backend, psql, and pg_dump issues. I am not sure what needs to be done in the other client-side code. improve macros in new tuple header code (Manfred) Since I was the one griping, not Manfred, it's probably my job to fix this. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Standard replication interface?
On Thu, 2002-08-15 at 15:36, Tom Lane wrote: Well, I am, but I'm only speaking for myself here: Fair enough. I think there is room for several replication solutions for Postgres (three or four, maybe). If the ideal solution count is merely one with a maybe on two then I tend to concur that any specification along these lines would *mostly* be a waste. On the other hand, if we can count three or more possible replication solutions, IMHO, there seemingly would be merit is providing some sort of defacto monitoring interface. Seems the current difficulty is forecasting the future in this regard. Perhaps other core developers would care to chime in and share their vision? CVS tree. So assuming that the Postgres-R project gets to the point of usefulness, I'd vote in favor of integrating it. On the other hand, I guess I should ask. Do the developers foresee immediate usability from this project or are we looking at something that's a year+ away? I don't think I have a problem helping guide what could be an interim solution if the interim window were large enough. In theory, monitoring tools developed between now and the closing of the window could largely continue to function without change. That, of course, assumes that even the end-run solutions would implement the interface as well. The return on such a concept is that it allows generic monitoring tools to mature while providing value now and in the future. The end result should be a stronger, more powerful tool base which matures while other technologies are still being developed. Another question along this line is, once something rolls into a core position, does that obsolete all other existing implementations or merely become the defacto in a bag of solutions? Tom seems to hint at the later. If the answer is the former then that seemingly argues not to worry about this...unless the window for usefulness and/or inclusion is rather large. As for the point at hand: I'm fairly dubious that a common monitoring API will be very useful, considering how different the possible Well, all replication scenarios have a lot in common. They should, after all, they are all doing the same thing. Since the different strategies for accomplishing replication are well understood, it seems well within reason to assume that someone can put their brain around this. I can also imagine that the specification includes requirements as well as optional facilities. Certainly capability queries would further iron out any gaps between differing solutions/implementations. replication approaches are. If Greg can prove me wrong, fine. But I don't want to see us artificially constraining replication solutions by insisting that they meet some prespecified API. Hmmm. I'm not sure how it would act as a constraining force. To me, this implies that any such specification would fail to evolve and could not be revised based on feedback. IMO, most specifications are regarded as living documents. While I can see that some specifications are set in stone, I certainly am not so bold as to assert my crystal ball even came with batteries. ;) That is, I assume some level of revision to an initial specification would be required following real-world use. Regards, Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Open 7.3 items
On Fri, 16 Aug 2002, Tom Lane wrote: Vince Vielhaber [EMAIL PROTECTED] writes: So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The trouble with putting it in contrib is that that makes it effectively unavailable to anyone who installs from RPMs, or otherwise doesn't build from source for themselves. Putting a patch diff in contrib is a bad idea anyway since the patch will suffer bit-rot in no time, as the referenced files change. RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Standard replication interface?
Greg Copeland [EMAIL PROTECTED] writes: I guess I should ask. Do the developers foresee immediate usability from [Postgres-R] or are we looking at something that's a year+ away? Darren Johnson would be the man to answer that, but from what he said at OSCON it sounded like we'd be seeing something useful by the end of the year, with all the usual caveats about time actually being available to work on it. As for the point at hand: I'm fairly dubious that a common monitoring API will be very useful, considering how different the possible Well, all replication scenarios have a lot in common. They should,=20 after all, they are all doing the same thing. The end goal is approximately the same, but the mechanisms are totally different, and that means that what you want to monitor is totally different. Perhaps the problem is that you're using the wrong word, and that what you would like to standardize is not monitoring but administrative functions. For example, I'd classify selecting tables to be replicated as an admin task. Monitoring to me means something like how much data is in the queue to be pushed out to slave X?, which is a question that already presupposes a heck of a lot about the implementation. I could agree with a set of guidelines that say stuff like if your mechanism is capable of selecting individual tables to replicate, then here's the preferred way to control that feature. But I'm not sure that there's enough common functionality for monitoring (in the above sense) to be worth standardizing. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? If so I fail to see the usefulness of this and indeed it would be very harmful to existing installations! All use of PostgreSQL utilities in scripts for our product always do a '-U sprint' to use a global user, this aids our internal development and makes installation notes for clients easier... Also what effect would adding significance to '@' in the context of usernames have, if any, on the current use of it as a database/host separator (in ECPG, certainly would be useful in the utilities too)? Thanks, Lee. ---(end of broadcast)--- TIP 3: 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: [HACKERS] Open 7.3 items
Lee Kindness [EMAIL PROTECTED] writes: Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? I think Vince is talking through his hat. The proposed flag wouldn't ever be enabled by default. If someone did turn it on in their installation on a whim, they'd soon turn it off again if they didn't like the effects. I do not see much difference between the above argument and arguing we shouldn't have i18n support, because if I turned it on on a whim I wouldn't be able to read my error messages. Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Also what effect would adding significance to '@' in the context of usernames have, if any, on the current use of it as a database/host separator (in ECPG, certainly would be useful in the utilities too)? Well, I don't see any difficulty there, but if you are aware of a context where it'd be a problem, point it out! regards, tom lane ---(end of broadcast)--- TIP 3: 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: [HACKERS] Open 7.3 items
On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? I'm not sure who's 'whim' it is that your afraid of: perhaps you have a paticularly sadistic DBA to deal with? ;-) And of course, this being free software and all, noone is forcing an upgrade on you. Ross ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote: On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? I'm not sure who's 'whim' it is that your afraid of: perhaps you have a paticularly sadistic DBA to deal with? ;-) And of course, this being free software and all, noone is forcing an upgrade on you. AND, I thought the general consensus was **AWAY** from configure time directives and to GUC variables whenever **POSSIBLE**. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Admin nice-to-have's
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: I don't see a major problem with allowing postgres to login if the connection limit is hit (although I'm not sure it's worth the worry, when 'kill a backend executing SELECT ; psql template1 postgres' works as-is). max_connections is a hard limit; you do not have the option of letting people in anyway, because there'll be no PROC slot for them. We could consider establishing a soft connection limit that's somewhat less than max_connections, and allowing non-superusers to log in only if the soft limit hasn't been exceeded. This does not guarantee that superusers can always get in: the extra slots might have been filled by other superuser connections. But it'd give them better odds than the rabble. I tend to concur with Neil that the usefulness of such a feature is dubious. But OTOH such a practice has always existed for Unix disk space --- maybe we should respect that precedent. Yea, added to TODO: * Reserve last process slot for super-user if max_connections reached -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items, with names
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Reindex/btree shrinkage - does reindex need work, can btree be shrunk? I think there is zero probability that anything will be finished on this in the next two weeks, considering that (a) no one is working on it, and (b) it's not a small task. Push it back to TODO. Done. Also, we do now have contrib/reindexdb, so it is there for people to use until we get it fixed. That is a step forward, and it is a documented problem in 7.3 too. Schema handling - ready? interfaces? client apps? You can put my name on this for backend, psql, and pg_dump issues. I am not sure what needs to be done in the other client-side code. I am worried about the other stuff. I just added DROP COLUMN to the open items list to make sure that is dealt with too. improve macros in new tuple header code (Manfred) Since I was the one griping, not Manfred, it's probably my job to fix this. OK, but I thought Manfred was going to address this when he got back from vacation, but he is back now. I assume you are saying that he isn't quite sure what you want and that you will have to do it. OK. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] where to put NO_MKTIME_BEFORE_1970?
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I'm running Red Hat 7.3 at home. For the fun of it, I put: #define NO_MKTIME_BEFORE_1970 But I'm still getting the 1970 regression test failures. What else do I need to do? I'd assume you need to select different regression comparison file(s) in src/test/regress/resultmap - probably horology-no-DST-before-1970. slaps headI guess that makes perfect sense! Is /src/include/port/linux.h the correct place to put this or should something more specific to Red Hat 7.3 be used (and if so, any ideas about how to detect that Red Hat 7.3 is being used)? Thanks, Joe ---(end of broadcast)--- TIP 3: 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: [HACKERS] Open 7.3 issues
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: What does -f do? There is concern that using pg_resetxlog by accident could cause problems, so it will prompt the user for confirmation by default. -f (force) disables that confirmation. pg_resetxlog already has an -f switch, and I do not think you should change its semantics. At least not without putting up a better argument than the above. Anyone who's running pg_resetxlog had already better know what they're doing. I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. We have it /contrib partly to make sure it isn't installed in the default path for all admins. What do people want? We can rethink this. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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: [HACKERS] Coding help
Absolutely, I have been looking into this and I have some thoughts, but right now all I was trying to do was some rough implementations just to help me make sure I understand all / most of the issues. I am very new to hacking on the guts of the backend. I plan on posting a formal proposal when I feel more confident as to what I'm talking about. On Friday 16 August 2002 10:10 am, Jan Wieck wrote: Matthew T. O'Connor wrote: Hello, I'm playing with creating an auto vacuum daemon, but it is my first time inside the pg source code and I'm a bit lost. I have gotten as far as having a vacuum daemon created on postmaster startup. It's just a fork from the postmaster, cribbed mostly from the stat collector code. I recall that there has been discussion and so far the conclusion that an automatic vacuum daemon is not the solution everyone needs. If you really want to spend the effort on doing this, can we please see some proposal about possible configuration options, how the daemon decides what to vacuum when and the like? Jan ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open 7.3 items
Vince Vielhaber wrote: On Thu, 15 Aug 2002, Bruce Momjian wrote: I have seen some negative reactions to the feature. I am willing to ask for a vote, if that is what people want. If not, I will apply the patch in the next day or two. So are you calling for a vote or just willing to ask for one? I vote for putting it in contrib and letting whoever wants it apply it and use it. The more we discuss it the worse it looks. I can do a vote. However, seeing many positive comments about the patch, and 1-2 negative ones (with no suggestion on how to improve it), I don't think the negative votes will win. I usually do a vote when the email comments are coming in kind of close. Specifically, in the thread, I have Vince and Peter as negative, and 7 positive, I think. Look at the contraints I am under to implement what is effectively username schemas: small patch, no bloat, because it isn't a core feature multiple global users no namespace collisions between global/non-global users zero performance impact 32-byte user string coming from the client Specifically, what is ugly about it? Is it that global users have an @ at the end of their names? How do we prevent namespace collisions _without_ doing this? I am all ears. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Curt Sampson wrote: On Thu, 15 Aug 2002, Bruce Momjian wrote: I would like to know how to move this item forward. Right now (i.e., in 7.2), the only two options we have for moving the log file to a different spindle are mounting it on pg_xlog and using a symlink. I doubt many people do the the former, and if they do they do not need an option to init_db to move the logfile away from its default location. So I propose we just continue to use the symlink method for the moment, until we agree on another way to store the log file location within the data directory, and at that time we implement the code to do that. Note that if we don't move forward at all, we're still left in the symlink situation, with the exception that you init_db, move the log directory and create the symlink by hand, and then start up the database. So this partial move forward makes no difference to the symlink argument. Part of the reason we can't just continue to use the symlink method is that the PGXLOG environment variable situation is currently in CVS beyond initdb and in postmaster, postgres, and pg_ctl, so we do have to do something before 7.3 or we will have new environment variable handling in all those commands, and I don't think we have agreement on that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items: heap tuple header
On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: P O S T G R E S Q L 7 . 3 O P E NI T E M S improve macros in new tuple header code (Manfred) ISTM there's no consensus about what improve means. I tried to start discussing this after my vacation, but apparently people had better things to do. On Wed, 07 Aug 2002 16:16:14 +0200, I wrote (Heap tuple header issues): :. Transaction and command ids, performance : :I offered to provide cheaper versions of GetCmin and GetCmax to be :used by the tqual routines. These version would reduce additional CPU :work from two infomask compares to one. Is this still considered an :issue? However, I don't think this would lead to any measurable difference. :. Transaction and command ids, robustness : :I'm still of the opinion that putting *more* knowledge into the SetXxx :macros is the way to go. The runaway INSERT bug could as well have :been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is :set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I :would change SetXmax to set HEAP_XMAX_INVALID, if xid == :InvalidTransactionId, or reset it, if != (not sure about this). Same :for SetXminInvalid and SetXmin. This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? :Further, I'll try to build a regression test using statement timeout :to detect runaway INSERT/UPDATE (the so called halloween problem). This won't hurt anyway. I'll start working on this. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. This makes me wonder whether there is something wrong with the regression tests ... :. Oids : :I was a bit surprised that these patches went in so smoothly, must be :due to the fact that there was a lot of work to do at that time. :Personnally I feel that these changes are more dangerous than the :Xmin/Cid/Xmax patches; and I ask the hackers to review especially :part 2, which contains changes to the executor and even to bootstrap. :. Oids, t_infomask : :There has been no comment from a tool developer. :. Oids, heap_getsysattr : :We thought that a TupleDesc parameter would have to be added for this :function. However, tests showed that heap_getsysattr is not called to :get the oid, when the tuple doesn't have an oid: ERROR: Attribute :'oid' not found. :. Oids, micro tuning : :There are a few places, where storing an oid in a local variable might :be a little faster than fetching it several times from a heap tuple :header. However, I don't think this would lead to any measurable difference. :. Overall performance : :If Joe Conway can be talked into running OSDB benchmarks with old and :new heap tuple header format, I'll provide patches and instructions to :easily switch between versions. Or, Joe, can you tell me, what I need :to have and need to do to set up a benchmarking environment? With Joe's help (thanks again, Joe) I've managed to setup a benchmarking environment and I am continuously testing different configurations for a week now. There are issues with OSDB which I plan to bring up later when things cool down, but a first anawhat seems to show that with the reduced heap tuple header size we get a speed improvement of up to 3%, especially when the database is significantly larger than system memory. When the database size is only a small fraction of available memory, results vary so widely that I cannot tell whether the new heap tuple macros are a loss or a win. : :. CVS : :There have been a lot of CVS broken messages in the past few days. :When I tried : cvs -z3 log heapam.c :I got :| cvs server: failed to create lock directory for :`/projects/cvsroot/pgsql/src/backend/access/heap' :(/projects/cvsroot/pgsql/src/backend/access/heap/#cvs.lock): No such file or directory :| cvs server: failed to obtain dir lock in repository :`/projects/cvsroot/pgsql/src/backend/access/heap' :| cvs [server aborted]: read lock failed - giving up : :Is this a temporary problem or did a miss any planned changes? AFAIK I have to re-checkout everything. Servus Manfred ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Admin nice-to-have's
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: We could consider establishing a soft connection limit that's somewhat less than max_connections, and allowing non-superusers to log in only if the soft limit hasn't been exceeded. This does not guarantee that superusers can always get in: the extra slots might have been filled by other superuser connections. But it'd give them better odds than the rabble. Yea, added to TODO: * Reserve last process slot for super-user if max_connections reached I don't like phrasing it that way: if we are going to do this at all then the number of reserved slots should be a configurable parameter. If I were a DBA I'd want it to be at least two: figure one for a cron job (doing backups, periodic vacuums, etc) and one for emergency interactive superuser access. It definitely seems like something that installations would have differing views about. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items: heap tuple header
Manfred Koizar wrote: On Fri, 16 Aug 2002 01:05:07 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: P O S T G R E S Q L 7 . 3 O P E NI T E M S improve macros in new tuple header code (Manfred) ISTM there's no consensus about what improve means. I tried to start discussing this after my vacation, but apparently people had better things to do. OK. On Wed, 07 Aug 2002 16:16:14 +0200, I wrote (Heap tuple header issues): :. Transaction and command ids, performance : :I offered to provide cheaper versions of GetCmin and GetCmax to be :used by the tqual routines. These version would reduce additional CPU :work from two infomask compares to one. Is this still considered an :issue? However, I don't think this would lead to any measurable difference. Yep. :. Transaction and command ids, robustness : :I'm still of the opinion that putting *more* knowledge into the SetXxx :macros is the way to go. The runaway INSERT bug could as well have :been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is :set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I :would change SetXmax to set HEAP_XMAX_INVALID, if xid == :InvalidTransactionId, or reset it, if != (not sure about this). Same :for SetXminInvalid and SetXmin. This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? Could you or Tom explain that in a way that others could understand. My guess is that you want the sanity checks in the macros, and Tom wants more of them in the main code? :Further, I'll try to build a regression test using statement timeout :to detect runaway INSERT/UPDATE (the so called halloween problem). This won't hurt anyway. I'll start working on this. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. I totally agree with you here. You code has been great, and it did something (reduce tuple size) that no one else thought possible. This makes me wonder whether there is something wrong with the regression tests ... However, I should add that the regression tests test only a small subset of how the database has to operate. There are so many bizarre conditions that we can't test them all. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Bruce Momjian [EMAIL PROTECTED] writes: I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. There's already an interlock to prevent you from running it against a live installation (it won't run if it sees a postmaster lock file). That should also prevent an accidental run against a crashed installation (presumably a lockfile will still be there). And if you run it against a cleanly-shut-down installation, it's harmless because you don't need the old xlog. I don't think we need to be so paranoid as to insist that you say pg_resetxlog --yes-i-read-the-manual before it will do anything. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Bruce Momjian [EMAIL PROTECTED] writes: Specifically, what is ugly about it? Is it that global users have an @ at the end of their names? How do we prevent namespace collisions _without_ doing this? I am all ears. The folks who are unhappy about this design basically think that the namespace collisions issue should not be considered a vital requirement; whereupon you don't have to have the '@' because a search in the pg_shadow flat file would work well enough. It comes down to a judgment call about which is uglier, putting '@' on global usernames or having to avoid namespace collisions. At this point I think we've wasted more than enough time on the argument; I haven't seen any new ideas recently, nor any change in anyone's position. Since no one seems to want to do the work to make a better implementation, I vote we accept the patch we have and move on. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bug/Change in behavior for 7.3 vs 7.2.1
Then shouldn't this appear on the Open 7.3 issues list that has been circulating around? This seems like an open issue to me, that needs to be addressed before 7.3 ships. --Barry Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: You can no long insert large values into a bigint column without a cast. This seems to be fallout from the move to tighten up implicit coercions (cf http://archives.postgresql.org/pgsql-hackers/2002-04/msg00528.php as well as lots of earlier discussions). I said right along that this topic needed more debate, but we haven't gotten back to looking at it. We have a number of other nasty behaviors in current sources that trace back to altering the set of available coercions. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] where to put NO_MKTIME_BEFORE_1970?
Joe Conway [EMAIL PROTECTED] writes: Is /src/include/port/linux.h the correct place to put this or should something more specific to Red Hat 7.3 be used (and if so, any ideas about how to detect that Red Hat 7.3 is being used)? Really what we need is a test on the glibc version, which seems a bit difficult. I am half inclined to put in a configure test that actually checks whether mktime will work on pre-1970 dates ... but I dunno if Peter will hold still for that. In any case we don't currently have a mechanism for reflecting whatever configure would discover into the resultmap. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bug/Change in behavior for 7.3 vs 7.2.1
Barry Lind [EMAIL PROTECTED] writes: Then shouldn't this appear on the Open 7.3 issues list that has been circulating around? It does. regards, tom lane ---(end of broadcast)--- TIP 3: 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: [HACKERS] Open 7.3 issues
OK, sounds reasonable. --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I hadn't looked at flags yet. Thomas's concern, and I think a valid one, is that if we move it from contrib into the main tree, people may accidentally run pg_resetxlog without understanding the issues involved. There's already an interlock to prevent you from running it against a live installation (it won't run if it sees a postmaster lock file). That should also prevent an accidental run against a crashed installation (presumably a lockfile will still be there). And if you run it against a cleanly-shut-down installation, it's harmless because you don't need the old xlog. I don't think we need to be so paranoid as to insist that you say pg_resetxlog --yes-i-read-the-manual before it will do anything. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items
On Fri, 16 Aug 2002, Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Vince Vielhaber writes: [ 'user@' patch ] whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. Having read bits and pieces of this thread, can those in favour confirm that this would be an effect of this patch? I think Vince is talking through his hat. The proposed flag wouldn't ever be enabled by default. If someone did turn it on in their installation on a whim, they'd soon turn it off again if they didn't like the effects. I do not see much difference between the above argument and arguing we shouldn't have i18n support, because if I turned it on on a whim I wouldn't be able to read my error messages. Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Not yet they haven't. What happens when it's decided that this *feature* is a good thing and should be the default? Maybe not now, but can you guarantee that that won't happen in say 7.4? Or maybe 8.0? I can hear it now, Well we're giving you an entire version to change your scripts. There's not even a concensus that this is the right way to do it, you even said you'd prefer it was implemented in another way but don't have the time to do it. Since when does this group rush to stuff features in without agreement even on HOW to implement it? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Admin nice-to-have's
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: We could consider establishing a soft connection limit that's somewhat less than max_connections, and allowing non-superusers to log in only if the soft limit hasn't been exceeded. This does not guarantee that superusers can always get in: the extra slots might have been filled by other superuser connections. But it'd give them better odds than the rabble. Yea, added to TODO: * Reserve last process slot for super-user if max_connections reached I don't like phrasing it that way: if we are going to do this at all then the number of reserved slots should be a configurable parameter. If I were a DBA I'd want it to be at least two: figure one for a cron job (doing backups, periodic vacuums, etc) and one for emergency interactive superuser access. It definitely seems like something that installations would have differing views about. Added few: * Reserve last few process slots for super-user if max_connections reached -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bug/Change in behavior for 7.3 vs 7.2.1
It is already there, I think: fix implicit type coercions that are worse --- Barry Lind wrote: Then shouldn't this appear on the Open 7.3 issues list that has been circulating around? This seems like an open issue to me, that needs to be addressed before 7.3 ships. --Barry Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: You can no long insert large values into a bigint column without a cast. This seems to be fallout from the move to tighten up implicit coercions (cf http://archives.postgresql.org/pgsql-hackers/2002-04/msg00528.php as well as lots of earlier discussions). I said right along that this topic needed more debate, but we haven't gotten back to looking at it. We have a number of other nasty behaviors in current sources that trace back to altering the set of available coercions. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Vince Vielhaber wrote: Once again: *no one* has at any time suggested that any form of this patch should affect the default behavior in the slightest. Not yet they haven't. What happens when it's decided that this *feature* is a good thing and should be the default? Maybe not now, but can you guarantee that that won't happen in say 7.4? Or maybe 8.0? I can hear it now, Well we're giving you an entire version to change your scripts. I can't argue hypothetical with you, but if we decided to make this a default behavior, we would probably push the functionality down into CREATE USER, create a new column in pg_shadow, lengthen the username passed from the client, and do it that way. However, because it is not on by default _and_ we don't want to add visibility to a functionality that is off by default, we are doing it this way. Remember, non-local users already have an @ in their username. I am just adding @ to the global users too. This functionality actually allows you to keep your old users in pg_shadow and once you turn on the feature, those users become unusable. When you turn the feature off, they are back again. I know the trailing @ is ugly, but it prevents surpises when connecting to the database. There's not even a consensus that this is the right way to do it, you even said you'd prefer it was implemented in another way but don't have the time to do it. Since when does this group rush to stuff features in without agreement even on HOW to implement it? This is an argument I don't want to bow to. How many features have we left undone, for release after release, because we couldn't find a perfect way to do it, so we did nothing, and users went elsewhere for their database needs? We have had enough discussion to know that there isn't a perfect solution in this case, so we are going to implement the best we can, and if we have to revisit it in 8.0, so be it. I am sure you will still be around to help craft that solution. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
On Fri, 16 Aug 2002, Ross J. Reedstrom wrote: On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: RPMs aren't a good enough reason to put it in. All features aren't installed in an RPM, why would this need to? Besides, anything that is runtime configurable can end up getting its default changed on a whim. Then again as long as 7.2.1 is stable enough for me there's no reason to upgrade 'cuze I damn sure ain't going back and changing all sorts of programs and scripts that have global users. So, Vince, do you have problems with the various GUC based optimizer hooks getting set to other than the default? I'd think you'd notice if suddenly indexscans all went away, or any of these: #enable_seqscan = true #enable_indexscan = true #enable_tidscan = true #enable_sort = true #enable_nestloop = true #enable_mergejoin = true #enable_hashjoin = true My point is that your resistance to a GUC controlled runtime configurable on the basis of 'it might get changed accidently' makes little sense to me, given all the other runtime config settings that never do get changed. What makes you think this one will be more susceptible to accidental flipping? My point has nothing to do with resistance to GUC configurables. Someone WILL decide that having it as a default is a *Good Thing* because it's there and is useful to them and in its current implementation there's not even a concensus that it's the right way to do it. It's being rushed into this version unnecessarily. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
Vince Vielhaber [EMAIL PROTECTED] writes: My point has nothing to do with resistance to GUC configurables. Someone WILL decide that having it as a default is a *Good Thing* because it's there and is useful to them Which someone would this be? There's no chance that such a proposal would pass a pghackers vote, and certainly no chance that someone could commit such a change into CVS without everyone noticing. and in its current implementation there's not even a concensus that it's the right way to do it. It's being rushed into this version unnecessarily. It's being rushed into this version because we need a stopgap solution. I don't see it as anything but a stopgap. The fact that it's a very small patch is good, because it can be replaced with minimal effort once someone has the time to design and implement a better mechanism for multi-database user management. AFAICT a proper solution will involve considerable work, and I don't see it happening in time for 7.3. Also, ugly as this may be, it's still better than the old solution for people who are trying to support multiple similarly-named users in different databases. The old hack required external password files which mean manual management, admin involvement in any password change, etc. With this approach users can set their password normally even if they're being restricted to one database. So realistically I think this does not affect people who aren't using it, and for people who do want to use it it's a step forward, even if not as far forward as we'd like. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open 7.3 issues
Bruce Momjian wrote: Jan Wieck wrote: Bruce Momjian wrote: Allow PL/PgSQL functions to return sets Is anyone working on this? We will get beaten up if we don't have this for 7.3 and it is available in other languages. That's true. I think I have to do this one. I'm busy for the next 2-3 weeks (Mom will be back from her Westcoast trip tonight and stay for another 3 weeks). But I should be able to do something after that. Nope. We are in beta then. Either someone else will have to do it or it will wait for 7.4. Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 issues
Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open 7.3 items
Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Sure. If I can get one more 'yes' I will submit a new patch with the change. It does prevent the namespace collision without mucking up pg_shadow. We only need to tell people that global users need to supply their username to the client as user@. Is that cleaner? Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. Ewe, I didn't think of that. Good point. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
On Fri, 2002-08-16 at 20:03, Bruce Momjian wrote: Sure. If I can get one more 'yes' I will submit a new patch with the change. It does prevent the namespace collision without mucking up pg_shadow. We only need to tell people that global users need to supply their username to the client as user@. Is that cleaner? I will vote yes for this change. I think the flexibility this new system offers will make it much easier for people to offer PostgreSQL hosting facilities, of which I would like to see many more. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C And whatsoever ye shall ask in my name, that will I do, that the Father may be glorified in the Son. John 14:13 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 issues
Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. Neil said he was working on this and expected to have it done for 7.3. I think he's using the approach we discussed at OSCON, namely generating a tuplestore within the plpgsql module and passing it back to FunctionNext. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 issues
Joe Conway wrote: Tom Lane wrote: Jan Wieck [EMAIL PROTECTED] writes: Since PL/pgSQL is a loadable module still, we might be able to provide an upgrade after 7.3 is out instead of waiting for 7.4. Maybe, but you'd have to get the core-code end of it in before beta. AFAIR Joe's patch doesn't yet cover any return style from a function except one-row-at-a-time. Neil said he was working on this and expected to have it done for 7.3. I think he's using the approach we discussed at OSCON, namely generating a tuplestore within the plpgsql module and passing it back to FunctionNext. If I understand correctly, it is a great idea because it uses the cursor return support already in pl/pgsql to handle it. Great idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] CVS Messages
Is it possible for the cvs emails to include a URL to the appropriate entries in cvs web? The below is current: Modified files: src/backend/utils/adt: ruleutils.c Is this possible? Modified files: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c Or perhaps have a LINKS section at the very bottom below the current messages? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS Messages
Rod Taylor wrote: Modified files: src/backend/utils/adt: ruleutils.c Is this possible? Modified files: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c I'd second that request! Great idea. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] XLogDir
A recent change made XLogDir dynamically sized. There was a question of whether this was a good idea since there are lots of other places that use MAXPGPATH. I have now found that pg_resetxlog doesn't compile anymore because XLogDir is a char* now instead of a char[]. Should I fix pg_resetxlog or revert the XLogDir change in the backend. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Open 7.3 items: heap tuple header
On Fri, 16 Aug 2002 12:25:37 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: Manfred Koizar wrote: This is the main point of disagreement: Tom Lane wants lighter macros, I want heavier macros. Which direction shall we go? Could you or Tom explain that in a way that others could understand. I'm not sure we understand each other :-) My guess is that you want the sanity checks in the macros, and Tom wants more of them in the main code? I guess we agree on having the sanity checks in the macros. It's more on what the macros are allowed to change and what decisions they are allowed to take. Do the following quotes make it clearer? :On Sat, 20 Jul 2002 16:27:14 -0400, Tom Lane [EMAIL PROTECTED] :wrote: :I'd recommend redesigning the HeapTupleHeaderSet macros so that they :do not do any setting of t_infomask bits, or even take any conditional :action based on them, to which I replied on Sun, 21 Jul 2002 23:00:22 +0200: :The HEAP_XMIN_IS_XMAX bit is exclusively managed by these macros. :Pulling the handling of this bit out of the macros and spreading it to :the places, where the macros are used, cannot make the whole thing :more robust. This would mean, the caller had to decide whether to :store Cmax into t_cid or t_xmax... Tom: : but solely Assert() that the bits are already :in the appropriate state to allow storing of the value to be stored. :Then, all uses have to be checked to ensure that t_infomask is coerced :into the right state *before* doing HeapTupleHeaderSetFoo. me: :Apart from HEAP_XMIN_IS_XMAX this was my intention; we already do :this with HEAP_MOVED. I could add an assertion to SetCmax: : Assert(!((tup)-t_infomask HEAP_XMAX_INVALID)); : :OTOH I thought about putting *more* logic into the macros to make :their use less fragile. For example SetXmaxInvalid could set the :HEAP_XMAX_INVALID bit, likewise SetCminInvalid with XMIN_INVALID. BTW, my changes have been criticized with words like vague unease, zero confidence, very obviously not robust, do not trust the current code at all etc., while from day one all my patches have passed all regression tests. I totally agree with you here. You code has been great, and it did something (reduce tuple size) that no one else thought possible. Thanks a lot! But I was not fishing for compliments, I was just preparing for the next sentence: There is something wrong with the regression tests. In fact vague unease more than once was a proper description for my own feelings when I posted a patch, because I didn't know whether I could trust the tests. If core developers share this unease, I find myself in good company. This makes me wonder whether there is something wrong with the regression tests ... However, I should add that the regression tests test only a small subset of how the database has to operate. So, please, could you add to TODO: * Add more regression tests There are so many bizarre conditions that we can't test them all. When Tom Lane recently posted a way to reproduce a bug (No one parent tuple was found, CASE 1) I thought about how to add this case to the regression tests, but we have no vehicle for testing concurrent transactions. TODO: * Build a test vehicle for concurrent transactions * Add even more regression tests Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS Messages
It is certainly possibly. We have added that type of functionality to our inhouse CVS system. Below is an example. We include at the bottom of the checkin mail a link to the webcvs diff page so you can quickly see what changed for a particular checkin. --Barry wfs checkin by barry 02/08/16 12:10:39 Modified:com/.../sql/postgres SessionManagerBaseSql.java com/.../sql/mssql SessionManagerBaseSql.java com/.../sql/oracle SessionManagerBaseSql.java Log: port fix for bug 1605 from 3.3 to 4.0 https://foo.bar.com/cgi-bin/viewcvs.cgi/wfs/com/.../sql/postgres/SessionManagerBaseSql.java.diff?r1=40.1r2=40.2diff_format=h https://foo.bar.com/cgi-bin/viewcvs.cgi/wfs/com/.../sql/mssql/SessionManagerBaseSql.java.diff?r1=40.0r2=40.1diff_format=h https://foo.bar.com/cgi-bin/viewcvs.cgi/wfs/com/.../sql/oracle/SessionManagerBaseSql.java.diff?r1=40.0r2=40.1diff_format=h Rod Taylor wrote: Is it possible for the cvs emails to include a URL to the appropriate entries in cvs web? The below is current: Modified files: src/backend/utils/adt: ruleutils.c Is this possible? Modified files: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/adt/ruleutils.c Or perhaps have a LINKS section at the very bottom below the current messages? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] (Bruce Momjian) wrote I know the trailing @ is ugly, but it prevents surpises when connecting to the database. if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont.. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Bruce Momjian) wrote I know the trailing @ is ugly, but it prevents surpises when connecting to the database. if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont.. It already does that. When it is off, it works just like it does in 7.2. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Temporary Table existence?
From earlier postings it seems like there is no way to check that a temp table exists; at the time Tom suggested schemas might solve the problem. I was wondering if: (a) schema did solve the problem or (b) there was any chance of a backend function to get a temp table OID (or 0 is none), or a view, eg. pg_temporary_tables? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Function result cacheing
This has been discussed before in the context of misunderstanding the meaning of 'iscachable', but I now have a use for cached function results, and have seen at least one other posting with a similar need. The reason I need it is that I have a few functions that do recursive inheritance lookups going up a converging inheritance tree. Typically this function will be called on several hundred objects in a single select statement. Because of inheritance, it ends up with several thousand function calls, each of which is non-trivial. A solution that would be useful for me would be: If a function is marked 'invariant' (or something similar), then - cache the most recently used 20 calls (config item) iff the args were less than 1K in total storage (ie. don't cache large text blocks), - calculate a very simple checksum on the args - when a function is to be evaluated, calc the checksum and if a match is found, compare the args, and if they all match, return the result. I would anticipate deleting the cache when the current command exits, and/or certainly when a TX ends. Obviously this is not a 7.3 item, but would people support such functionality going into a future version? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /() __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] XLogDir
Bruce Momjian [EMAIL PROTECTED] writes: A recent change made XLogDir dynamically sized. There was a question of whether this was a good idea since there are lots of other places that use MAXPGPATH. I have now found that pg_resetxlog doesn't compile anymore because XLogDir is a char* now instead of a char[]. Should I fix pg_resetxlog or revert the XLogDir change in the backend. Revert. The XLogDir change was incomplete and basically useless to start with ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Open 7.3 items
OK, here is the patch with the suggested changes. I am sending the
patch to hackers because there has been so much interest in this.
---
Tom Lane wrote:
BTW, I just thought of a small improvement to your patch that eliminates
some of the ugliness. Suppose that when we recognize an attempt to
connect as a global user (ie, feature flag is on and last character of
username is '@'), we strip off the '@' before proceeding. Then we would
have:
global users appear in pg_shadow as foo
local users appear in pg_shadow as foo@db
and what this would mean is that you can flip between feature-enabled
and feature-disabled states without breaking your global logins. So you
don't need the extra step of creating a postgres@ before turning on
the feature. (Which was pretty ugly anyway, since even though postgres@
could be made a superuser, he wouldn't be the same user as postgres ---
this affects table ownership, for example, and would be a serious issue
if you wanted any non-superuser global users.)
I suppose some might argue that having to say postgres@ to log in,
when your username is really just postgres as far as you can see in the
database, is a tad confusing. But the whole thing is an acknowledged
wart anyway, and I think getting rid of the two problems mentioned above
is worth it.
Also, if we do this then it's important to strip a trailing '@' only
if it's the *only* one in the given username. Else a local user
'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@'
with requested database db2. But I can't see any other security hole.
regards, tom lane
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/runtime.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.125
diff -c -r1.125 runtime.sgml
*** doc/src/sgml/runtime.sgml 15 Aug 2002 14:26:15 - 1.125
--- doc/src/sgml/runtime.sgml 17 Aug 2002 04:14:34 -
***
*** 1191,1196
--- 1191,1216
/varlistentry
varlistentry
+ termvarnameDB_USER_NAMESPACE/varname (typeboolean/type)/term
+ listitem
+para
+ This allows per-database user names. You can create users as literal
+ username@dbname/. When literalusername/ is passed by the client,
+ literal@/ and the database name is appended to the user name and
+ that database-specific user name is looked up by the server.
+ When creating user names containing literal@/, you will need
+ to quote the user name.
+/para
+para
+ With this option enabled, you can still create ordinary global
+ users. Simply append literal@/ when specifying the user name
+ in the client. The literal@/ will be stripped off and looked up
+ by the server.
+/para
+ /listitem
+ /varlistentry
+
+ varlistentry
indexterm
primarydeadlock/primary
secondarytimeout/secondary
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.82
diff -c -r1.82 auth.c
*** src/backend/libpq/auth.c20 Jun 2002 20:29:28 - 1.82
--- src/backend/libpq/auth.c17 Aug 2002 04:14:35 -
***
*** 117,123
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port-user, auth_data.pname, SM_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
port-user, auth_data.pname);
--- 117,123
version, PG_KRB4_VERSION);
return STATUS_ERROR;
}
! if (strncmp(port-user, auth_data.pname, SM_DATABASE_USER) != 0)
{
elog(LOG, pg_krb4_recvauth: name \%s\ != \%s\,
port-user, auth_data.pname);
***
*** 290,296
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port-user, kusername, SM_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
port-user, kusername);
--- 290,296
}
kusername = pg_an_to_ln(kusername);
! if (strncmp(port-user, kusername, SM_DATABASE_USER))
{
elog(LOG, pg_krb5_recvauth: user name \%s\ != krb5 name \%s\,
port-user, kusername);
Index: src/backend/postmaster/postmaster.c
Re: [HACKERS] Function result cacheing
Philip Warner [EMAIL PROTECTED] writes: Obviously this is not a 7.3 item, but would people support such functionality going into a future version? Actually, I wouldn't. I can think of very few situations where such caching is useful, and I don't believe that the mechanism required would pay for itself. In the cases where a cache does make sense, it's sufficiently application-specific that a generic cache on a key consisting of the function arguments isn't the right thing anyway; you'll find you want some internal logic to decide what to cache and what key to use to retrieve it. Furthermore, a generic cache will have no clue whatever about cache-invalidating events, thus further restricting its usefulness. (Your suggestion of flush at transaction end is too short-term for most applications, too long-term for some, and just right for hardly any.) Build the cache internally to your function if you need it. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Open 7.3 items
Sample run: $ psql -U postgres test psql: FATAL: user postgres@test does not exist $ psql -U postgres@ test Welcome to psql 7.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit test= --- Tom Lane wrote: BTW, I just thought of a small improvement to your patch that eliminates some of the ugliness. Suppose that when we recognize an attempt to connect as a global user (ie, feature flag is on and last character of username is '@'), we strip off the '@' before proceeding. Then we would have: global users appear in pg_shadow as foo local users appear in pg_shadow as foo@db and what this would mean is that you can flip between feature-enabled and feature-disabled states without breaking your global logins. So you don't need the extra step of creating a postgres@ before turning on the feature. (Which was pretty ugly anyway, since even though postgres@ could be made a superuser, he wouldn't be the same user as postgres --- this affects table ownership, for example, and would be a serious issue if you wanted any non-superuser global users.) I suppose some might argue that having to say postgres@ to log in, when your username is really just postgres as far as you can see in the database, is a tad confusing. But the whole thing is an acknowledged wart anyway, and I think getting rid of the two problems mentioned above is worth it. Also, if we do this then it's important to strip a trailing '@' only if it's the *only* one in the given username. Else a local user 'foo@db1' could cheat to log into db2 by saying username = 'foo@db1@' with requested database db2. But I can't see any other security hole. regards, tom lane -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] XLogDir
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: A recent change made XLogDir dynamically sized. There was a question of whether this was a good idea since there are lots of other places that use MAXPGPATH. I have now found that pg_resetxlog doesn't compile anymore because XLogDir is a char* now instead of a char[]. Should I fix pg_resetxlog or revert the XLogDir change in the backend. Revert. The XLogDir change was incomplete and basically useless to start with ... Yea, but it was tied into the PGXLOG commit. Thomas, what are we doing with that? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
