Re: Fw: Fw: [HACKERS] bad performance on irix
> Makes me wonder... perhaps now someone will be convinced to take a look > at the POSIX IPC patch. On some platforms (not on Linux I am afraid) > POSIX mutexes might be quite a bit faster than SYSV semaphores. > Is there any current patch? Regards ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Fw: Fw: [HACKERS] bad performance on irix
I've done some meditions with timex, it uses sar(System activity register) to take workloads, it's not very relliable, but it allow us to see how it is been doing, it has been taken during an execution of a like tpc-h benchmark, it performs inserts, deletes(about 5% of the time of the execution) and a set of 8 continous streams of 22 read only queries, notice that it only gives idle time (not the cause of idle), notice semafores/sec is up to 2700!!! Regards 12:27:08 %usr %sys %intr %wio %idle %sbrk %wfs %wswp %wphy %wgsw %wfif 12:55:3932 3 0 956 0 100 0 0 0 09% waiting for I/O which is 100% file system 12:27:08 device %busy avque r+w/s blks/sw/s wblks/s avwait avserv 12:55:39 dks0d5 00.00.0 00.0 0 0.0 0.0 dks1d1 13.10.7 190.7 1627.8 15.0 dks1d2 01.00.0 00.0 0 0.0 13.3 dks1d3 00.00.0 00.0 0 0.0 0.0 dks1d423 15.39.117057.81553 519.7 24.8 12:27:08 bread/s lread/s %rcach bwrit/s lwrit/s wcncl/s %wcach pread/s pwrit/s 12:55:39 1582372 9315499072 1 83 0 093% of read cache hits and 83% of write chache hits 12:27:08 scall/s sread/s swrit/s fork/s exec/s rchar/s wchar/s 12:55:394618 181 1260.180.06 648854 580354 syscalls averages 12:27:08 msg/s sema/s 12:55:390.00 2704.28 12:27:08 vflt/s dfill/s cache/s pgswp/s pgfil/s pflt/s cpyw/s steal/s rclm/snotice that there aren't page swaps, so idle is not waiting for paging 12:55:39 862.58 58.31 804.240.000.045.703.11 60.90 0.00 12:27:08CPU %usr %sys %intr %wio %idle %sbrk %wfs %wswp %wphy %wgsw %wfif 12:55:39 025 3 0 863 0 100 0 0 0 0 per CPU usage 125 3 0 962 0 100 0 0 0 0 224 3 0 964 0 100 0 0 0 0 330 3 0 859 0 100 0 0 0 0 430 3 0 859 0 100 0 0 0 0 539 3 0 850 0 100 0 0 0 0 654 3 0 834 0 100 0 0 0 0 733 3 0 855 0 100 0 0 0 0 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Vacation
I will be on vacation from tomorrow up to April 6th. So don't expect any answer prior early April from me. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Domains and type coercion
... > The problem seems to be that when parse_func looks for "exact match" > operators, it doesn't consider numeric to be an exact match for mydom. > So that heuristic fails and we're left with no unique best choice for > the operator. Sure. At the moment there is no reason for parse_func to think that mydom is anything, right? > I'm not sure if there's anything much that can be done about this. Something has to be done ;) > We could treat exact and binary-compatible matches alike (doesn't seem > good), or put a special case into the operator selection rules to reduce > domains to their basetypes before making the "exact match" test. > Neither of these seem real appealing, but if we don't do something > I think that domains are going to be a big pain in the neck to use. There could also be an explicit heuristic *after* the exact match gathering to look for an exact match for domains reduced to their base types. Is there any reason to look for domains before that? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Domain Support -- another round
> > Not entirely sure, except the book I had (SQL99 Complete, Really) > > specifically forbids it. > > > > Yes, but this is their interpretation of the standard. There is an Understood. It's the best that I had on me. I've not found a cheap resource for the real one. Ie. priced suitably to fit a hobby project :) > error in that page anyway, as the standard explicitly forbids > arrays and UDTs and they list REF and ARRAY as valid data types. > (they also get confused with SESSION_USER and CURENT_USER on page > 281, so it does not surprise me). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Where to get official SQL spec (was Re: Domain Support)
"Rod Taylor" <[EMAIL PROTECTED]> writes: > I've not found a cheap resource for the real one. Ie. priced suitably > to fit a hobby project :) Try ANSI's electronic standards store: they'll sell you PDFs of ANSI's printing of the spec at a reasonable price. http://webstore.ansi.org/ansidocstore/default.asp Go to the "search" page and enter "9075" (the IS number for SQL). Along with the overpriced ISO offerings, there are: ANSI X3.135-1992SQL92 ANSI/ISO/IEC 9075-n-1999SQL99, parts 1-5 Each of these is $18 US. You don't really need all five parts of SQL99; I've seldom found any use for anything but part 2. It is worth having SQL92, mainly because it's so much more readable than the 99 spec :-( 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] Domains and type coercion
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> We could treat exact and binary-compatible matches alike (doesn't seem >> good), or put a special case into the operator selection rules to reduce >> domains to their basetypes before making the "exact match" test. > There could also be an explicit heuristic *after* the exact match > gathering to look for an exact match for domains reduced to their base > types. Is there any reason to look for domains before that? The problem in the case I gave was that the "exact match" heuristic was throwing away the operator we really wanted to use. I had "domain + int4" where domain is really numeric. In the base case, "numeric + int4", we'll keep both "numeric + numeric" and "int4 + int4" since each has one exact match, and later decide that "numeric + numeric" is preferred. In the domain case we will keep only "int4 + int4" ... oops. Testing later will not help. If we take the hard SQL99 line that domains *are* the base type plus constraints, then we could reduce domains to base types before we start the entire matching process, and this issue would go away. This would prevent declaring any specialized operators or functions for a domain. (In fact, I'd be inclined to set things up so that it's impossible to store domain type OIDs in pg_proc or pg_operator, thus saving the time of doing getBaseType on one side of the match.) Thoughts? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Fw: Fw: [HACKERS] bad performance on irix
No, I've been told it is not gonna be considered for 7.2x and I shall wait till 7.3. Luis Alberto Amigo Navarro wrote: > > > Makes me wonder... perhaps now someone will be convinced to take a look > > at the POSIX IPC patch. On some platforms (not on Linux I am afraid) > > POSIX mutexes might be quite a bit faster than SYSV semaphores. > > > Is there any current patch? > Regards ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Fw: Fw: [HACKERS] bad performance on irix
Igor Kovalenko wrote: > No, I've been told it is not gonna be considered for 7.2x and I shall > wait till 7.3. > > Luis Alberto Amigo Navarro wrote: > > > > > Makes me wonder... perhaps now someone will be convinced to take a look > > > at the POSIX IPC patch. On some platforms (not on Linux I am afraid) > > > POSIX mutexes might be quite a bit faster than SYSV semaphores. > > > > > Is there any current patch? > > Regards > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster I've been thinking, and I think it maybe possible that tuning kernel parameters could help, I'll keep you informed Thanks and regards begin:vcard n:Amigo Navarro;Luis Alberto tel;cell:609581857 x-mozilla-html:FALSE org:Universidad de Cantabria;Arquitectura de Computadores adr:;;Avda Los Castros S/N ;Santander;Cantabria;39005;España version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;0 fn:Luis Amigo end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Domains and type coercion
Tom Lane wrote: > > If we take the hard SQL99 line that domains *are* the base type plus > constraints, then we could reduce domains to base types before we start > the entire matching process, and this issue would go away. This would > prevent declaring any specialized operators or functions for a domain. > (In fact, I'd be inclined to set things up so that it's impossible to > store domain type OIDs in pg_proc or pg_operator, thus saving the time > of doing getBaseType on one side of the match.) Thoughts? > IMHO this is the right thing to do. -- Fernando Nasser Red Hat - Toronto E-Mail: [EMAIL PROTECTED] 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Domains and type coercion
> If we take the hard SQL99 line that domains *are* the base type plus > constraints, then we could reduce domains to base types before we start > the entire matching process, and this issue would go away. This would > prevent declaring any specialized operators or functions for a domain. > (In fact, I'd be inclined to set things up so that it's impossible to > store domain type OIDs in pg_proc or pg_operator, thus saving the time > of doing getBaseType on one side of the match.) Thoughts? It would be fairly straight forward to simply copy the domain base type into the atttypid, then create an atttypdomain (normally 0, except in the case of a domain). Everything would use the attypid, except for \d and pg_dump which could use the domain if it exists. Is this something I should do? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Domains and type coercion
"Rod Taylor" <[EMAIL PROTECTED]> writes: > It would be fairly straight forward to simply copy the domain base > type into the atttypid, then create an atttypdomain (normally 0, > except in the case of a domain). Everything would use the attypid, > except for \d and pg_dump which could use the domain if it exists. > Is this something I should do? No, because it's quite irrelevant to the problem of type coercion, which works with expressions; attributes are only one part of the expression world. Actually, considering Fernando's point that a CAST ought to apply the constraints associated with a domain type, your attribute-based implementation is wrong anyway. Rather than merging the domain constraints into the table definition (which will be a nightmare for pg_dump to sort out, anyway) keep 'em separate. The constraints could be checked during casting from a base type to a domain type --- take a look at the existing mechanism for enforcing typmod (length limits), which after all is a simplistic kind of domain constraint. 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
[HACKERS] Problem compiling PostgreSQL 7.2 on IRIX 6.5.15f
I've been able to compile previous versions of PostgreSQL on my SGI machines, but am having trouble this time. I have an SGI O2 with IRIX 6.5.15f, gmake 3.79.1, and MIPSPro C 7.3.1.3 compiler. I can get through the 'configure' step fine. I've copied the Makefile.irix5 up to the src directory. I've also added '-O2' flags to the CFLAGS and LDFLAGS in template/irix5. When I run 'gmake all', the compilation errors on: cc-1521 cc: WARNING File = /usr/include/setjmp.h, Line = 26 A nonstandard preprocessing directive is used. #ident "$Revision: 1.36 $" ^ cc-1521 cc: WARNING File = /usr/include/sys/ipc.h, Line = 17 A nonstandard preprocessing directive is used. #ident"$Revision: 3.30 $" ^ cc-1070 cc: ERROR File = xact.c, Line = 587 The indicated type is incomplete. struct timeval delay; ^ 1 error detected in the compilation of "xact.c". gmake[4]: *** [xact.o] Error 2 gmake[4]: Leaving directory `/usr/src/postgresql-7.2/src/backend/access/transam' gmake[3]: *** [transam-recursive] Error 2 gmake[3]: Leaving directory `/usr/src/postgresql-7.2/src/backend/access' gmake[2]: *** [access-recursive] Error 2 gmake[2]: Leaving directory `/usr/src/postgresql-7.2/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/src/postgresql-7.2/src' gmake: *** [all] Error 2 Can anyone offer a suggestion on what I'm doing wrong? Thanks. -Tony ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Bruce Momjian writes: > I am adding users and groups to pg_hba.conf. You know what would be cool? GRANT CONNECT ON mydb TO GROUP myfriends; and it rewrites pg_hba.conf accordingly. Just a thought... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Where to get official SQL spec (was Re: Domain Support)
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them > off some ftp site yonks ago. Anyone want them? Is it legal for me to have > them or distribute them? My understanding of the legal situation is that what's circulating around the net in plain text form is *draft* versions of the spec. It is okay to redistribute these freely. The *official* version you are supposed to pay for. No, I don't know how close the drafts really are to the final. Personally I tend to consult the draft versions more than the PDF versions anyway, because it's vastly easier to search flat ASCII files than PDFs ... so I sure hope they're pretty close ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I am adding users and groups to pg_hba.conf. > > You know what would be cool? > > GRANT CONNECT ON mydb TO GROUP myfriends; > > and it rewrites pg_hba.conf accordingly. > > Just a thought... We are actually not that far away. If you create a group for each database, you can grant access to just that group and add/delete users from that group at will. My new pg_group code will do that. Now, as far as rewriting pg_hba.conf, that goes into an area where we are not sure if the master connection information is in the file or in the database. We also get into a chicken and egg case where we have to have the database loaded to connect to it. I am interested to hear where people think we should go with this. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Linux/mips compile should not use -mips2
Oliver Elphick writes: > > > Upstream automatically passes -mips2 to gcc on mips platforms. In the case > > > of Linux, this should not be done, as the main reason to use it (ll/sc) is > > > handled by glibc and emulated by the kernel. It also makes all of postgresql > > > unusable on DECstation mipsel machines,... It's gone. I never liked it there anyway. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Function call crashes server
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: >> regression=# SELECT update_pg_pwd(); >> ERROR: getTypeOutputInfo: Cache lookup of type 0 failed > Wouldn't it be nice to make this a feature that allows > stored procedures (void update_pg_pwd ()) ? Correctly register > this function to not return anything ? This is what the 0 is actually > supposed to mean here, no ? No, in this case the procedure is a trigger procedure and is not supposed to be called directly at all. But we don't have a distinguishable signature for triggers as yet. One of the changes I'd like to make eventually is that trigger procs take and return some special pseudo-type, so that the type system can catch this sort of mistake explicitly. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Ross J. Reedstrom wrote: > On Thu, Mar 21, 2002 at 11:38:05AM -0500, Bruce Momjian wrote: > > > > I am handling it like pg_shadow. The problem is that because I expand > > pg_group inside the pg_hba tokens, I have to retokenize pg_hba.conf too > > after pg_group changes. I assumed we didn't want pg_hba.conf > > retokenized on a password change and only on a pg_ctl reload. > > > > My new code has a separate pg_group token list which is not expanded > > into the pg_hba.conf token list and is traversed for every connection. > > Hmm, your trading performance on every connection for less work on the > rare event of a password change? What's wrong with reparsing pg_hba.conf > at password/group change? Streamline the common case, don't optimize for > the rare condition. Yes, that was the issue. We tell people pg_hba.conf only gets reloaded when they tell the postmaster to do it. We can't have it happening at random times, e.g. password change. My new coding will need to only spin through a list of group names, not the list of users in each group. That's why the new format for global/pg_group should make things ok for doing this at connection time. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Problem with reloading groups in pg_hba.conf
Bruce Momjian <[EMAIL PROTECTED]> writes: > Yes, that was the issue. We tell people pg_hba.conf only gets reloaded > when they tell the postmaster to do it. We can't have it happening at > random times, e.g. password change. I agree on that: the signal should cause the postmaster to reload pg_pwd/pg_group info *only*. So you cannot integrate the data from these files into the same datastructure as you use for pg_hba.conf; they have to be separate datastructures. I think what you are really asking is whether to expand groups by substitution of user names during read of the file, vs doing it on-the-fly when accepting a connection. On that I agree with Ross: better to move work out of the connection logic and into the file reread logic as much as possible. 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] Problem with reloading groups in pg_hba.conf
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Yes, that was the issue. We tell people pg_hba.conf only gets reloaded > > when they tell the postmaster to do it. We can't have it happening at > > random times, e.g. password change. > > I agree on that: the signal should cause the postmaster to reload > pg_pwd/pg_group info *only*. So you cannot integrate the data from > these files into the same datastructure as you use for pg_hba.conf; > they have to be separate datastructures. > > I think what you are really asking is whether to expand groups by > substitution of user names during read of the file, vs doing it > on-the-fly when accepting a connection. On that I agree with Ross: > better to move work out of the connection logic and into the file > reread logic as much as possible. Yes, I am doing that. pg_group will be tokenized into username tokens, and on connection, the mention of a group token in pg_hba.conf will cause a spin through the pg_group tokens to find a matching groupname, then it will look for the requested username. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > The problem is when to retokenize pg_hba.conf after a new pg_group is > > made. Seems I can either force administrators to 'pg_ctl reload' to > > update for group changes, or automatically retokenize pg_hba.conf every > > time I update pg_group. > > Why exactly are you looking to reinvent the wheel, rather than doing > it the same way we currently handle pg_shadow updates? Send the > postmaster a signal when you modify the flat file, and it can reread > the file on receipt of the signal. See SendPostmasterSignal(). I am handling it like pg_shadow. The problem is that because I expand pg_group inside the pg_hba tokens, I have to retokenize pg_hba.conf too after pg_group changes. I assumed we didn't want pg_hba.conf retokenized on a password change and only on a pg_ctl reload. My new code has a separate pg_group token list which is not expanded into the pg_hba.conf token list and is traversed for every connection. Is this the right way to go? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
I think I have figured out a way to do this efficiently. Instead of making pg_group with groupname/username on each line, I will do groupname/username,username, ... so I can spin through the group token file much quicker; that way, I can read just retokenize pg_group and spin through it for each connection. I think that is the way to go. --- Bruce Momjian wrote: > I am adding users and groups to pg_hba.conf. The coding is done but I > am stuck on a reload issue. > > As you may know, 7.2 tokenizes pg_hba.conf once, and reads those tokens > to test every connection request. I have added code to dump the > group/user mappings into global/pg_group and the postmaster can read > that file and substitute group names for users lists during > tokenization. > > I have also added code to dump a new pg_group every time a group/user is > modified. (Users have to be done because of user renaming.) > > The problem is when to retokenize pg_hba.conf after a new pg_group is > made. Seems I can either force administrators to 'pg_ctl reload' to > update for group changes, or automatically retokenize pg_hba.conf every > time I update pg_group. (We don't have any way of handling user renames > in pg_hba.conf because we enter those as strings, but pg_group will > handle them.) > > Does anyone see another option? I can write code so only pg_global is > retokenized, but right now the user tokens are pulled out for the > matching group and inlined into the token stream. If I have a separate > token tree for pg_group, each connection will have to spin through the > tokens looking for matching group names. I suppose it isn't a big deal, > but I want to make sure we want to prevent auto-reloading of pg_hba.conf > on user/group changes, and just reload pg_group. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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
[HACKERS] Linux/mips compile should not use -mips2
I sent a message about this yesterday, but it does not appear to have
got to the list.
According to the attached message, mips builds for Linux should not use
-mips2 in the compilation or linking. It appears that this can be
prevented by removing the mips special case from src/template/linux.
-Forwarded Message-
From: [EMAIL PROTECTED]
To: Oliver Elphick <[EMAIL PROTECTED]>
Subject: Re: [Fwd: Mail delivery failed: returning message to sender]
Date: 20 Mar 2002 07:48:38 -0800
On Wed, Mar 20, 2002 at 09:52:52AM +, Oliver Elphick wrote:
> > Upstream automatically passes -mips2 to gcc on mips platforms. In the case
> > of Linux, this should not be done, as the main reason to use it (ll/sc) is
> > handled by glibc and emulated by the kernel. It also makes all of postgresql
> > unusable on DECstation mipsel machines,...
>
> The build failure appears to be that
> debian/tmp/usr/lib/postgresql/bin/postgres has somehow been deleted
> during the build. (The build log shows it being installed correctly.)
> Are you saying that this is related to use of -mips2, or is that a
> totally separate problem?
No, the kernel doesn't always have the greatest error messages...
test.c:
main(void)
{
return 1;
}
rmurray@resume:~$ gcc -o t test.c ; ls -l t ; ./t
-rwxr-xr-x1 rmurray rmurray 7628 Mar 20 16:43 t
rmurray@resume:~$ gcc -mips2 -o t test.c ; ls -l t ; ./t
-rwxr-xr-x1 rmurray rmurray 7628 Mar 20 16:44 t
bash: ./t: No such file or directory
The reason this worked in the past is due to a bug in binutils -- it wasn't
setting the mips2 bit in the elf header of the binary. That bug has now
been fixed, and the kernel refuses to run anything with a mips# bit set
in the header, as it is used to indicate an irix binary, according to the
comments in elf.h.
--
Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED])
The opinions expressed here are my own.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Function call crashes server
> Removing the special-case logic in ExecTypeFromTL yields > > regression=# SELECT update_pg_pwd(); > ERROR: getTypeOutputInfo: Cache lookup of type 0 failed Wouldn't it be nice to make this a feature that allows stored procedures (void update_pg_pwd ()) ? Correctly register this function to not return anything ? This is what the 0 is actually supposed to mean here, no ? Such a proc would need a fmgr, that generates an empty resultset. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Where to get official SQL spec (was Re: Domain Support)
> "Rod Taylor" <[EMAIL PROTECTED]> writes: > > I've not found a cheap resource for the real one. Ie. priced suitably > > to fit a hobby project :) I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them off some ftp site yonks ago. Anyone want them? Is it legal for me to have them or distribute them? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Fw: Fw: [HACKERS] bad performance on irix
Just remember that patches for 7.3 are being accepted at this very moment... Chris > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Igor Kovalenko > Sent: Friday, 22 March 2002 1:31 AM > To: Luis Alberto Amigo Navarro > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Fw: Fw: [HACKERS] bad performance on irix > > > No, I've been told it is not gonna be considered for 7.2x and I shall > wait till 7.3. > > Luis Alberto Amigo Navarro wrote: > > > > > Makes me wonder... perhaps now someone will be convinced to > take a look > > > at the POSIX IPC patch. On some platforms (not on Linux I am afraid) > > > POSIX mutexes might be quite a bit faster than SYSV semaphores. > > > > > Is there any current patch? > > Regards > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Where to get official SQL spec (was Re: Domain Support)
Christopher Kings-Lynne wrote: > > "Rod Taylor" <[EMAIL PROTECTED]> writes: > > > I've not found a cheap resource for the real one. Ie. priced suitably > > > to fit a hobby project :) > > I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them > off some ftp site yonks ago. Anyone want them? Is it legal for me to have > them or distribute them? I have these URL's: > http://www.ansi.org > http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt > ftp://gatekeeper.dec.com/pub/standards/sql > ftp://jerry.ece.umassd.edu/isowg3/x3h2/Standards/ -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] notification: pg_notify ?
Jeff Davis asked on -general why NOTIFY doesn't take an optional argument, specifying a message that is passed to the listening backend. This feature is supported by Oracle and other databases and I think it's quite useful, so I've started to implement it. Most of the modifications have been pretty straight-forward, except for 2 issues: (1) Processing notifies. Currently, the only data that is passed from the notifying backend to the listening one is the PID of the notifier, which is stored in the "notification" column of pg_listener. In order to pass messages from notifier to listener, I could add another column to pg_listener, but IMHO that's a bad idea: there is really no reason for this kind of data to be in pg_listener in the first place. pg_listener should simply list the PIDs of listening backends, as well as the conditions upon which they are listening -- any data that is related to specific notifications should be put elsewhere. (2) Multiple notifications on the same condition name in a short time span are delivered as a single notification. This isn't currently a problem because the NOTIFY itself doesn't carry any data (other than backend PID), it just informs the listener that an event has occurred. If we allow NOTIFY to send a message to the listener, this is not good -- the listener should be notified for each and every notification, since the contents of the message could be important. Solution: Create a new system catalog, pg_notify. This should contain 4 columns: relname: the name of the NOTIFY condition that has been sent message: the optional message sent by the NOTIFY sender: the PID of the backend that sent the NOTIFY receiver: the PID of the listening backend AFAICT, this should resolve the two issues mentioned above. The actual notification of a listening backend is still done at transaction commit, by sending a SIGUSR2: however, all this does is to ask the backend to scan through pg_notify, looking for tuples containing its PID in "receiver". Therefore, even if Unix doesn't send multiple signals for multiple notifications, a single signal should be enough to ensure a scan of pg_notify, where any additional notifications will be found. If we continued to add columns to pg_listener, there would be a limit of 1 tuple per listening backend: thus, we would still run into problems with multiple notifications being ignored. Can anyone see a better way to do this? Are there any problems with the implementation I've outlined? Any feedback would be appreciated. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Bruce Momjian wrote: > > Now, as far as rewriting pg_hba.conf, that goes into an area where we > are not sure if the master connection information is in the file or in > the database. We also get into a chicken and egg case where we have to > have the database loaded to connect to it. I am interested to hear > where people think we should go with this. > I would like to offer this opinion: postmaster should connect to the database directory as the user who started it. ---(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] notification: pg_notify ?
Neil Conway <[EMAIL PROTECTED]> writes: > Solution: Create a new system catalog, pg_notify. It's not apparent to me why that helps much. There is a very significant performance problem with LISTEN/NOTIFY via pg_listener: in any application that generates notifications at a significant rate, pg_listener will accumulate dead tuples at that same rate, and we will soon find ourselves wasting lots of time scanning through dead tuples. Frequent VACUUMs might help, but the whole thing is really quite silly: why are we using a storage mechanism that's designed entirely for *stable* storage of data to pass inherently *transient* signals? If the system crashes, we have absolutely zero interest in the former contents of pg_listener (and indeed need to go to some trouble to get rid of them). So if someone wants to undertake a revision of the listen/notify code, I think the first thing to do ought to be to throw away pg_listener entirely and develop some lower-overhead, shared-memory-based communication mechanism. You could do worse than to use the shared cache inval code as a model --- or perhaps even incorporate LISTEN signaling into that mechanism. (Actually that seems like a good plan, so as not to use shared memory inefficiently by dedicating two separate memory pools to parallel purposes.) If you follow the SI model then NOTIFY messages would essentially be broadcast to all backends, and whether any given backend pays attention to one is its own problem; no one else cares. A deficiency of the SI implementation (and probably anything else that relies solely on shared memory) is that it can suffer from buffer overrun, since there's a fixed-size message pool. For the purposes of cache inval, we cope with buffer overrun by just invalidating everything in sight. It might be a workable tradeoff to cope with buffer overrun for LISTEN/NOTIFY by reporting notifies on all conditions currently listened for. Assuming that overrun is infrequent, the net performance gain from being able to use shared memory is probably worth the occasional episode of wasted work. BTW, I would like to see a spec for this "notify with parameter" feature before it's implemented, not after. Exactly what semantics do you have in mind? 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] Where to get official SQL spec (was Re: Domain Support)
It would be nice to add it to the docs of the project. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: "Rod Taylor" <[EMAIL PROTECTED]>; "Hackers List" <[EMAIL PROTECTED]> Sent: Friday, March 22, 2002 1:29 PM Subject: Re: [HACKERS] Where to get official SQL spec (was Re: Domain Support) > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > I seem to have parts 1-5 .txt of sql99 on my computer here. I ftp'd them > > off some ftp site yonks ago. Anyone want them? Is it legal for me to have > > them or distribute them? > > My understanding of the legal situation is that what's circulating > around the net in plain text form is *draft* versions of the spec. > It is okay to redistribute these freely. The *official* version > you are supposed to pay for. > > No, I don't know how close the drafts really are to the final. > > Personally I tend to consult the draft versions more than the PDF > versions anyway, because it's vastly easier to search flat ASCII > files than PDFs ... so I sure hope they're pretty close ... > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] notification: pg_notify ?
On Thu, 2002-03-21 at 22:41, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > Solution: Create a new system catalog, pg_notify. > > It's not apparent to me why that helps much. Well, it solves the functional problem at hand -- this feature can now be implemented. However, I agree with you that there are still problems with NOTIFY and pg_listener, as you have outlined. > So if someone wants to undertake a revision of the listen/notify code, > I think the first thing to do ought to be to throw away pg_listener > entirely and develop some lower-overhead, shared-memory-based > communication mechanism. You could do worse than to use the shared > cache inval code as a model --- or perhaps even incorporate LISTEN > signaling into that mechanism. (Actually that seems like a good plan, > so as not to use shared memory inefficiently by dedicating two separate > memory pools to parallel purposes.) That's very interesting. I need to read the code you're referring to before I can comment further, but I'll definately look into this. That's a good idea. > If you follow the SI model then NOTIFY messages would essentially be > broadcast to all backends, My apologies, but what's the SI model? > A deficiency of the SI implementation (and probably anything else that > relies solely on shared memory) is that it can suffer from buffer > overrun, since there's a fixed-size message pool. For the purposes > of cache inval, we cope with buffer overrun by just invalidating > everything in sight. It might be a workable tradeoff to cope with > buffer overrun for LISTEN/NOTIFY by reporting notifies on all conditions > currently listened for. This assumes that the NOTIFY condition we're waiting for is fairly routine (e.g. "table x is updated, refresh the cache"). If a NOTIFY actually represents the occurence of a non-trivial condition, this could be a problem (e.g. "the site crashed, page the sys-admin", and the buffer happens to overflow at 2 AM :-) ). However, it's questionable whether that is an appropriate usage of NOTIFY. > BTW, I would like to see a spec for this "notify with parameter" feature > before it's implemented, not after. What information would you like to know? > Exactly what semantics do you have in mind? The current syntax I'm using is: NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; But I'm open to suggestions for improvement. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(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] Where to get official SQL spec (was Re: Domain Support)
> It would be nice to add it to the docs of the project. If anyone wants a copy, just holler. A bunch of us have exchanged those drafts over the years so speak up and someone will forward you a copy... I'm sure we stumbled on them via google or somesuch so a quick search would get you an independent copy too... - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] notification: pg_notify ?
Neil Conway <[EMAIL PROTECTED]> writes: >> BTW, I would like to see a spec for this "notify with parameter" feature >> before it's implemented, not after. > The current syntax I'm using is: > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; Hm. How are you going to transmit that to the client side without changing the FE/BE protocol? (While we will no doubt find reasons to change the protocol in the future, I'm not eager to force a protocol update right now; at least not without more reason than just NOTIFY parameters.) If we want to avoid a protocol break then it seems like the value transmitted to the client has to be a single string. I guess we could say that what's transmitted is a single string in the form condition_name.additional_text (or pick some other delimiter instead of dot, but doesn't seem like it matters much). Pretty grotty though. Another thought that comes to mind is that we could reinterpret the parameter of LISTEN as a pattern to match against the strings generated by NOTIFY --- then there's no need to draw a hard-and-fast distinction between condition name and parameter text; it's all in the eye of the beholder. However it's tough to see how to do this without breaking backwards compatibility at the syntax level --- you'd really want LISTEN to be accepting a string literal, rather than a name, to make this happen. That brings up the more general point that you'd want at least the "message" part of NOTIFY to be computable as an SQL expression, not just a literal. It might be entertaining to try to reimplement NOTIFY as something that's internally like a SELECT, just with a funny data destination. I find this attractive because if it were a SELECT then it could have (at least on the inside) a WHERE clause, which'd make it possible to handle NOTIFYs in conditional rules in a less broken fashion than we do now. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] notification: pg_notify ?
> > Exactly what semantics do you have in mind? > > The current syntax I'm using is: > > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; > > But I'm open to suggestions for improvement. Have you considered visiting the oracle site and finding their documentation for their NOTIFY statement and making sure you're using compatible syntax? They might have extra stuff as well. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Again, sorry, caching, (Tom What do you think: function
Neil,
Following is an email I sent the other day detailing how this works.
The entry point to the underlying invalidation system is the heap
manipulation functions: heap_delete(), heap_update(). (I've just had a
quick look at heap_insert() and cannot find where the cache modification
takes place)
These call RelationInvalidateHeapTuple() ->
PrepareForTupleInvalidation() ->
RegisterCatcacheInvalidation()/RegisterRelcacheInvalidation.
These feed linked lists which get processed at the end of the transaction
as is detailed below. Clearly, this is a much better way of running the
LISTEN/NOTIFY than storing them in the system.
Gavin
-- Forwarded message --
Date: Wed, 20 Mar 2002 02:17:09 +1100 (EST)
From: Gavin Sherry <[EMAIL PROTECTED]>
To: Greg Copeland <[EMAIL PROTECTED]>
Cc: mlw <[EMAIL PROTECTED]>, Jeff Davis <[EMAIL PROTECTED]>,
PostgreSQL-development <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] Again, sorry, caching, (Tom What do you think: function
On 19 Mar 2002, Greg Copeland wrote:
> On Tue, 2002-03-19 at 07:46, mlw wrote:
> [snip]
>
> > Right now, the function manager can only return one value, or one set of values
> > for a column. It should be possible, but require a lot of research, to enable
> > the function manager to return a set of rows. If we could get that working, it
> > could be fairly trivial to implement a cache as a contrib project. It would
> > work something like this:
> >
> > select querycache("select * from mytable where foo='bar') ;
>
> Interesting concept...but how would you know when the cache has become
> dirty? That would give you a set of rows...but I don't understand what
> would let you know your result set is invalid?
>
> Perhaps: select querycache( foobar_event, "select * from my table where
> foo='bar'" ) ; would automatically create a listen for you??
Personally, I think this method of providing query caching is very
messy. Why not just implement this along side the system relation
cache? This maybe be slightly more time consuming but it will perform
better and will be able to take advantage of Postgres's current MVCC.
There would be three times when the cache would be interacted with
ExecRetrieve() would need to be modified to handle a
prepare-for-cache-update kind of feature. This would involve adding the
tuple table slot data into a linked list.
At the end of processing/transaction and if the query was successfuly, the
prepare-for-cache-update list could be processed by AtCommit_Cache()
(called from CommitTransaction()) and the shared cache updated.
2) attempt to get result set from cache
Before planning in postgres.c, test if the query will produce an already
cached result set. If so, send the data off from cache.
3) modification of underlying heap
Like (1), produce a list inside the executor (ExecAppend(), ExecDelete(),
ExecReplace() -> RelationInvalidateHeapTuple() ->
PrepareForTupleInvalidation()) which gets processed by
AtEOXactInvalidationMessages(). This results in the affected entries being
purged.
---
I'm not sure that cached results is a direction postgres need move in. But
if it does, I think this a better way to do it (given that I may have
overlooked something) than modifying the function manager (argh!).
Gavin
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Where to get official SQL spec (was Re: Domain Support)
Thomas Lockhart wrote: > > It would be nice to add it to the docs of the project. > > If anyone wants a copy, just holler. A bunch of us have exchanged those > drafts over the years so speak up and someone will forward you a copy... > > I'm sure we stumbled on them via google or somesuch so a quick search > would get you an independent copy too... Should I add the URL's to the developer's FAQ? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Problem with reloading groups in pg_hba.conf
pgman wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> >
> > > I am adding users and groups to pg_hba.conf.
> >
> > You know what would be cool?
> >
> > GRANT CONNECT ON mydb TO GROUP myfriends;
> >
> > and it rewrites pg_hba.conf accordingly.
> >
> > Just a thought...
>
> We are actually not that far away. If you create a group for each
> database, you can grant access to just that group and add/delete users
> from that group at will. My new pg_group code will do that.
>
> Now, as far as rewriting pg_hba.conf, that goes into an area where we
> are not sure if the master connection information is in the file or in
> the database. We also get into a chicken and egg case where we have to
> have the database loaded to connect to it. I am interested to hear
> where people think we should go with this.
I have another idea. What if we had a default group for each database,
like pg_connect_{dbname}, and you can add/remove users from that group
to grant/remove connection privileges? Sort of like a default +dbname
in pg_hba.conf.
It sort of merges the group feature with pg_hba.conf connections.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(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] Where to get official SQL spec (was Re: Domain Support)
Does it mean that we are not 100% sure they are open documents? - Original Message - From: "Thomas Lockhart" <[EMAIL PROTECTED]> To: "Nicolas Bazin" <[EMAIL PROTECTED]> Cc: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>; "Tom Lane" <[EMAIL PROTECTED]>; "Rod Taylor" <[EMAIL PROTECTED]>; "Hackers List" <[EMAIL PROTECTED]> Sent: Friday, March 22, 2002 3:36 PM Subject: Re: Where to get official SQL spec (was Re: Domain Support) > > It would be nice to add it to the docs of the project. > > If anyone wants a copy, just holler. A bunch of us have exchanged those > drafts over the years so speak up and someone will forward you a copy... > > I'm sure we stumbled on them via google or somesuch so a quick search > would get you an independent copy too... > > - Thomas > ---(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] SET NULL / SET NOT NULL
Hi, I'm halfway thru implementing setting a column's nullness (I've done changing to null, but not changing to not null) Peter E. said: > Using the standard precedent above, how about > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL; > ALTER TABLE blah ALTER COLUMN col DROP NOT NULL; Do we want the above syntax, or this syntax: ALTER TABLE blah ALTER COLUMN col SET NOT NULL; ALTER TABLE blah ALTER COLUMN col SET NULL; The former sort of treats it like a contraint, where as the latter treats it as it is during the CREATE TABLE statement. Say in the future we want to support changing column type as well. How would we work that in? ALTER TABLE blah ALTER COLUMN col SET int4; ?? Then we should allow people to do this: ALTER TABLE blah ALTER COLUMN col SET int4 NULL DEFAULT '3'; So they can change their entire column in one statement. So really this implies that ALTER COLUMN/SET NULL is the correct syntax, rather than ALTER COLUMN/DROP NOT NULL. In fact, maybe we could support BOTH syntaxes... Comments? Let's sort this out before I submit my patch. Regards, Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SET NULL / SET NOT NULL
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Say in the future we want to support changing column type as well. How > would we work that in? > ALTER TABLE blah ALTER COLUMN col SET int4; ?? Seems one keyword shy of a load; I'd prefer ALTER TABLE blah ALTER COLUMN col SET TYPE int4; Otherwise, every keyword that might appear after SET will have to be fully reserved (else it couldn't be distinguished from a type name). I like the "SET NULL"/"SET NOT NULL" variant better than SET/DROP, even though "SET NULL" is perhaps open to misinterpretation. "DROP NOT NULL" seems just as confusing for anyone who's not read the documentation :-( 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] Where to get official SQL spec (was Re: Domain Support)
> Does it mean that we are not 100% sure they are open documents? Hmm. Yeah, though afaics there is no copyright inside the docs. - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SET NULL / SET NOT NULL
> Seems one keyword shy of a load; I'd prefer > > ALTER TABLE blah ALTER COLUMN col SET TYPE int4; > > Otherwise, every keyword that might appear after SET will have to be > fully reserved (else it couldn't be distinguished from a type name). I like that... So would you then envisage something like this: ALTER TABLE blah ALTER COLUMN col SET TYPE int4 DEFAULT 3 NOT NULL; or ALTER TABLE blah ALTER COLUMN col SET DEFAULT 3 TYPE int4 NULL; etc. ie. Order wouldn't matter and you could do them all at once for convenience? This seems like a cool idea to me. Problem with all this, of course, is that it's different to everyone else's syntax, but then they're all different to each other. There's no standard for it, but if there's a new standard - I wonder what they would specify? Since altering a column is a not oft used operation, I would expect that the punters wouldn't have a problem looking in the docs for how to do it, for each different DBMS they use... Chris ---(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] Problem with reloading groups in pg_hba.conf
Bruce Momjian writes:
> I have another idea. What if we had a default group for each database,
> like pg_connect_{dbname}, and you can add/remove users from that group
> to grant/remove connection privileges?
That strikes me as a very ugly abuse of the privilege system. If you want
to grant a privilege, use GRANT, not the name of a group.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SET NULL / SET NOT NULL
Christopher Kings-Lynne writes: > Do we want the above syntax, or this syntax: > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL; > ALTER TABLE blah ALTER COLUMN col SET NULL; My only objection to the second command is that it's plain wrong. You don't set anything to NULL, so don't make the command look like it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SET NULL / SET NOT NULL
Tom Lane wrote: > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > > Say in the future we want to support changing column type as well. How > > would we work that in? > > > ALTER TABLE blah ALTER COLUMN col SET int4; ?? > > Seems one keyword shy of a load; I'd prefer > > ALTER TABLE blah ALTER COLUMN col SET TYPE int4; > > Otherwise, every keyword that might appear after SET will have to be > fully reserved (else it couldn't be distinguished from a type name). > > I like the "SET NULL"/"SET NOT NULL" variant better than SET/DROP, even > though "SET NULL" is perhaps open to misinterpretation. "DROP NOT NULL" > seems just as confusing for anyone who's not read the documentation :-( Yes, DROP NOT NULL does have a weird twist to it. However, does SET NULL sound to much like you are setting all the values to NULL? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Problem with reloading groups in pg_hba.conf
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > I have another idea. What if we had a default group for each database,
> > like pg_connect_{dbname}, and you can add/remove users from that group
> > to grant/remove connection privileges?
>
> That strikes me as a very ugly abuse of the privilege system. If you want
> to grant a privilege, use GRANT, not the name of a group.
We could use GRANT and internally do it with per-database system groups.
It would fit into our system cleanly, and could be dumped/reloaded
cleanly too. Unfortunately, that would give us two places to specify
the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem?
It would be tricky to grant access to only one db or all db's using
GRANT. Not sure how that would be specified. This is where we start to
get overlap and confusion because it doesn't behave just like
pg_hba.conf but also doesn't have the same flexibility of pg_hba.conf.
I am still looking for ideas.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SET NULL / SET NOT NULL
> > Do we want the above syntax, or this syntax: > > > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL; > > ALTER TABLE blah ALTER COLUMN col SET NULL; > > My only objection to the second command is that it's plain wrong. You > don't set anything to NULL, so don't make the command look like it. So then how is it any more wrong than SET NOT NULL? It should almost be ADD NOT NULL ... Chris ---(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] Problem with reloading groups in pg_hba.conf
Bruce Momjian <[EMAIL PROTECTED]> writes: > Unfortunately, that would give us two places to specify > the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem? Yes. What if they conflict? I don't think GRANT CONNECT fits into our setup at all. I also doubt that it will be needed very much once we have schemas. 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] Problem with reloading groups in pg_hba.conf
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Unfortunately, that would give us two places to specify > > the connecting users, pg_hba.conf and GRANT CONNECT. Is that a problem? > > Yes. What if they conflict? > > I don't think GRANT CONNECT fits into our setup at all. I also doubt > that it will be needed very much once we have schemas. With groups, we are at least giving admins a way to do this that they didn't have before. That may be enough. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SET NULL / SET NOT NULL
On Fri, Mar 22, 2002 at 02:34:57PM +0800, Christopher Kings-Lynne wrote: > > > Do we want the above syntax, or this syntax: > > > > > > ALTER TABLE blah ALTER COLUMN col SET NOT NULL; > > > ALTER TABLE blah ALTER COLUMN col SET NULL; > > > > My only objection to the second command is that it's plain wrong. You > > don't set anything to NULL, so don't make the command look like it. > > So then how is it any more wrong than SET NOT NULL? > > It should almost be ADD NOT NULL ... Hmm, there's this SQL92 keyword here: what do people thing of NULLABLE? SET NOT NULLABLE SET NULLABLE Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] notification: pg_notify ?
On Thu, 2002-03-21 at 23:41, Christopher Kings-Lynne wrote: > > > Exactly what semantics do you have in mind? > > > > The current syntax I'm using is: > > > > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; > > > > But I'm open to suggestions for improvement. > > Have you considered visiting the oracle site and finding their documentation > for their NOTIFY statement and making sure you're using compatible syntax? Oracle's implementation uses a completely different syntax to begin with: it's called DBMS_ALERT. > They might have extra stuff as well. >From a brief scan of their docs, it doesn't look like it. In fact, their implementation seems to be worse than PostgreSQL's in at least one respect: "A waiting application is blocked in the database and cannot do any other work." Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] notification: pg_notify ?
> On Thu, 2002-03-21 at 23:41, Christopher Kings-Lynne wrote: > > > > Exactly what semantics do you have in mind? > > > > > > The current syntax I'm using is: > > > > > > NOTIFY condition_name [ [WITH MESSAGE] 'my message' ]; > > > > > > But I'm open to suggestions for improvement. > > > > Have you considered visiting the oracle site and finding their > documentation > > for their NOTIFY statement and making sure you're using > compatible syntax? > > Oracle's implementation uses a completely different syntax to begin > with: it's called DBMS_ALERT. OK - not Oracle then. Didn't you say some other db did it - what about their syntax? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
