Thread
-
Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-28T16:16:42Z
Here are the open items. Thanks to Jan, the only 'hot' item left is the ps args issue. People on non-BSD platforms will see all their backends called 'postmaster', because argv[0] changes do not reflect in ps arg displays. I have asked that at least we get set_proctitle() working for Linux, but no one wants to do it, and we can't remove the it because we would have to add the exec() back into backend creation, which is impossible at this point. At this point, I am not even sure if Marc will allow a fix so late in the game. Perhaps we can put it into a minor 6.4 release. As long as you don't think we are going to get tons of complaints, I am not worried about it. Everything else is minor, so we are ready for 6.4 on November 1. --------------------------------------------------------------------------- Additions --------- regression test all platforms Serious Items ------------ change pg args for platforms that don't support argv changes (setproctitle()?, sendmail hack?) Docs ---- generate html/postscript documentation (User's Guide, Administrator's Guide, Programmer's Guide) (Thomas) make sure all changes are documented properly markup and merge JDBC docs from Peter (Thomas, others??) merge the release notes into doc/src/sgml/release.sgml (Bruce, Thomas) generate new text-format INSTALL and README from sgml sources (Thomas) markup of Jan's PL docs Minor items ----------- cnf-ify still can exhaust memory, make SET KSQO more generic permissions on indexes: what do they do? should it be prevented? allow multiple generic operators in expressions without the use of parentheses document/trigger/rule so changes to pg_shadow create pg_pwd large objects orphanage improve group handling improve PRIMARY KEY handling generate postmaster pid file and remove flock/fcntl lock code add ability to specifiy location of lock/socket files -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-28T16:49:59Z
> > > > Here are the open items. Thanks to Jan, the only 'hot' item left is the > > ps args issue. People on non-BSD platforms will see all their backends > > called 'postmaster', because argv[0] changes do not reflect in ps arg > > displays. > > > > I have asked that at least we get set_proctitle() working for Linux, but > > no one wants to do it, and we can't remove the it because we would have > > to add the exec() back into backend creation, which is impossible at > > this point. > > I'm running Linux 2.1.88 and get > > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle > > from ps. So what isn't working? Whoh, this is a shock. I thought this trick did not work under Linux. If it does, and no one has complained, we can consider the issue closed. Massimo did a nice job of moving my ps status stuff into pg_status.h, but it looks like the same code that modifies argv[0]. Perhaps it is the Linux version you are using. It give us a cheap 'db monitor' capability, wrapped into the 'ps' command. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] Open 6.4 items
Jan Wieck <jwieck@debis.com> — 1998-10-28T16:53:03Z
> > Here are the open items. Thanks to Jan, the only 'hot' item left is the > ps args issue. People on non-BSD platforms will see all their backends > called 'postmaster', because argv[0] changes do not reflect in ps arg > displays. > > I have asked that at least we get set_proctitle() working for Linux, but > no one wants to do it, and we can't remove the it because we would have > to add the exec() back into backend creation, which is impossible at > this point. I'm running Linux 2.1.88 and get 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle from ps. So what isn't working? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-28T17:06:23Z
> > > > Here are the open items. Thanks to Jan, the only 'hot' item left is the > > ps args issue. People on non-BSD platforms will see all their backends > > called 'postmaster', because argv[0] changes do not reflect in ps arg > > displays. > > > > Bruce, > > I asked for it a while ago but forgot about it. Anyway - I > think it is better to have precreated gram.c, y.tab.h and > scan.c files in src/pl/plpgsql/src too. Otherwise ppl not > having bison/flex might have a build problem. > > The only thing required is to take them out of the 'clean' rm > in Makefile.in and add the bison/flex created files to CVS. > If gram.c, y.tab.h and scan.l are present and newer than > gram.y and scan.l the Makefile will already skip the steps to > create them. Do they fail for people who have standard BSD yacc? Too large? No one has complained about it, but it may be true. Done. Removed from Makefile.in, and added via cvs. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] Open 6.4 items
Jan Wieck <jwieck@debis.com> — 1998-10-28T17:06:55Z
> > Here are the open items. Thanks to Jan, the only 'hot' item left is the > ps args issue. People on non-BSD platforms will see all their backends > called 'postmaster', because argv[0] changes do not reflect in ps arg > displays. > Bruce, I asked for it a while ago but forgot about it. Anyway - I think it is better to have precreated gram.c, y.tab.h and scan.c files in src/pl/plpgsql/src too. Otherwise ppl not having bison/flex might have a build problem. The only thing required is to take them out of the 'clean' rm in Makefile.in and add the bison/flex created files to CVS. If gram.c, y.tab.h and scan.l are present and newer than gram.y and scan.l the Makefile will already skip the steps to create them. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] Open 6.4 items
Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-28T17:08:56Z
> I'm running Linux 2.1.88 and get > > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle > > from ps. So what isn't working? Whoh, this is a shock. I thought this trick did not work under Linux. If it does, and no one has complained, we can consider the issue closed. For whatever it's worth, I see the same status stuff changing under NetBSD 1.3.2. Seems to work fine. Cheers, Brook
-
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-28T17:20:33Z
> The only thing required is to take them out of the 'clean' rm > in Makefile.in and add the bison/flex created files to CVS. > If gram.c, y.tab.h and scan.l are present and newer than > gram.y and scan.l the Makefile will already skip the steps to > create them. We should do that for the ecpg pre-processor also. - Tom -
Re: [HACKERS] Open 6.4 items
Jan Wieck <jwieck@debis.com> — 1998-10-28T17:35:01Z
> > Bruce, > > > > I asked for it a while ago but forgot about it. Anyway - I > > think it is better to have precreated gram.c, y.tab.h and > > scan.c files in src/pl/plpgsql/src too. Otherwise ppl not > > having bison/flex might have a build problem. > > > > The only thing required is to take them out of the 'clean' rm > > in Makefile.in and add the bison/flex created files to CVS. > > If gram.c, y.tab.h and scan.l are present and newer than > > gram.y and scan.l the Makefile will already skip the steps to > > create them. > > Do they fail for people who have standard BSD yacc? Too large? No one > has complained about it, but it may be true. They shouldn't be too large. But they get modified with sed(1) since this is a second independend scanner/parser inside the backend (after loading). I'm not 100% sure if the code generated by ANY other lex/yacc accepts the substitutions or if the resulting code is really that independet as it should be. > > Done. Removed from Makefile.in, and added via cvs. Thanks. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-28T19:17:45Z
On Wed, 28 Oct 1998, Bruce Momjian wrote: > Here are the open items. Thanks to Jan, the only 'hot' item left is the > ps args issue. People on non-BSD platforms will see all their backends > called 'postmaster', because argv[0] changes do not reflect in ps arg > displays. Since there were no problem reports for this, I assumed that it was an 'asthetic change' more then anything. Once v6.4 is released, I'll dive into it with the Linux guys here at the University... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-28T19:22:51Z
Doesn't work under Solaris, but, then again, neither does sendamil's, so that isn't a shock :) On Wed, 28 Oct 1998, Brook Milligan wrote: > > I'm running Linux 2.1.88 and get > > > > 15572 p2 S 0:01 /usr/local/pgsql/bin/postmaster -o -F > > 16121 p2 S 0:01 /usr/local/pgsql/bin/postgres localhost twieck twieck idle > > > > from ps. So what isn't working? > > Whoh, this is a shock. I thought this trick did not work under Linux. > If it does, and no one has complained, we can consider the issue closed. > > For whatever it's worth, I see the same status stuff changing under > NetBSD 1.3.2. Seems to work fine. > > Cheers, > Brook > Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-29T03:36:45Z
> On Wed, 28 Oct 1998, Bruce Momjian wrote: > > > Here are the open items. Thanks to Jan, the only 'hot' item left is the > > ps args issue. People on non-BSD platforms will see all their backends > > called 'postmaster', because argv[0] changes do not reflect in ps arg > > displays. > > Since there were no problem reports for this, I assumed that it > was an 'asthetic change' more then anything. Once v6.4 is released, I'll > dive into it with the Linux guys here at the University... Looks like it works for most people. I will remove it from the list, and see if someone complains. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] Open 6.4 items
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-29T03:37:24Z
> Doesn't work under Solaris, but, then again, neither does sendamil's, so > that isn't a shock :) Man, if sendmail's doesn't work, that is really broken. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-29T04:32:49Z
On Wed, 28 Oct 1998, Bruce Momjian wrote: > > Doesn't work under Solaris, but, then again, neither does sendamil's, so > > that isn't a shock :) > > Man, if sendmail's doesn't work, that is really broken. Solaris just doesn't have any mechanisms to work around the limitation, I guess *shrug* It really sucks when you want to SIGHUP the "parent process", which, under FreeBSD at least, is the one that states: -accepting connections, but under Solaris they are *all* the same :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items
Matthew N. Dodd <winter@jurai.net> — 1998-10-29T15:24:36Z
On Thu, 29 Oct 1998, The Hermit Hacker wrote: > Solaris just doesn't have any mechanisms to work around the > limitation, I guess *shrug* It really sucks when you want to SIGHUP > the "parent process", which, under FreeBSD at least, is the one that > states: -accepting connections, but under Solaris they are *all* the > same :) $ ps -eaf UID PID PPID C STIME TTY TIME CMD root 0 0 0 Oct 12 ? 0:01 sched root 1 0 0 Oct 12 ? 0:15 /etc/init - ... You'll note the 'PPID' field. 3 guesses what that stands for. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | -
Re: [HACKERS] Open 6.4 items
Jan Wieck <jwieck@debis.com> — 1998-10-29T16:31:19Z
> > On Thu, 29 Oct 1998, The Hermit Hacker wrote: > > Solaris just doesn't have any mechanisms to work around the > > limitation, I guess *shrug* It really sucks when you want to SIGHUP > > the "parent process", which, under FreeBSD at least, is the one that > > states: -accepting connections, but under Solaris they are *all* the > > same :) > > $ ps -eaf > UID PID PPID C STIME TTY TIME CMD > root 0 0 0 Oct 12 ? 0:01 sched > root 1 0 0 Oct 12 ? 0:15 /etc/init - > ... > > You'll note the 'PPID' field. > > 3 guesses what that stands for. > Don't see how this is related to the topic - sorry. PPID is the parent process ID. sched has no parent (it's a kernel pseudo process) and init has sched as father. For all other processes the PPID is set to init's PID at the time their father dies (you'll see lot's of PPID=1). But this all has nothing to do with changing the CMD column of the ps output from inside a running process. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] Open 6.4 items
Matthew N. Dodd <winter@jurai.net> — 1998-10-29T16:43:59Z
On Thu, 29 Oct 1998, Jan Wieck wrote: > > On Thu, 29 Oct 1998, The Hermit Hacker wrote: > > > Solaris just doesn't have any mechanisms to work around the > > > limitation, I guess *shrug* It really sucks when you want to SIGHUP > > > the "parent process", which, under FreeBSD at least, is the one that > > > states: -accepting connections, but under Solaris they are *all* the > > > same :) > > > > $ ps -eaf > > UID PID PPID C STIME TTY TIME CMD > > root 0 0 0 Oct 12 ? 0:01 sched > > root 1 0 0 Oct 12 ? 0:15 /etc/init - > > ... > > > > You'll note the 'PPID' field. > > > > 3 guesses what that stands for. > > > > Don't see how this is related to the topic - sorry. I really have to start explaining things using more words don't I. > PPID is the parent process ID. sched has no parent (it's a > kernel pseudo process) and init has sched as father. For all > other processes the PPID is set to init's PID at the time > their father dies (you'll see lot's of PPID=1). Reread the bit of text I quoted. Read my reply. How does my reply address the problem scrappy had? The bits of ps output I quoted were only serving to demonstrate actual data produced by the ps command I used. The actual commands weren't important, only the PID and PPID fields were. > But this all has nothing to do with changing the CMD column > of the ps output from inside a running process. No, but changing the CMD column is only eye-candy. Its not necessary to be able to tell which processes are children and which is the parent. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
-
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-29T17:24:06Z
On Thu, 29 Oct 1998, Matthew N. Dodd wrote: > On Thu, 29 Oct 1998, The Hermit Hacker wrote: > > Solaris just doesn't have any mechanisms to work around the > > limitation, I guess *shrug* It really sucks when you want to SIGHUP > > the "parent process", which, under FreeBSD at least, is the one that > > states: -accepting connections, but under Solaris they are *all* the > > same :) > > $ ps -eaf > UID PID PPID C STIME TTY TIME CMD > root 0 0 0 Oct 12 ? 0:01 sched > root 1 0 0 Oct 12 ? 0:15 /etc/init - > ... > > You'll note the 'PPID' field. > > 3 guesses what that stands for. Okay, now you risk getting on my bad side :) I know what PPID stands for...now you tell me which of these processes to SIGHUP: root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail And ya, I know, the one with the older date...the point is that you can't really automate this, except to do: kill -HUP `ps -aef | grep sendmail | awk '{print $2}'` And SIGHUP them all... -
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-29T17:26:23Z
On Thu, 29 Oct 1998, Jan Wieck wrote: > > > > On Thu, 29 Oct 1998, The Hermit Hacker wrote: > > > Solaris just doesn't have any mechanisms to work around the > > > limitation, I guess *shrug* It really sucks when you want to SIGHUP > > > the "parent process", which, under FreeBSD at least, is the one that > > > states: -accepting connections, but under Solaris they are *all* the > > > same :) > > > > $ ps -eaf > > UID PID PPID C STIME TTY TIME CMD > > root 0 0 0 Oct 12 ? 0:01 sched > > root 1 0 0 Oct 12 ? 0:15 /etc/init - > > ... > > > > You'll note the 'PPID' field. > > > > 3 guesses what that stands for. > > > > Don't see how this is related to the topic - sorry. > > PPID is the parent process ID. sched has no parent (it's a > kernel pseudo process) and init has sched as father. For all > other processes the PPID is set to init's PID at the time > their father dies (you'll see lot's of PPID=1). > > But this all has nothing to do with changing the CMD column > of the ps output from inside a running process. In Matthew's defence, I think the point he was trying to bring across was that you should be able to look at hte PPID. sendmail, when you start, tends to list its PPID as '1'...but, as I showed in my last email, that doesn't appear to be "unique"... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
RE: [HACKERS] Open 6.4 items
Taral <taral@mail.utexas.edu> — 1998-10-29T17:36:02Z
> root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail Er... if you have this, you have a problem. This means there are TWO sendmail daemons running... There should only be ONE with a ppid of 1. It looks like 18948 is blah. Taral
-
Re: [HACKERS] Open 6.4 items
Matthew N. Dodd <winter@jurai.net> — 1998-10-29T17:40:26Z
On Thu, 29 Oct 1998, The Hermit Hacker wrote: > Okay, now you risk getting on my bad side :) I know what PPID > stands for...now you tell me which of these processes to SIGHUP: > > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail 2 open connections. > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail a local delivery spawned by an open connection that closed and left the local delivery to finish, thus orphaning it to init (PID1) > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail The listener. > And ya, I know, the one with the older date...the point is that > you can't really automate this, except to do: You're trying to kill the listener? You do know you can use truss and lsof to figure this out as well right? Or you could do: kill -HUP `head -1 /var/run/sendmail.pid` Also, check out what the BSD style ps shows under Solaris (/usr/ucb/ps). -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
-
RE: [HACKERS] Open 6.4 items
Matthew N. Dodd <winter@jurai.net> — 1998-10-29T17:43:18Z
On Thu, 29 Oct 1998, Taral wrote: > > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail > > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail > > Er... if you have this, you have a problem. This means there are TWO > sendmail daemons running... There should only be ONE with a ppid of 1. It > looks like 18948 is blah. No, it looks like there are 4 sendmail daemons running. The issue is to determine what each of them are doing. daemon != listener -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? |
-
Re: [HACKERS] Open 6.4 items
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-10-29T18:17:59Z
> I really have to start explaining things using more words don't I. Only if you want anyone to bother paying attention to you. - Thomas (who didn't) -
RE: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-30T02:02:42Z
On Thu, 29 Oct 1998, Taral wrote: > > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail > > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail > > Er... if you have this, you have a problem. This means there are TWO > sendmail daemons running... There should only be ONE with a ppid of 1. It > looks like 18948 is blah. Good guess, but that is normal behaviour, at least under Solaris :) It took me several 'ps -aef's to actually find it duplicated, it isn't always there. Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] Open 6.4 items
Marc G. Fournier <scrappy@hub.org> — 1998-10-30T02:06:25Z
On Thu, 29 Oct 1998, Matthew N. Dodd wrote: > On Thu, 29 Oct 1998, The Hermit Hacker wrote: > > Okay, now you risk getting on my bad side :) I know what PPID > > stands for...now you tell me which of these processes to SIGHUP: > > > > root 18942 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > root 18946 22213 0 13:22:03 ? 0:00 /usr/local/sbin/sendmail > > 2 open connections. > > > root 18948 1 0 13:22:04 ? 0:00 /usr/local/sbin/sendmail > > a local delivery spawned by an open connection that closed and left the > local delivery to finish, thus orphaning it to init (PID1) > > > root 22213 1 0 Oct 26 ? 1:40 /usr/local/sbin/sendmail > > The listener. > > > And ya, I know, the one with the older date...the point is that > > you can't really automate this, except to do: > > You're trying to kill the listener? > > You do know you can use truss and lsof to figure this out as well right? > > Or you could do: > > kill -HUP `head -1 /var/run/sendmail.pid` Yes, of course, but this was not the point of the whole thread...:) > Also, check out what the BSD style ps shows under Solaris (/usr/ucb/ps). No apparent difference in the output...wait, you'll take me too literally on that, eh? :) Both show the sasme information in the last field../usr/local/sbin/sendmail -bd -q1h :) Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
ORDER BY optimisations
Hannu Krosing <hannu@trust.ee> — 1998-10-30T16:38:55Z
Hallo Jan, Do I remember right that your pathes to speed up ORDER BYs (by omitting them when not needed) did not make it into 6.4 . If that is the case, are they available anywhere ? I really need them (fast) for my new project. ------------- Hannu Krosing
-
Re: [HACKERS] ORDER BY optimisations
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-30T17:19:40Z
> Hallo Jan, > > Do I remember right that your pathes to speed up ORDER BYs (by > omitting them when not needed) did not make it into 6.4 . > > If that is the case, are they available anywhere ? > > I really need them (fast) for my new project. LIMIT will probably be added to 6.4.1. Queries that use '%text%' can not use indexes because they are not anchored at the beginning. fulltextindex is in contrib for those cases. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
-
Re: [HACKERS] ORDER BY optimisations
Hannu Krosing <hannu@trust.ee> — 1998-10-31T14:53:59Z
Bruce Momjian wrote: > > > Hallo Jan, > > > > Do I remember right that your pathes to speed up ORDER BYs (by > > omitting them when not needed) did not make it into 6.4 . > > > > If that is the case, are they available anywhere ? > > > > I really need them (fast) for my new project. > > LIMIT will probably be added to 6.4.1. Actually I don't need LIMIT that much (for me using CURSOR/MOVE/FETCH is quite ok). The main benefit from LIMIT seems to be the ability of giving the (future) optimiser a hint that we actulally need only a small part of the whole query so it may be better to use an index. What I am after, is the patch that removed the redundant sort node when the access is already by an index matching the sort. > Queries that use '%text%' can not use indexes because they are not > anchored at the beginning. > fulltextindex is in contrib for those cases. It still seems a bit of a cludge, although a useful one as its usage is quite different from the use of other indexes. It also seems to be quite liberal with wasting space as it makes both an additional table _and_ an index for the words it indexes. In fact I'm currently using my own fulltext indexing scheme outside the database. I'm planning to work on including it in the pgsql backend, once I figure out how the extending of access methods works. -------------- Hannu
-
Re: [HACKERS] ORDER BY optimisations
Jan Wieck <jwieck@debis.com> — 1998-10-31T16:33:52Z
> > Hallo Jan, > > Do I remember right that your pathes to speed up ORDER BYs (by > omitting them when not needed) did not make it into 6.4 . > > If that is the case, are they available anywhere ? > > I really need them (fast) for my new project. > > ------------- > Hannu Krosing > > Yepp, it didn't made it. There where two different ones out, my and one from - hmmm - was it Tatsuo or Hinoue? My one only suppresses the final sort if 1. the plan is a Sort->IndexScan, 2. there is an ORDER BY clause, 3. the index choosen by the planner matches ALL attributes given in the ORDER BY clause (extra indexed attributes not in ORDER BY ignored), 4. and finally all sort operators are ASCENDING. There are many debugging printf()'s in the patch and I think one of them is still active while the others are commented out. You need to comment out the last one yourself after you found out that your queries are what causes it to suppress the sorts. Anyway, you said you need it fast, so here it is. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # diff -cr src.orig/backend/optimizer/plan/planner.c src/backend/optimizer/plan/planner.c *** src.orig/backend/optimizer/plan/planner.c Wed Oct 14 19:12:36 1998 --- src/backend/optimizer/plan/planner.c Wed Oct 14 23:17:08 1998 *************** *** 48,53 **** --- 48,59 ---- #include "executor/executor.h" + #include "utils/builtins.h" + #include "utils/syscache.h" + #include "access/genam.h" + #include "parser/parse_oper.h" + + static bool need_sortplan(List *sortcls, Plan *plan); static Plan *make_sortplan(List *tlist, List *sortcls, Plan *plannode); extern Plan *make_groupPlan(List **tlist, bool tuplePerGroup, List *groupClause, Plan *subplan); *************** *** 281,292 **** } else { ! if (parse->sortClause) return make_sortplan(tlist, parse->sortClause, result_plan); else return (Plan *) result_plan; } } /* --- 287,450 ---- } else { ! if (parse->sortClause && need_sortplan(parse->sortClause, result_plan)) return make_sortplan(tlist, parse->sortClause, result_plan); else return (Plan *) result_plan; } + } + + static TargetEntry * + get_matching_tle(Plan *plan, Resdom *resdom) + { + List *i; + TargetEntry *tle; + + foreach (i, plan->targetlist) { + tle = (TargetEntry *)lfirst(i); + if (tle->resdom->resno == resdom->resno) + return tle; + } + return NULL; + } + + static bool + need_sortplan(List *sortcls, Plan *plan) + { + Relation indexRel; + IndexScan *indexScan; + Oid indexId; + List *i; + HeapTuple htup; + Form_pg_index index_tup; + int key_no = 0; + + /* + printf("check if need_sortplan ... "); + */ + + if (nodeTag(plan) != T_IndexScan) { + /* + printf("not an index scan\n"); + */ + return TRUE; + } + + indexScan = (IndexScan *)plan; + + if (plan->lefttree != NULL) { + /* + printf("scan has lefttree\n"); + */ + return TRUE; + } + if (plan->righttree != NULL) { + /* + printf("scan has righttree\n"); + */ + return TRUE; + } + + if (length(indexScan->indxid) != 1) { + /* + printf("scanning multiple indices\n"); + */ + return TRUE; + } + + if (length(sortcls) > 8) { + /* + printf("sort clause too long (>8)\n"); + */ + return TRUE; + } + + indexId = lfirsti(indexScan->indxid); + + indexRel = index_open(indexId); + if (strcmp(nameout(&(indexRel->rd_am->amname)), "btree") != 0) { + /* + printf("not a btree index\n"); + */ + heap_close(indexRel); + return TRUE; + } + heap_close(indexRel); + + htup = SearchSysCacheTuple(INDEXRELID, + ObjectIdGetDatum(indexId), 0, 0, 0); + if (!HeapTupleIsValid(htup)) { + elog(ERROR, "cache lookup for index %d failed", indexId); + } + index_tup = (Form_pg_index) GETSTRUCT(htup); + + foreach (i, sortcls) { + SortClause *sortcl; + Resdom *resdom; + TargetEntry *tle; + Var *var; + + sortcl = (SortClause *) lfirst(i); + + /* + printf("\nchecking sortclause %s\n", nodeToString(sortcl)); + */ + + resdom = sortcl->resdom; + tle = get_matching_tle(plan, resdom); + if (tle == NULL) { + /* + printf("matching target entry not found\n"); + */ + return TRUE; + } + if (nodeTag(tle->expr) != T_Var) { + /* + printf("target entry not a Var\n"); + */ + return TRUE; + } + var = (Var *)(tle->expr); + + if (var->varno != indexScan->scan.scanrelid) { + /* + printf("Var not from scanrelid\n"); + */ + return TRUE; + } + + if (var->varattno != index_tup->indkey[key_no]) { + /* + printf("attribute sorted does not match indexed att\n"); + */ + return TRUE; + } + + if (oprid(oper("<", resdom->restype, resdom->restype, FALSE)) != sortcl->opoid) { + /* + printf("opoid should be %d - is %d\n", + oprid(oper("<", resdom->restype, resdom->restype, FALSE)), sortcl->opoid); + */ + return TRUE; + } + + key_no++; + } + if (key_no < 8 && index_tup->indkey[key_no] != 0) { + /* + printf("there are more indexed fields! "); + */ + return TRUE; + } + + printf("SUPPRESSING sort over index scan\n"); + + /* + printf("scan = %s\n\n", nodeToString(indexScan)); + */ + + return FALSE; } /* -
Re: [HACKERS] ORDER BY optimisations
Jan Wieck <jwieck@debis.com> — 1998-10-31T17:07:04Z
> 1. the plan is a Sort->IndexScan, > > 2. there is an ORDER BY clause, > > 3. the index choosen by the planner matches ALL attributes > given in the ORDER BY clause (extra indexed attributes > not in ORDER BY ignored), Ooops - sorry. Took another look at the patch and saw, that it actually does not ignore extra attributes in the index. Maybe you want to force sort suppression then too and comment out the 'return TRUE' for this case. BTW: This or an enhanced version (suppressing more stupid sort cases) is my first candidate for the v6.4.1 feature patch. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #