Re: [HACKERS] Quite strange crash
Well, it's not good idea because of SIGTERM is used for ABORT + EXIT (pg_ctl -m fast stop), but shouldn't ABORT clean up everything? Er, shouldn't ABORT leave the system in the exact state that it's in so that one can get a crashdump/traceback on a wedged process without it trying to clean up after itself? Sorry, I've meant "transaction abort"... Vadim
[HACKERS] tinterval - operator problems on AIX
On AIX timestamp and horology regression fails in current, because timestamp - interval for result timestamps that are before 1970 (epoch ?) are off by one hour. I think this is not an issue for an adapted expected file, but a new (in 7.1beta) bug. But I am at no means an expert at what the result should be when substracting 34 years from epoch or 'Mon Dec 30 17:32:01 1996 PST'. Andreas regression.diffs
Re: [HACKERS] bit_length()
Added to TODO: * Add SQL standard function bit_length() It seems we do not have the standard SQL function "bit_length()"? -- Tatsuo Ishii -- 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
Re: [HACKERS] Well, we seem to be proof against cache-inval problemsnow
Can this now be marked as done?
* Modification of pg_class can happen while table in use by another
backend. Might lead to MVCC inside of syscache
I just finished running the parallel regress tests with inval.c rigged
to flush the relcache and syscache at every available opportunity,
that is anytime we could recognize a shared-cache-inval message from
another backend (see diff below). This setup gives a whole new universe
of meaning to the word "slow" --- it took *three full days* to run the
standard "make check" procedure, including eighteen hours just to do the
"vacuum template1" part of initdb. I kid you not. But it worked.
Looks like the unexpected-cache-entry-drop class of problems are indeed
gone.
BTW, the reason the diff is rigged not to allow recursive cache flush
is not that it wouldn't work, it's that I didn't expect to live long
enough to finish such a test. I didn't originally have that restriction
in there (and indeed found a bug that way: relcache flush could go into
an infinite loop if hit with another SI inval before it'd finished the
initial flush). After fixing that bug, initdb was making steady
progress, but not at a rate that I wanted to wait out...
regards, tom lane
*** src/backend/utils/cache/inval.c.orig Wed Nov 15 23:57:44 2000
--- src/backend/utils/cache/inval.c Mon Jan 1 17:27:53 2001
***
*** 643,649
--- 643,661
elog(DEBUG, "DiscardInvalid called");
#endif /* defined(INVALIDDEBUG) */
+ #if 1
+ /* DEBUG CHECK ONLY ... force cache reset at any opportunity */
+ static bool inReset = false;
+
+ if (! IsBootstrapProcessingMode() !inReset)
+ {
+ inReset = true;
+ ResetSystemCaches();
+ inReset = false;
+ }
+ #else
InvalidateSharedInvalid(CacheIdInvalidate, ResetSystemCaches);
+ #endif
}
/*
--
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
Re: [PATCHES] Re: [HACKERS] Recursion and SPI
Applied. Thanks. "Mikheev, Vadim" [EMAIL PROTECTED] writes: Does the SPI interface support recursion? That is, can a function use SPI to make a query which involves calling another function which uses SPI? From http://www.postgresql.org/docs/programmer/spi.htm : "SPI procedures are always called by some (upper) Executor and the SPI manager uses the Executor to run your queries. Other procedures may be called by the ^^ Executor running queries from your procedure." The documentation suggests not, saying that if a function which uses SPI calls another function which uses SPI, it won't work, and calling that ``bad practice.'' From http://www.postgresql.org/docs/programmer/spi-spiconnect.htm : "You may get SPI_ERROR_CONNECT error if SPI_connect is called from an already connected procedure - e.g. if you *directly call* one procedure from another ^^^ connected one. Actually, while the child procedure will be able to use SPI, your parent procedure will not be able to continue to use SPI after the child returns (if SPI_finish is called by the child). It's bad practice." But you are able to run queries which call SPI functions. Thanks for the clarification. Approaching the current documentation from a position of ignorance, I find it ambiguous. I propose something along the lines of the following patch to clarify it. Thanks. (Alternatively, perhaps the code could maintain a count of nested calls to SPI_connect/SPI_finish. But I didn't try to write that patch.) Ian Index: spi.sgml === RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/spi.sgml,v retrieving revision 1.8 diff -u -r1.8 spi.sgml --- spi.sgml 2000/12/22 18:57:50 1.8 +++ spi.sgml 2001/01/05 22:10:13 @@ -34,10 +34,11 @@ /Para Para -AcronymSPI/Acronym procedures are always called by some (upper) -Executor and the AcronymSPI/Acronym -manager uses the Executor to run your queries. Other procedures may be -called by the Executor running queries from your procedure. +Procedures which use AcronymSPI/Acronym are called by the +Executor. The AcronymSPI/Acronym calls recursively invoke the +Executor in turn to run queries. When the Executor is invoked +recursively, it may itself call procedures which may make +AcronymSPI/Acronym calls. /Para Para @@ -146,12 +147,17 @@ utility SPI functions may be called from un-connected procedures. /PARA PARA - You may get ReturnValueSPI_ERROR_CONNECT/ReturnValue error if FunctionSPI_connect/Function is - called from an already connected procedure - e.g. if you directly call one - procedure from another connected one. Actually, while the child procedure - will be able to use SPI, your parent procedure will not be able to continue - to use SPI after the child returns (if FunctionSPI_finish/Function is called by the child). - It's bad practice. + If your procedure is already connected, + FunctionSPI_connect/Function will return an + ReturnValueSPI_ERROR_CONNECT/ReturnValue error. Note that this + may happen if a procedure which has called + FunctionSPI_connect/Function directly calls another procedure + which itself calls FunctionSPI_connect/Function. While + recursive calls to the AcronymSPI/Acronym manager are permitted + when an AcronymSPI/Acronym query invokes another function which + uses AcronymSPI/Acronym, directly nested calls to + FunctionSPI_connect/Function and + FunctionSPI_finish/Function are forbidden. /PARA /REFSECT1 REFSECT1 ID="R1-SPI-SPICONNECT-2" -- 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
Re: [HACKERS] pg_dump return status..
There are two versions of sprintf() available in SunOS 4 - 8. The standard one (ANSI C) in libc returns an int, the number of characters written (excluding '\0'). The BSD version returns a char* which points to the target. If you have a -lbsd on your link line then you get the BSD version. There are no compiler errors, just run time errors if you rely on the return from sprintf() being the number of characters. The workaround is to put an extra -lc on the link line before the -lbsd if your code needs both standard sprintf() and some other BSD function. Ultrix is documented as having the same behaviour as Solaris. I don't know about NeXTSTEP/OPENSTEP/GNUStep. Of course, if sprintf() returns an error, you have pretty big problems. :-) -- 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
Re: [HACKERS] Re: [SQL] PostgreSQL web page
On Tue, 9 Jan 2001, The Hermit Hacker wrote: On Tue, 9 Jan 2001, Kaare Rasmussen wrote: I wonder why http://www.postgresql.org is not updated with news. The latest "Latest News" is from Nov 16. I have to go to http://www.pgsql.com to find some interesting news later than that: 2000-12-22 PostgreSQL, Inc. Releases Open Source Replication Database and2000-12-12 2000 Linux Journal Editor's Choice Award for Best Database In fact I was looking for the Replication server. No mention seems to be available on postgresql.org. Also the mailing list archive for pgsql-sql is not listed here: http://www.postgresql.org/devel-corner/index.html - but you can see it if you write the correct URL yourself. I have no graphical browser right now, and lynx isn't installed, so I'm a bit at a disadvantage here ... but, pgsql-sql *should* be listed under users-gallery, not devel ... devel is -hackers, -bugs, -ports, etc ... Unless the clock on hub was wrong, I have the award happening on 11/16/Y2K. The replication server info was a press release by PostgreSQL, Inc. Not the PostgreSQL Global Development Group. Between GB and PG,Inc with the constant barrage of press releases I made the decision months ago that NO press releases from ANY group would be posted on the PostgreSQL website - these groups have their own websites for that and PostgreSQL.org doesn't need to be caught up in the middle. pgsql-sql is in the users section - both info and archives. Beyond that, the web site is maintained by Vince ... but I thought the Award was definitely up there already ... Both on the main page and in latest news. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com ==
Re: [HACKERS] patch: contrib/pgcrypto sanity
Applied. Thanks. [ Charset ISO-8859-1 unsupported, converting... ] The KAME files md5.* and sha1.* have the following changelog entry: revision 1.2 date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18 Eliminate some of the more blatant platform-dependencies ... it builds here now, anyway ... Which basically changes u_int*_t - uint*_t, so now it does not compile neither under Debian 2.2 nor under NetBSD 1.5 which is platform independent? all right. Also it replaces $KAME$ with $Id$ which is Bad Thing. PostgreSQL Id should be added as a separate line so the file history could be seen. So here is patch: * changes uint*_t - uint*. I guess that was the original intention * adds uint64 type to include/c.h because its needed [somebody should check if I did it right] * adds back KAME Id, because KAME is the master repository * removes stupid c++ comments in pgcrypto.c * removes sys/types.h from the code, its not needed -- marko [ Attachment, skipping... ] -- 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
Re: [HACKERS] README.mb
Tatsuo Ishii [EMAIL PROTECTED] writes: I think doc/REAME.mb is now deprecated and I would like to remove it. Also I would like to place the Chinese (Big5) version of README.mb recently posted by Chih-Chang Hsieh [EMAIL PROTECTED] as doc/README.mb.big5. Go for it. I was surprised you hadn't done so already. I kind of got stuck on how to deal with the Big5 file. Glad Tatsuo is handling it. -- 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
AW: [HACKERS] Re: tinterval - operator problems on AIX
On AIX timestamp and horology regression fails in current, because timestamp - interval for result timestamps that are before 1970 (epoch ?) are off by one hour. I think this is not an issue for an adapted expected file, but a new (in 7.1beta) bug. But I am at no means an expert at what the result should be when substracting 34 years from epoch or 'Mon Dec 30 17:32:01 1996 PST'. Hi Andreas. It is certainly true that the behavior has changed for the new release, but afaik it can not be put into the "bug" category. The difference is that, before, I rotated date/time into the correct time zone for arithmetic by adding/subtracting the current time zone. For (date/time)-(interval), this resulted in evaluating the result in the same time zone as the starting date/time, which was not correct. The time zone is now evaluated in the time zone of the result, rather than the input, using system support routines from libc. But that will expose troubles on some platforms with time zone support before 1970. Some platforms are worse than others; my experience has been that zinc-based systems such as Linux, FreeBSD, and Tru64 are pretty good, Suns are the best, and, well, apparently AIX is not ;) What I do not understand is, that I thought a time in december cannot be affected by such math because it is clearly not in the daylight savings months of the year ? Also I thought that you recognize daylight savings time by the PDT instead of PST, and PostgreSQL shows a result with PST as I would have expected, but one hour off. e.g.: Mon Dec 30 17:32:01 1996 PST - @ 34 years -- Sun Dec 30 16:32:01 1962 PST How do we go about resolving this ? I hesitate to mark a bogus result "ok". Andreas
Re: AW: [HACKERS] Re: tinterval - operator problems on AIX
What I do not understand is, that I thought a time in december cannot be affected by such math because it is clearly not in the daylight savings months of the year ? Also I thought that you recognize daylight savings time by the PDT instead of PST, and PostgreSQL shows a result with PST as I would have expected, but one hour off. By the time the math is actually done, the date is in GMT. So the issue is: how does one assign the time zone for the result? Or more properly, how does one account for time zone shifts (e.g. Daylight time vs Standard time) when doing date/time arithmetic? The previous scheme rotated the date/time by the same amount as the original date input. The current scheme uses your system's date/time support functions to deduce the correct time zone and DST setting once the math is complete. In principle, this gives your system the opportunity to come up with the correct answer, where previously the answer was not what might be expected for any platform. e.g.: Mon Dec 30 17:32:01 1996 PST - @ 34 years -- Sun Dec 30 16:32:01 1962 PST How do we go about resolving this ? I hesitate to mark a bogus result "ok". The result must be what the AIX developers want ;) I've made some assumptions in this conversation: 1) Some platforms, Linux included, give "correct results". I think I checked this thoroughly, but, well, you know how that goes sometimes... 2) You are diff'ing the current "expected" against current "results", and not a previous version of "expected". 3) Some platforms do not do the right thing wrt time zones for dates before 1970. For example, the USA had some weird time zones during WWII, and this is reflected in Sun's time zone database but not quite as accurately in the open source zinc package that Linux and others use. And other platforms (such as AIX?) prefer to do it themselves and get it wrong altogether. - Thomas
Re: [HACKERS] Quite strange crash
[EMAIL PROTECTED] (Nathan Myers) writes: The relevance to the issue at hand is that processes dying during heavy memory load is a documented feature of our supported platforms. Ugh. Do you know anything about *how* they get killed --- ie, with what signal? regards, tom lane
Re: [HACKERS] Well, we seem to be proof against cache-inval problems now
Bruce Momjian [EMAIL PROTECTED] writes: Can this now be marked as done? * Modification of pg_class can happen while table in use by another backend. Might lead to MVCC inside of syscache I'm not sure. Do you have any record of what the concern was, in detail? I don't understand what the TODO item is trying to say. regards, tom lane
Re: [HACKERS] Well, we seem to be proof against cache-inval problemsnow
Bruce Momjian [EMAIL PROTECTED] writes: Can this now be marked as done? * Modification of pg_class can happen while table in use by another backend. Might lead to MVCC inside of syscache I'm not sure. Do you have any record of what the concern was, in detail? I don't understand what the TODO item is trying to say. I assumed it was the problem of table lookups with no locking. No idea what the MVCC mention is about. -- 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
Re: [HACKERS] Quite strange crash
Denis Perchine [EMAIL PROTECTED] writes: Didn't you get my mail with a piece of Linux kernel code? I think all is clear there. That was implementing CPU-time-exceeded kill, which is a different issue. regards, tom lane
Re: [HACKERS] Quite strange crash
Didn't you get my mail with a piece of Linux kernel code? I think all is
clear there.
That was implementing CPU-time-exceeded kill, which is a different
issue.
Opps.. You are talking about OOM killer.
/* This process has hardware access, be more careful. */
if (cap_t(p-cap_effective) CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}
You will get SIGKILL in most cases.
--
Sincerely Yours,
Denis Perchine
--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
RE: [HACKERS] Quite strange crash
START_/END_CRIT_SECTION is mostly CritSectionCount++/--. Recording could be made as LockedSpinLocks[LockedSpinCounter++] = spinlock in pre-allocated array. Yeah, I suppose. We already do record locking of all the fixed spinlocks (BufMgrLock etc), it's just the per-buffer spinlocks that are missing from that (and CRIT_SECTION calls). Would it be reasonable to assume that only one buffer spinlock could be held at a time? No. UPDATE holds two spins, btree split even more. But stop - afair bufmgr remembers locked buffers, probably we could just add XXX_CRIT_SECTION to LockBuffer..? Vadim
Re: [HACKERS] Quite strange crash
"Mikheev, Vadim" [EMAIL PROTECTED] writes: Yeah, I suppose. We already do record locking of all the fixed spinlocks (BufMgrLock etc), it's just the per-buffer spinlocks that are missing from that (and CRIT_SECTION calls). Would it be reasonable to assume that only one buffer spinlock could be held at a time? No. UPDATE holds two spins, btree split even more. But stop - afair bufmgr remembers locked buffers, probably we could just add XXX_CRIT_SECTION to LockBuffer..? Right. A buffer lock isn't a spinlock, ie, we don't hold the spinlock except within LockBuffer. So a quick CRIT_SECTION should deal with that. Actually, with careful placement of CRIT_SECTION calls in LockBuffer, there's no need to record holding the buffer's cntxt spinlock at all, I think. Will work on it. regards, tom lane
Re: [HACKERS] Quite strange crash
Denis Perchine [EMAIL PROTECTED] writes: You will get SIGKILL in most cases. Well, a SIGKILL will cause the postmaster to shut down and restart the other backends, so we should be safe if that happens. (Annoyed as heck, maybe, but safe.) Anyway, this is looking more and more like the SIGTERM that caused your vacuum to die must have been done manually. The CRIT_SECTION code that I'm about to go off and add to spinlocking should prevent similar problems from happening in 7.1, but I don't think it's reasonable to try to retrofit that into 7.0.*. regards, tom lane
Re: [HACKERS] Quite strange crash
On Wed, Jan 10, 2001 at 12:46:50AM +0600, Denis Perchine wrote:
Didn't you get my mail with a piece of Linux kernel code? I think all is
clear there.
That was implementing CPU-time-exceeded kill, which is a different
issue.
Opps.. You are talking about OOM killer.
/* This process has hardware access, be more careful. */
if (cap_t(p-cap_effective) CAP_TO_MASK(CAP_SYS_RAWIO)) {
force_sig(SIGTERM, p);
} else {
force_sig(SIGKILL, p);
}
You will get SIGKILL in most cases.
... on Linux, anyhow. There's no standard for this behavior.
Probably others try a SIGTERM first (on several processes) and
then a SIGKILL if none die.
If a backend dies while holding a lock, doesn't that imply that
the shared memory may be in an inconsistent state? Surely a death
while holding a lock should shut down the whole database, without
writing anything to disk.
Nathan Myers
[EMAIL PROTECTED]
Re: [HACKERS] Quite strange crash
[EMAIL PROTECTED] (Nathan Myers) writes: If a backend dies while holding a lock, doesn't that imply that the shared memory may be in an inconsistent state? Yup. I had just come to the realization that we'd be best off to treat the *entire* period from SpinAcquire to SpinRelease as a critical section for the purposes of die(). That is, response to SIGTERM will be held off until we have released the spinlock. Most of the places where we grab spinlocks would have to make such a critical section anyway, at least for large parts of the time that they are holding the spinlock, because they are manipulating shared data structures and the instantaneous intermediate states aren't always self-consistent. So we might as well follow the KISS principle and just do START_CRIT_SECTION in SpinAcquire and END_CRIT_SECTION in SpinRelease. Vadim, any objection? regards, tom lane
RE: [HACKERS] Quite strange crash
Yup. I had just come to the realization that we'd be best off to treat the *entire* period from SpinAcquire to SpinRelease as a critical section for the purposes of die(). That is, response to SIGTERM will be held off until we have released the spinlock. Most of the places where we grab spinlocks would have to make such a critical section anyway, at least for large parts of the time that they are holding the spinlock, because they are manipulating shared data structures and the instantaneous intermediate states aren't always self-consistent. So we might as well follow the KISS principle and just do START_CRIT_SECTION in SpinAcquire and END_CRIT_SECTION in SpinRelease. Vadim, any objection? No one for the moment. If we'll just add XXX_CRIT_SECTION to SpinXXX funcs without changing anything else then it will be easy to remove them later (in the event we'll find any problems with this), so - do it. Vadim
Re: [HACKERS] Re: Beta2 ... ?
On Fri, 5 Jan 2001, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... FWIW: We would definately beta test 7.1 beta releases on our test machines if RPMS were made available. However, if rpms are not made available, its unlikely that anyone around here will get time to build the sources from scratch. So you can count me as one beta tester that you would have if you made RPMS of the betas. Regards, Mike
[HACKERS] BETWEEN [SYMMETRIC | ASYMMETRIC]
Here is current cvs: SELECT 2 BETWEEN 1 AND 3; ?column? -- t (1 row) subselects=# SELECT 2 BETWEEN 3 AND 1; ?column? -- f (1 row) Any chance of BETWEEN [SYMMETRIC | ASYMMETRIC] being implemented? SELECT 2 BETWEEN SYMMETRIC 3 AND 1; ?column? -- t (1 row) ASYMMETRIC is the default and what is currently the case. This would probably be easy TODO. -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [HACKERS] Re: Beta2 ... ?
Michael J Schout wrote: We would definately beta test 7.1 beta releases on our test machines if RPMS were made available. However, if rpms are not made available, its unlikely that anyone around here will get time to build the sources from scratch. So you can count me as one beta tester that you would have if you made RPMS of the betas. Your offer is appreciated, and will most definitely be taken :-). I'm experiencing some degree of difficulty with the build -- mostly due to some reorg in the Perl and Python clients, but also some main Make framework as well, thanks to the RPM build-root environment. The compiles I have done outside the RPM environment have worked and installed (as source installs) very cleanly -- but the RPM build-root environment is rather different -- installing files to a location where they won't actually be installed to :-). Let me explain: so that RPM builders don't accidentally trash their systems during building, RPM includes a 'build-root' mechanism that allows a fake root for the build install to be used instead of the real root. Think 'chroot-lite'. This build-root is not enforced anywhere except by the spec file build and install sections. This also allows RPMs to be built for root installation by a non-root user, which provides an extra layer of filesystem protection. So, files get installed to this build-root, for eventual real installation on the real root when the RPM is actually installed. However, there are some hard-coded paths left in the build, and the perl client is being difficult, and odbcinst is going to the REAL /usr/etc instead of $RPM_BUILD_ROOT/etc I have lots of combing to do. In many ways 7.1 is an easier build -- but not in this regard. But I consider this an RPM issue and not a PostgreSQL tarball issue, meaning, while I will be developing patches for the RPM build, I won't expect those to be integrated into the main tarball. So, I'm plugging at it -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] How to print explain using PHP
I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with PHP, to the postgres backend the output goes to the error_log file of apache and I don't know how to redirect that output to the browser. Does anyone know how I can do this? Saludos... ;-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] How to print explain using PHP
On Tue, 9 Jan 2001, Martin A. Marques wrote: I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with PHP, to the postgres backend the output goes to the error_log file of apache and I don't know how to redirect that output to the browser. Good point, before some time somebody (Bruce?) ask if anything is needful add to PostgreSQL extension in PHP. You found that... PHP not support libpq's routine: PQnoticeProcessor PQsetNoticeProcessor( PGconn *conn, PQnoticeProcessor proc, void *arg); Karel
[GENERAL] Re: How to print explain using PHP
El Mar 09 Ene 2001 16:30, Karel Zak escribi: On Tue, 9 Jan 2001, Martin A. Marques wrote: I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with PHP, to the postgres backend the output goes to the error_log file of apache and I don't know how to redirect that output to the browser. Good point, before some time somebody (Bruce?) ask if anything is needful add to PostgreSQL extension in PHP. You found that... PHP not support libpq's routine: PQnoticeProcessor PQsetNoticeProcessor( PGconn *conn, PQnoticeProcessor proc, void *arg); I think it would be of great help for web programers that use postgres. Any way, I'm doing some messy things to get what I want, but it is a very needfull extension. Saludos... :-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
[GENERAL] Re: [HACKERS] How to print explain using PHP
I think the issue here was that these functions don't make any sense for PHP because you can't register C functions. On Tue, 9 Jan 2001, Martin A. Marques wrote: I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with PHP, to the postgres backend the output goes to the error_log file of apache and I don't know how to redirect that output to the browser. Good point, before some time somebody (Bruce?) ask if anything is needful add to PostgreSQL extension in PHP. You found that... PHP not support libpq's routine: PQnoticeProcessor PQsetNoticeProcessor( PGconn *conn, PQnoticeProcessor proc, void *arg); Karel -- 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
Re: [HACKERS] How to print explain using PHP
On Tue, 9 Jan 2001, Bruce Momjian wrote: I think the issue here was that these functions don't make any sense for PHP because you can't register C functions. I mean (I know) that you can register some common (internal) PHP function and this function can call your PHP function. It is some used in XML Expat parser that use element handlers (functions). It's very good resolvable in PHP... see php-4.0b3/ext/xml/xml.c as example Karel On Tue, 9 Jan 2001, Martin A. Marques wrote: I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with PHP, to the postgres backend the output goes to the error_log file of apache and I don't know how to redirect that output to the browser. Good point, before some time somebody (Bruce?) ask if anything is needful add to PostgreSQL extension in PHP. You found that... PHP not support libpq's routine: PQnoticeProcessor PQsetNoticeProcessor( PGconn *conn, PQnoticeProcessor proc, void *arg); Karel -- 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
[GENERAL] Re: [HACKERS] How to print explain using PHP
On Tue, 9 Jan 2001, Bruce Momjian wrote: I think the issue here was that these functions don't make any sense for PHP because you can't register C functions. I mean (I know) that you can register some common (internal) PHP function and this function can call your PHP function. It is some used in XML Expat parser that use element handlers (functions). It's very good resolvable in PHP... see php-4.0b3/ext/xml/xml.c as example OK, this is why I never added it to the TODO list. Should we add this to our TODO list? -- 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
[GENERAL] Re: [HACKERS] How to print explain using PHP
On Tue, 9 Jan 2001, Bruce Momjian wrote: On Tue, 9 Jan 2001, Bruce Momjian wrote: I think the issue here was that these functions don't make any sense for PHP because you can't register C functions. I mean (I know) that you can register some common (internal) PHP function and this function can call your PHP function. It is some used in XML Expat parser that use element handlers (functions). It's very good resolvable in PHP... see php-4.0b3/ext/xml/xml.c as example OK, this is why I never added it to the TODO list. Should we add this to our TODO list? Quick look to PHP:-) libphp/zend_execute_API.c: call_user_function() Karel
[HACKERS] SIMILAR TO for regular expressions
Anyone read the [NOT] SIMILAR TO syntax for regular expressions? Looks like it might be close to an SQL standard synonym for [!]~. I don't know if it can match the case insensitive ops though. -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [HACKERS] BETWEEN [SYMMETRIC | ASYMMETRIC]
"Robert B. Easter" [EMAIL PROTECTED] writes: subselects=# SELECT 2 BETWEEN 3 AND 1; ?column? -- f (1 row) SQL92 quoth: 6) "X BETWEEN Y AND Z" is equivalent to "X=Y AND X=Z". so this is correct behavior, even if it might seem surprising. Any chance of BETWEEN [SYMMETRIC | ASYMMETRIC] being implemented? SELECT 2 BETWEEN SYMMETRIC 3 AND 1; ?column? -- t (1 row) Build a function based on this idea: regression-# select case regression-# when 3 1 then 2 between 3 and 1 regression-# else 2 between 1 and 3 regression-# end; case -- t (1 row) I don't really see this as important enough to justify introducing a nonstandard syntax for it... regards, tom lane
Re: [HACKERS] BETWEEN [SYMMETRIC | ASYMMETRIC]
I don't really see this as important enough to justify introducing a nonstandard syntax for it... regards, tom lane Sorry to quote like this, it makes me feel like a real nerd. :) This quote from the SQL standard (1999) has it: 8.3 between predicate Function Specify a range comparison. Format between predicate ::= row value expression [ NOT ] BETWEEN [ ASYMMETRIC | SYMMETRIC ] row value expression AND row value expression Syntax Rules 1) If neither SYMMETRIC nor ASYMMETRIC is specified, then ASYMMETRIC is implicit. 2) Let X, Y, and Z be the first, second, and third row value expressions, respectively. 3) "X NOT BETWEEN SYMMETRIC Y AND Z" is equivalent to "NOT ( X BETWEEN SYMMETRIC Y AND Z )". 4) "X BETWEEN SYMMETRIC Y AND Z" is equivalent to "((X BETWEEN ASYMMETRIC Y AND Z) OR (X BETWEEN ASYMMETRIC Z AND Y))". 5) "X NOT BETWEEN ASYMMETRIC Y AND Z" is equivalent to "NOT ( X BETWEEN ASYMMETRIC Y AND Z )". 6) "X BETWEEN ASYMMETRIC Y AND Z" is equivalent to "X=Y AND X=Z". Access Rules None. General Rules None. Conformance Rules 1) Without Feature T461, "Symmetric between predicate", conforming SQL language shall not specify SYMMETRIC or ASYMMETRIC. 2) Without Feature S024, "Enhanced structured types", no subfield of the declared type of a row value expression that is simply contained in a between predicate shall be of a structured type. -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
Re: [GENERAL] Re: [HACKERS] How to print explain using PHP
On Tue, 9 Jan 2001, Bruce Momjian wrote: I think the issue here was that these functions don't make any sense for PHP because you can't register C functions. I mean (I know) that you can register some common (internal) PHP function and this function can call your PHP function. It is some used in XML Expat parser that use element handlers (functions). It's very good resolvable in PHP... see php-4.0b3/ext/xml/xml.c as example IMHO it would be confusing for PHP users. What about changing the PHP function php_pgsql_do_connect so that it calls PQsetNoticeProcessor to preserve the last NOTIFY string somewhere. And we would invent new PHP function pg_notifymessage (or whatever) to extract the string later on. OK, this is why I never added it to the TODO list. Should we add this to our TODO list? I don't think so, if the TODO should only include things to do with the PostgreSQL source code. -- Tatsuo Ishii
Re: [HACKERS] Well, we seem to be proof against cache-inval problemsnow
No? :-) Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Can this now be marked as done? * Modification of pg_class can happen while table in use by another backend. Might lead to MVCC inside of syscache I'm not sure. Do you have any record of what the concern was, in detail? I don't understand what the TODO item is trying to say. I assumed it was the problem of table lookups with no locking. No idea what the MVCC mention is about. I checked the CVS archives and found that you added that TODO item on 4-Feb-2000. I could not, however, find any relevant discussion in the pghackers archives in the first few days of February. Do you have anything archived that might help narrow it down? regards, tom lane -- 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
Re: [HACKERS] Well, we seem to be proof against cache-inval problemsnow
I barely understand the items sometimes. Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Can this now be marked as done? * Modification of pg_class can happen while table in use by another backend. Might lead to MVCC inside of syscache I'm not sure. Do you have any record of what the concern was, in detail? I don't understand what the TODO item is trying to say. I assumed it was the problem of table lookups with no locking. No idea what the MVCC mention is about. I checked the CVS archives and found that you added that TODO item on 4-Feb-2000. I could not, however, find any relevant discussion in the pghackers archives in the first few days of February. Do you have anything archived that might help narrow it down? regards, tom lane -- 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
