[HACKERS] Re: [JDBC] Open 7.1 items
Quoting Bruce Momjian [EMAIL PROTECTED]: Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug Reorder INSERT firing in rules Philip Warner UPDATE crash JDBC LargeObject short read return value missing Working on this on Saturday. SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC doesn't support cursors full stop yet. JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? No as it's obsolete in 7.1 ;-) Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Client code not calling Connection.close() method. Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux Merge global and template BKI files? Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Lookingfor . . . ]
Peter Eisentraut writes: Frank Joerdens writes: I have experienced before that Unix sockets will cause random connection abortions on Solaris [ . . . ] Isn't that _really_ bad? Random connection abortions when going over Unix sockets?? My app does _all_ the connecting over Unix sockets?! That's bad, for sure. Maybe you can check for odd conditions surrounding the /tmp directory, like is it on NFS, permission problems, mount options. Or is there something odd in the kernel configuration? If I'm counting correctly this is the third independent report of this problem, which is scary. I'm not sure if you counted me. I also observed that Unix sockets cause the parallel tests to fail in random places on Solaris. We had a similar problem porting a product that uses a lot of IPC to Solaris. There were failures involving the overloading of the Unix domain sockets. We took the code to Sun and they were unable to resolve the problems. It should have been possible to tune the kernel to provide more resources. However it turns out that some of the parameters that we wanted to tune were ignored in favour of hard coded values. In the end we rewrote our code to use Internet domain sockets (AF_INET). BTW, owing to a DNS error email to me has bounced over the last couple of days. It should be okay now if anything needs to be resent. -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Re: [HACKERS] Open 7.1 items
Hiroshi Inoue writes: What does this item mean ? Is it the following ? begin; insert into pk (id) values (1); update(delete from) pk where id=1; ERROR: triggered data change violation on relation pk" If so, isn't it a simple bug ? Depends on the definition of "bug". It's not spec compliant and it's not documented and it's annoying. But it's been like this for a year and the issue is well known and can normally be avoided. It looks like a documentation to-do to me. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
On Fri, Jan 26, 2001 at 03:29:59PM +, Patrick Welche wrote: On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote: Frank Joerdens [EMAIL PROTECTED] writes: I just did that and ran make check 4 times. 3 times went completely smoothly, once I had random fail. This is the same behaviour that I saw when running make installcheck (76 successful most of the time, sometimes you get 75 out of 76 with random being the one that fails). Er, you do realize that the random test is *supposed* to fail every so often? I do. I just included the info for completeness' sake. What troubles me is the nonrepeatable failures you saw on other tests. As Peter says, if "make installcheck" (serial tests) is perfectly solid and "make check" (parallel tests) is not, that suggests some kind of interprocess locking problem. But we haven't heard about any such issue on Solaris. Or simply running out of processes - check maxproc? (Deleted beginning of this thread, so may have missed something) There is no load at all on this server at the moment. The sysadmin and myself are currently the only people accessing a brand new UltraSPARC with 3 CPUs and 3/4 GB of RAM to install stuff. Whatever the reason for it, Peter's suggestion at least seems to mitigate the issue with the regression tests. I've set DEFAULT_PGSOCKET_DIR in src/include/config.h.in to /usr/db/pgsql/tmp (/usr/db/pgsql is the postgres user's home dir and the install dir for Postgres). Running make check after that gives: 1: none failed 2: random ... failed (ignored) 3: Oh. What's the expression (in German you'd say 'Zu frueh gefreut.') here. Now I get: select_distinct_on ... FAILED select_implicit ... FAILED random ... failed (ignored) portals ... FAILED test misc ... FAILED Typing $ ps -a I can see that 2 postgres processes are still active . . . ?? And /usr/db/pgsql/tmp does not contain any lock file??? I killed those 2 and ran make check again: 4: none failed 5: random ... failed (ignored) 6: none failed 7: random ... failed (ignored) 8: none failed 9: none failed 9: comments ... FAILED Hm. Bizarre. The issue isn't solved but it definitely looks better than before (also, the sysadmin just told me that /tmp is cleaned out nightly anyway by cron). I'm gonna test it over TCP/IP sockets again, and if that works, stick with those: When setting unix_sockets=no; for any plattform in src/test/regress/pg_regress.sh, 7 consecutive tests showed no errors. I'll just connect to the server over TCP/IP. Regards, Frank
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
Frank Joerdens [EMAIL PROTECTED] writes: Now I get: select_distinct_on ... FAILED select_implicit ... FAILED random ... failed (ignored) portals ... FAILED test misc ... FAILED Reporting a regression failure this way is pretty unhelpful. What are the actual diffs (regression.diffs)? What shows up in the postmaster log (logs/postmaster.log)? regards, tom lane
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
On Fri, Jan 26, 2001 at 05:03:13PM +0100, Frank Joerdens wrote: There is no load at all on this server at the moment. The sysadmin and myself are currently the only people accessing a brand new UltraSPARC with 3 CPUs and 3/4 GB of RAM to install stuff. Hmm, multiple processors, and lots of IPC: I've got a bad feeling about this. Nothing solid (don't do a lot with Solaris), but there are a _lot_ of gotchas in getting that combo right, many of which _kill_ performance for the normal case to get correct behavior in an edge case. I could imagine Sun missing one or two, and not catching it (or actively ignoring it, to get better CPU utilization) Since it seems to hit only when using Unix domain sockets, I'd take a wild guess that explicit use of shared memory and Unix domain sockets are stepping on each other in a multiprocessor environment. Invoking Inet sockets gets more of the networking code in play, which is usually more heavily tested in such an environment. Since it's just you and the sysadmin: any chance you could bring the system up uniprocessor (I don't even know if this is _possible_ with Sun hardware, let alone how hard) and run the regressions some more? If that makes it go away, I'd say it pretty well points straight into the Solaris kernel. Ross -- Ross J. Reedstrom, Ph.D., [EMAIL PROTECTED] NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
On Fri, Jan 26, 2001 at 11:15:45AM -0500, Tom Lane wrote: Frank Joerdens [EMAIL PROTECTED] writes: Now I get: select_distinct_on ... FAILED select_implicit ... FAILED random ... failed (ignored) portals ... FAILED test misc ... FAILED Reporting a regression failure this way is pretty unhelpful. Sorry. My thinking was that the bottom line here is the very non-reproducability of particular results. No two regression test failures where identical of the couple dozen or so I conducted, and hence it wouldn't make all that much sense to analyze any single test all by itself. As I wrote earlier, I don't have neither physical nor root access to this box. Moreover, the sysadmin tells me that he didn't install the OS himself, a friend of his did, because he himself was on holiday. There may well be something very fishy about the OSs configuration, but I wouldn't have the first notion as to where to start looking. It _appears_ that setting DEFAULT_PGSOCKET_DIR somewhere else besides /tmp has some positive effect, but that ain't conclusive. What are the actual diffs (regression.diffs)? What shows up in the postmaster log (logs/postmaster.log)? Those results were overwritten by the last 10 tests that didn't show any errors, so I can't retrieve them, now. Regards, Frank
RE: [HACKERS] Permissions on CHECKPOINT
Yes, there should be permission checking - I'll add it later (in 7.1) if no one else. Should be simple enough. Is this okay: I think yes - please apply. Vadim
RE: [HACKERS] Permissions on CHECKPOINT
Actually, I think a more interesting question is "should CHECKPOINT have permission restrictions? If so, what should they be?" A quite relevant precedent is that Unix systems (at least the ones I've used) do not restrict who can call sync(). Checkpoints 1. affect entire system, 2. increase log output and 3. it's hard operation. Command itself was added mostly for debug purposes. Vadim
Re: [HACKERS] Open 7.1 items
Bruce Momjian wrote: Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug Reorder INSERT firing in rules I don't recall why this is wanted. AFAIK there's no reason NOT to do so, except for the actual state of beeing far too close to a release candidate. Philip Warner UPDATE crash JDBC LargeObject short read return value missing SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Consider you have a deferred "ON DELETE CASCADE" constraint and do a DELETE, INSERT of a PK. Do the FK rows need to be deleted or not? Consider you have a deferred "ON DELETE RESTRICT" and "ON UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2 to PK1, the FK2 rows need to follow, but does PK2 inherit all FK1 rows now so it's the master of both groups? These are only two possible combinations. There are many to think of. As said, I've asked before, but noone voted yet. Move the item to 7.2 anyway, because changing this behaviour would require massive changes in the trigger queue *and* the generic RI triggers, which cannot be tested enough any more. Jan Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux Merge global and template BKI files? -- 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 -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
I'm not thinking about getting this done in time for 7.1, but I think it'd be a nice cleanup for 7.2. Bruce, a TODO item please: * Remove compile-time upper limit on number of backends (MAXBACKENDS) Did you ever consider remove per-backend semaphores at all? We use them to sleep waiting for lock (ie when someone awake us by changing our semaphore) - why don't use sigpause and some signal? Semaphores are good to sync access to *shared* resources but it's not that case here. Vadim
Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
"Mikheev, Vadim" [EMAIL PROTECTED] writes: Did you ever consider remove per-backend semaphores at all? We use them to sleep waiting for lock (ie when someone awake us by changing our semaphore) - why don't use sigpause and some signal? That'll fail if the signal arrives before the sigpause(), no? Semaphores are good to sync access to *shared* resources but it's not that case here. The thing we really need here is that the right thing has to happen if the V() occurs before our P(), ie, the V() has to be remembered so that we will fall through the P() without blocking. What I'd like to look at sometime soon is using POSIX semaphores instead of SysV semaphores. But we need stateful semaphores, not signals. regards, tom lane
AW: [HACKERS] Open 7.1 items
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Sorry, to answer late. I didn't know this needed clarification. The answer is simple, foreign keys only reference a key value, not a particular row. Andreas
RE: [HACKERS] Open 7.1 items
FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? I think first. The last is closer to OODBMS world, not to [O]RDBMS one. Consider you have a deferred "ON DELETE CASCADE" constraint and do a DELETE, INSERT of a PK. Do the FK rows need to be deleted or not? Good example. I think FK should not be deleted. If someone really want to delete "old" FK then he can do DELETE PK; SET CONSTRAINT ... IMMEDIATE; -- FK need to be deleted here INSERT PK; Consider you have a deferred "ON DELETE RESTRICT" and "ON UPDATE CASCADE" constraint. If you DELETE PK1 and UPDATE PK2 to PK1, the FK2 rows need to follow, but does PK2 inherit all FK1 rows now so it's the master of both groups? Yes. Again one can use SET CONSTRAINT to achieve desirable results. It seems that SET CONSTRAINT was designed for these purposes - ie for better flexibility. Though, it would be better to look how other DBes handle all these cases -:) Vadim
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
Did you ever consider remove per-backend semaphores at all? We use them to sleep waiting for lock (ie when someone awake us by changing our semaphore) - why don't use sigpause and some signal? That'll fail if the signal arrives before the sigpause(), no? Ops, you're right. Semaphores are good to sync access to *shared* resources but it's not that case here. The thing we really need here is that the right thing has to happen if the V() occurs before our P(), ie, the V() has to be remembered so that we will fall through the P() without blocking. What I'd like to look at sometime soon is using POSIX semaphores instead of SysV semaphores. But we need stateful semaphores, not signals. Conditional variables seem to be more portable - recently I had to rewrite some program with POSIX sem developed under Solaris when porting to AIX. (BTW, OmniORB uses cond vars to simulate semaphores). Vadim
Re: [HACKERS] This script will crash the connection
Jan Wieck [EMAIL PROTECTED] writes: Tom Lane wrote: The problem here is that the query rewriter tries to hang the query's qualification (WHERE clause) onto the rule's action query, so that the action query won't be done unless the query finds at least one row to update. NOTIFY commands, being utility statements, don't have qualifications. In 7.0 and before, the qual clause just vanished into the ether, and so in this example the NOTIFY would execute whether the UPDATE updated any rows or not. In 7.1 there is physically noplace to hang the qual (no jointree) and thus a crash. Would be something for a STATEMENT trigger. We don't have 'em yet and I'm not sure what kind of information they will receive if we finally implement them. But the number of rows affected by the statement is a good candidate. That's no help for a 7.1 solution however. We can't start inventing a new feature at this stage. What I am inclined to do is have the rewriter reject conditional rules that contain NOTIFY. That seems like the minimal restriction that will prevent a crash or incorrect behavior. Comments? regards, tom lane
Re: [HACKERS] Open 7.1 items
Jan Wieck [EMAIL PROTECTED] writes: Bruce Momjian wrote: Reorder INSERT firing in rules I don't recall why this is wanted. AFAIK there's no reason NOT to do so, except for the actual state of beeing far too close to a release candidate. I think I've been the main person arguing for this change, but I agree with Jan that this late in the cycle is not the time to be making such decisions. Let's discuss it again during 7.2 cycle. regards, tom lane
[HACKERS] postmaster -S will not print an error if pid file exists
If a second postmaster is started on a data directory and the second one uses the -S option it will not print a message but simply exit and not start a background process. The exit status is 0. This seems to have gotten lost in the changes postmaster.c rev. 1.195, global lock file changes by tgl. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Sure enough, the lock file is gone
The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Sure enough, the lock file is gone
The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. If we have to do it, let's make it an #ifdef __linux__ option. -- 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: [JDBC] Open 7.1 items
[ Charset ISO-8859-1 unsupported, converting... ] Quoting Bruce Momjian [EMAIL PROTECTED]: Here are my open 7.1 items. Thanks for shrinking the list so far. --- FreeBSD locale bug Reorder INSERT firing in rules Philip Warner UPDATE crash JDBC LargeObject short read return value missing Working on this on Saturday. OK. SELECT cash_out(1) crashes all backends LAZY VACUUM FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" Usernames limited in length Does pg_dump preserve COMMENTs? Failure of nested cursors in JDBC JDBC doesn't support cursors full stop yet. Removed from list. Doesn't even seem worth adding to TODO. JDBC setMaxRows() is global variable affecting other objects Does JDBC Makefile need current dir? No as it's obsolete in 7.1 ;-) Removed. Fix for pg_dump of bad system tables Steve Howe failure query with rules ODBC/JDBC not disconnecting properly? Client code not calling Connection.close() method. Removed. ODBC seems to have a problem, though. Thanks. -- 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] Sure enough, the lock file is gone
On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. If we have to do it, let's make it an #ifdef __linux__ option. #ifdef BRAINDAMAGED_TMP_CLEANER ? ISTR mention of non-linux platforms that do this. Ross
Re: [HACKERS] This script will crash the connection
Would be something for a STATEMENT trigger. We don't have 'em yet and I'm not sure what kind of information they will receive if we finally implement them. But the number of rows affected by the statement is a good candidate. That's no help for a 7.1 solution however. We can't start inventing a new feature at this stage. What I am inclined to do is have the rewriter reject conditional rules that contain NOTIFY. That seems like the minimal restriction that will prevent a crash or incorrect behavior. Comments? OK, added to TODO: * Allow NOTIFY in rules and removed from open items 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
Re: [HACKERS] Sure enough, the lock file is gone
Ross J. Reedstrom wrote: On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. If we have to do it, let's make it an #ifdef __linux__ option. #ifdef BRAINDAMAGED_TMP_CLEANER ? ISTR mention of non-linux platforms that do this. Exactly the way you want it to do (open(2) and close(2) of a UNIX domain socket) was what I had to do to get an old Mach3-4.3BSD combo into a kernel-panic. Better use utime(2) or the like for it. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report
Ross J. Reedstrom writes: Hmm, multiple processors, and lots of IPC: I've got a bad feeling about this. Although I'm not absolutely certain, the systems on which I had this problem were not multi-processor, they were just plain-old workstations in a university computer lab. At the time (7.0 beta) I had attributed this problem to the possibly supicious nature of the /tmp partition, since Marc didn't have any such problems with his Solaris boxes. After reading Pete Forman's anecdote I looked around some more and found this: http://www.cise.ufl.edu/depot/doc/postfix/HISTORY 19990321 Workaround: from now on, Postfix on Solaris uses stream pipes instead of UNIX-domain sockets. Despite workarounds, the latter were causing more trouble than anything else on all systems combined. There are also some reports that indicate problems in this direction at http://www.landfield.com/faqs/usenet/software/inn-faq/part2/. Conclusion: Don't use it. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Sure enough, the lock file is gone
* Peter Eisentraut [EMAIL PROTECTED] [010126 12:11] wrote: The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. Why not have the RPM/configure scripts stick it in where ever redhat says it's safe to? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk."
Re: [HACKERS] Sure enough, the lock file is gone
Bruce Momjian writes: If we have to do it, let's make it an #ifdef __linux__ option. What does Linux have to do with it? FreeBSD does the same thing, only every three days. I dont' know whether it's not enabled on a fresh install, but it's there, you only need to flip the switch. I doubt /tmp cleaning is such an unusual thing, especially on large sites. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: postmaster -S will not print an error if pid file exists
Peter Eisentraut [EMAIL PROTECTED] writes: If a second postmaster is started on a data directory and the second one uses the -S option it will not print a message but simply exit and not start a background process. The exit status is 0. Since the whole point of -S is to throw away stdout/stderr, I hardly see how you can complain about the fact that the error message went to /dev/null. I agree that zero exit status is not good, however; will see if I can fix that. regards, tom lane
Re: [HACKERS] This script will crash the connection
Bruce Momjian [EMAIL PROTECTED] writes: OK, added to TODO: * Allow NOTIFY in rules Uh, what does that have to do with the problem? It's certainly not an accurate rendering of either the current or proposed status ... regards, tom lane
Re: [HACKERS] Open 7.1 items
Bruce Momjian [EMAIL PROTECTED] writes: SELECT cash_out(1) crashes all backends OK, removed from 'open' list and added to TODO. Actually, I can't get the crash to happen except with cash_out. Is there another *out function you can get to fail. Any pass-by-reference type; also most if not all input functions. regards, tom lane
Re: [HACKERS] Bug in FOREIGN KEY
Here is another bug: test= begin; BEGIN test= INSERT INTO primarytest2 VALUES (5,5); INSERT 18757 1 test= UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5; ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not found Bruce Momjian wrote: Bruce Momjian writes: ERROR: triggered data change violation on relation "primarytest2" We're getting this report about once every 48 hours, which would make it a FAQ. (hint, hint) First time I heard of it. Does anyone know more details? Think I misinterpreted the SQL3 specs WR to this detail. The checks must be made per statement, not at the transaction level. I'll try to fix it, but we need to define what will happen with referential actions in the case of conflicting actions on the same key - there are some possible conflicts: 1. DEFERRED ON DELETE NO ACTION or RESTRICT Do the referencing rows reference to the new PK row with the same key now, or is this still a constraint violation? I would say it's not, because the constraint condition is satisfied at the end of the transaction. How do other databases behave? 2. DEFERRED ON DELETE CASCADE, SET NULL or SET DEFAULT Again I'd say that the action should be suppressed because a matching PK row is present at transaction end - it's not the same old row, but the constraint itself is still satisfied. Implementing it that way (if it is correct that way) requires that the RI-triggers check that the key in question really disappeared from the PK table, at least for the deferred invocation at transaction end. This lookup is not required in the immediate case, so it would be possible to retain the current performance here, but we'd need a mechanism that tells the trigger if it is actually invoked in immediate or deferred mode. Don't know how to do that right now. To fix it now, I'd tend to remove the triggered data change check in the trigger queue (where the error is coming from) and add the extra PK lookup to the triggers for 7.1. Then think about the suppress of it with an immediate/deferred flag mechanism for 7.2. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # -- 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] Open 7.1 items
Bruce Momjian writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" You're certainly not going to want to fix this now after having stared at it for a year? It's not trivial. Moved to TODO. Usernames limited in length Yeah, they are. ;-) If this is referring to pg_passwd, I just had a closer look and it's really a desaster. Both password and username as well as line length and file length (in lines) have arbitrary limits, sometimes not even consistent ones. To fix this to a point where one is confident that everything works one essentially would have to rewrite the whole thing. Added to TODO: * Fix username/password length limits in all areas Does pg_dump preserve COMMENTs? Sure OK, thanks. Someone submitted a patch, and I wasn't sure how to handle it. I thought it did it already. Fix ipcclean on Linux Consider it done. Thanks. Merge global and template BKI files? Not this release. Added to TODO. -- 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: AW: [HACKERS] Open 7.1 items
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" A well known issue, and I've asked multiple times how exactly we want to define the behaviour for deferred constraints. Do foreign keys reference just to a key value and are happy with it's existance, or do they refer to a particular row? Sorry, to answer late. I didn't know this needed clarification. The answer is simple, foreign keys only reference a key value, not a particular row. Cite chapter and verse in the spec, please? regards, tom lane
Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
"Mikheev, Vadim" [EMAIL PROTECTED] writes: What I'd like to look at sometime soon is using POSIX semaphores instead of SysV semaphores. But we need stateful semaphores, not signals. Conditional variables seem to be more portable Really? Which standard are they specified in? I have no intention of removing the SysV sem support, mind you; I just think it might be good to have an alternative implementation that relies on a more modern standard ... regards, tom lane
[HACKERS] Database tables disappeared.
I was woundering if any of you have seen this problem. I have been running a system using a postgres 6.5 database. After a while I realized the system wasn't very active so I looked into it. I tryed to view all the tables in the database using the \d command, but it return: - Couldn't find any tables, sequences or indices! So I then tried to do a select statement from the table, which worked, although no data was returned, but the table structure was correct. I have backed up my database and have been trying to recover my data with no luck. I am able to vacuum the tables and have it tell me that there are several those tuples in each table, yet I still cant view the data. Any suggestions? Thanks, Stefan Klopp ecmarket
Re: [HACKERS] Sure enough, the lock file is gone
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian writes: If we have to do it, let's make it an #ifdef __linux__ option. What does Linux have to do with it? FreeBSD does the same thing, only every three days. I dont' know whether it's not enabled on a fresh install, but it's there, you only need to flip the switch. I doubt /tmp cleaning is such an unusual thing, especially on large sites. Yes, there are lots of systems that will clean /tmp --- and since the lock file is an ordinary file (not a socket) pretty much any tmp-cleaner is going to decide to remove it. I think that I had intended to insert a periodic touch of the lockfile and forgot to. Touching it every time through ServerLoop is an overreaction though. I'd suggest touching it in the checkpoint-process-firing code, which runs every five minutes (or so?) by default. regards, tom lane
Re: [HACKERS] Bug in FOREIGN KEY
Bruce Momjian wrote: Here is another bug: test= begin; BEGIN test= INSERT INTO primarytest2 VALUES (5,5); INSERT 18757 1 test= UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5; ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not found Schema? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
RE: [HACKERS] Hardwired MAXBACKENDS limit could be history
Conditional variables seem to be more portable Really? Which standard are they specified in? POSIX - they are in pthread library (eg man pthread_cond_init). For sem_init I see in man (on Solaris and AIX): ENOSYS The sem_init() function is not supported what is exactly I've got on AIX. Vadim
Re: [HACKERS] Sure enough, the lock file is gone
Peter Eisentraut wrote: Jan Wieck writes: Exactly the way you want it to do (open(2) and close(2) of a UNIX domain socket) was what I had to do to get an old Mach3-4.3BSD combo into a kernel-panic. The lock file is an ordinary file. So the crazy-temp-vacuum-cleaner on linux doesn't touch the sockets? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [HACKERS] Bug in FOREIGN KEY
Bruce Momjian wrote: Here is another bug: test= begin; BEGIN test= INSERT INTO primarytest2 VALUES (5,5); INSERT 18757 1 test= UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5; ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not found Schema? CREATE TABLE primarytest2 ( col1 INTEGER, col2 INTEGER, PRIMARY KEY(col1, col2) ); CREATE TABLE foreigntest2 (col3 INTEGER, col4 INTEGER, FOREIGN KEY (col3, col4) REFERENCES primarytest2 ); -- 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] Bug in FOREIGN KEY
-Original Message- From: Bruce Momjian Bruce Momjian wrote: Here is another bug: ISTM commands/trigger.c is broken. The behabior seems to be changed by recent changes made by Tom. * Check if we're interested in this row at all * -- * -- */ */ ntriggers = rel-trigdesc-n_after_row[event]; if (ntriggers = 0) Regards, Hiroshi Inoue test= begin; BEGIN test= INSERT INTO primarytest2 VALUES (5,5); INSERT 18757 1 test= UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5; ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not found Schema? CREATE TABLE primarytest2 ( col1 INTEGER, col2 INTEGER, PRIMARY KEY(col1, col2) ); CREATE TABLE foreigntest2 (col3 INTEGER, col4 INTEGER, FOREIGN KEY (col3, col4) REFERENCES primarytest2 ); -- 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] Bug in FOREIGN KEY
"Hiroshi Inoue" [EMAIL PROTECTED] writes: ISTM commands/trigger.c is broken. The behabior seems to be changed by recent changes made by Tom. Hm. I changed the code to not log an AFTER event unless there is actually a trigger of the relevant type, thus suppressing what I considered a very serious memory leak in the non-deferred-trigger case. Are there cases where we must log an event anyway, and if so what are they? It didn't look to me like the deferred event executor would do anything with a logged event that has no triggers ... regards, tom lane
Re: [HACKERS] Permissions on CHECKPOINT
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Mikheev, Vadim writes: Yes, there should be permission checking - I'll add it later (in 7.1) if no one else. Should be simple enough. Is this okay: Actually, I think a more interesting question is "should CHECKPOINT have permission restrictions? If so, what should they be?" A quite relevant precedent is that Unix systems (at least the ones I've used) do not restrict who can call sync(). What about DoS attacks? What would be the effect of someone's setting off an infinite loop of CHECKPOINTs? Don't we have bigger DoS attacks? Certainly SELECT cash_out(1) is a much bigger one. -- 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
[HACKERS] Re: postmaster -S will not print an error if pid file exists
Peter Eisentraut [EMAIL PROTECTED] writes: If a second postmaster is started on a data directory and the second one uses the -S option it will not print a message but simply exit and not start a background process. The exit status is 0. On closer inspection, it's clear that the postmaster *does* exit with status 1 after failing to lock the lockfile. However, since it's already forked and detached from the terminal, you can't see the status 1; the parent process exited with status 0. Postponing the fork till after we grab the lockfile will not do, because then the lockfile will contain the wrong postmaster PID. I have stated before that I consider -S evil. Don't complain too hard about its behavior, or I'll fix it by ripping it out, lock stock and barrel ;-) regards, tom lane
Re: [HACKERS] Permissions on CHECKPOINT
[ Charset ISO-8859-1 unsupported, converting... ] What about DoS attacks? What would be the effect of someone's setting off an infinite loop of CHECKPOINTs? Don't we have bigger DoS attacks? Certainly SELECT cash_out(1) is a much bigger one. I've missed point - cash_out(1) is bug that should be fixed. Any reason to add yet another gun? True. I just thought there were many bigger DoS areas. Maybe I am wrong. -- 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] Sure enough, the lock file is gone
I said: Yes, there are lots of systems that will clean /tmp --- and since the lock file is an ordinary file (not a socket) pretty much any tmp-cleaner is going to decide to remove it. I think that I had intended to insert a periodic touch of the lockfile and forgot to. Done now. regards, tom lane
Re: [HACKERS] Permissions on CHECKPOINT
Okay, okay, complaint withdrawn. Peter, would you commit that permission check? regards, tom lane
[HACKERS] Which version?
Hello, guys: I am working on adding Postgre support to our multi-threaded benchmarking tool, which currenlty only support MySQL, and was wondering which version of pg you would recommend that I use for benchmarks, as well as any special performance considerations for pg-sql I need to be aware of while doing tests. The most obvious solution - the 7.0.3 source tarball from the downloads section on the website did not work because of undefined F_OIDEQ in istrat.c, and I greped and greped around the source trying to find some insights on it. My understanding is that F_OIDEQ is a constant that tells the key reading code how to read a key, or what kind of key it is. Unfortunately, it seems like the file that defines the constant disappeared from the distribution, or possibly did not get generated by configure if it was supposed to be generated. For a while, I thought it could be some mysterious fcntl() option I had never heard of, but looking at the code it appears otherwise :-) Anyway, I would appreciate your feedback. -- MySQL Development Team __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sasha Pachev [EMAIL PROTECTED] / /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/ /_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA ___/
[HACKERS] Re: [GENERAL] MySQL - Postgres dump converter
Guys, Thomas said he won't look into GPL'ed code for ideas. Well, I re-read GPL and found that it's up to author whether is to allow or not to use code for using in programs with another open-source license. So this isn't a problem - you may use my program and include code to your without limitations. I even would prefer to change license to BSD or similar but I didn't find in GPL ideas about that. Max Rudensky. On Wed, 24 Jan 2001 11:06:12 -0500 (EST) Bruce Momjian [EMAIL PROTECTED] wrote: Can someone look at both versions and merge the improvements into our version? Should be pretty easy. Can some PostgreSQL people comment on this? This person wrote a MySQL-PostgreSQL converter too. His version is at: http://ziet.zhitomir.ua/~fonin/code -- THIS VERSION IS EXTREMELY BUGSOME ! USE IT ON YOUR OWN RISK !!! Hmm. My version does not have this feature, but it could be added ;) Seriously, I haven't looked at the differences, but there is a licensing difference (BSD vs GPL). Someone else with experience with MySQL should evaluate both packages. mysql2pgsql has been used to convert SourceForge, with ~90 tables and moderately complicated schema, but that did not include enumerated types (done with ints at SF) and "unique" keys (done with sequences at SF) afaicr. Sucks found:... Each is a one-liner to fix in mysql2pgsql. The (nonstandard) types mentioned weren't used in the test cases I had available. I didn't realize that we had *any* reports of troubles or lacking features in the existing converter, but I'll leave it up to y'all to decide if the licensing issues and feature issues are significant. I'm willing to provide patches to address some of the concerns, but of course will not be able to look at the GPL'd code for hints and can only use the information posted here to help afaik. Comments? - Thomas -- 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
[HACKERS] Re: SourceForge Postgres (fwd)
Do we need to do a bunch of testing on Beta3 before deployment or is it so much more stable that it absolutely will have no problems? We haven't had any problems with the ~Nov 17 snapshot, so we figure why mess with a good thing. Tim On Thu, Jan 25, 2001 at 08:23:30PM -0500, Jeff Duffy wrote: Just wanted to make sure you saw this. Jeff -- Forwarded message -- Date: Thu, 25 Jan 2001 16:51:44 -0500 (EST) From: Jan Wieck [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: SourceForge Postgres Tim Perdue wrote: I thought the hackers team would be interested in knowing that SourceForge, as of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open Source projects are depending on your stuff, so I hope it's going to be stable for us. ;-) Tim, the PG core team is wondering if SourceForge might still be running on a snapshot prior to BETA3, because there is a major bug in it that could result in a complete corruption of the system catalog. The bug is that the shared buffer cache might mix up blocks between different databases. As long as you only use one database, you're fairly safe. But a single 'createdb' or 'createuser' on the same instance, which is connecting to template1, could blow away your entire installation. It is fixed in BETA3. My personal recommendation should be clear. Jan -- Founder - PHPBuilder.com / Geocrawler.com Lead Developer - SourceForge VA Linux Systems
Re: [HACKERS] beta3 Solaris 7 (SPARC) port report [ Was: Looking for . . . ]
On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote: Frank Joerdens [EMAIL PROTECTED] writes: I just did that and ran make check 4 times. 3 times went completely smoothly, once I had random fail. This is the same behaviour that I saw when running make installcheck (76 successful most of the time, sometimes you get 75 out of 76 with random being the one that fails). Er, you do realize that the random test is *supposed* to fail every so often? (Else it'd not be random...) See the pages on interpreting regression test results in the admin guide. What troubles me is the nonrepeatable failures you saw on other tests. As Peter says, if "make installcheck" (serial tests) is perfectly solid and "make check" (parallel tests) is not, that suggests some kind of interprocess locking problem. But we haven't heard about any such issue on Solaris. Or simply running out of processes - check maxproc? (Deleted beginning of this thread, so may have missed something) Cheers, Patrick
Re: [HACKERS] Which version?
Need more information ... specifically what OS are you running? I *just*
built PgSQL 7.0.3 on my freshly installed FreeBSD 4.2-RELEASE box, and it
compiled cleanly ...
On Fri, 26 Jan 2001, Sasha Pachev wrote:
Hello, guys:
I am working on adding Postgre support to our multi-threaded benchmarking
tool, which currenlty only support MySQL, and was wondering which version of
pg you would recommend that I use for benchmarks, as well as any special
performance considerations for pg-sql I need to be aware of while doing tests.
The most obvious solution - the 7.0.3 source tarball from the downloads
section on the website did not work because of undefined F_OIDEQ in istrat.c,
and I greped and greped around the source trying to find some insights on it.
My understanding is that F_OIDEQ is a constant that tells the key reading
code how to read a key, or what kind of key it is. Unfortunately, it seems
like the file that defines the constant disappeared from the distribution, or
possibly did not get generated by configure if it was supposed to be
generated. For a while, I thought it could be some mysterious fcntl() option
I had never heard of, but looking at the code it appears otherwise :-)
Anyway, I would appreciate your feedback.
--
MySQL Development Team
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev [EMAIL PROTECTED]
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
___/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] PQprint
Hi all, Re-posting this to -hackers. Will PQprint() remain/disappear/be replaced in the future? No idea. We are not sure who uses 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
RE: [HACKERS] Bug in FOREIGN KEY
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] "Hiroshi Inoue" [EMAIL PROTECTED] writes: ISTM commands/trigger.c is broken. The behabior seems to be changed by recent changes made by Tom. Hm. I changed the code to not log an AFTER event unless there is actually a trigger of the relevant type, thus suppressing what I considered a very serious memory leak in the non-deferred-trigger case. Are there cases where we must log an event anyway, and if so what are they? It didn't look to me like the deferred event executor would do anything with a logged event that has no triggers ... Because I don't know details about trigger stuff, I may be misunderstanding. As far as I see, KEY_CHANGED stuff requires to log every event about logged tuples. However I'm suspicious if KEY_CHANGED check is necessary. Removing KEY_CHANGED stuff seems to solve the TODO FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" though it may introduce other bugs. Regards, Hiroshi Inoue
Re: [HACKERS] Hardwired MAXBACKENDS limit could be history
It would require only very minor changes in the main backend code to eliminate entirely the hard-wired upper bound MAXBACKENDS. This would be nice since there'd never be any need to recompile in order to increase the soft limit MaxBackends (-N). However I see that the SysV-semaphore emulation code used by the QNX and Darwin ports still makes use of MAXBACKENDS to size some arrays. I don't especially want to touch that code, since I am in no position to test it. Perhaps someone who uses QNX and/or Darwin would like to tweak the sema code to not depend on a compile-time-constant MAXBACKENDS? I'm not thinking about getting this done in time for 7.1, but I think it'd be a nice cleanup for 7.2. Bruce, a TODO item please: * Remove compile-time upper limit on number of backends (MAXBACKENDS) Added to TODO. -- 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] Sure enough, the lock file is gone
On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. If we have to do it, let's make it an #ifdef __linux__ option. #ifdef BRAINDAMAGED_TMP_CLEANER ? ISTR mention of non-linux platforms that do this. Yes, thank you. -- 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] Sure enough, the lock file is gone
I said: Yes, there are lots of systems that will clean /tmp --- and since the lock file is an ordinary file (not a socket) pretty much any tmp-cleaner is going to decide to remove it. I think that I had intended to insert a periodic touch of the lockfile and forgot to. Done now. Yes, checkpoint is a good place to put it. Thanks. I still liked the BRAINDAMAGED_TMP_CLEANER though. -- 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] This script will crash the connection
Bruce Momjian [EMAIL PROTECTED] writes: OK, added to TODO: * Allow NOTIFY in rules Uh, what does that have to do with the problem? It's certainly not an accurate rendering of either the current or proposed status ... Oops, can you give me a line. What was the issue? -- 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] new version of contrib-intarray
Oleg, do you want this in /contrib for 7.1? Mark, we prepared new version of contrib-intarray - index support for 1-D integer arrays using GiST. Changes: - Improved regression test - Current implementation provides index support for one-dimensional array of int4's - gist__int_ops, suitable for small and medium size of arrays, and gist__intbig_ops for indexing large arrays (we use superimposed signature with length of 4096 bits to represent sets, see Sven Helmer,1997). Archive is available from http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 -- 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] Bug in FOREIGN KEY
I wrote: Are there cases where we must log an event anyway, and if so what are they? It didn't look to me like the deferred event executor would do anything with a logged event that has no triggers ... Oops, I missed the uses of deferredTriggerGetPreviousEvent(). Fixed now. regards, tom lane
Re: [HACKERS] Bug in FOREIGN KEY
"Hiroshi Inoue" [EMAIL PROTECTED] writes: Because I don't know details about trigger stuff, I may be misunderstanding. As far as I see, KEY_CHANGED stuff requires to log every event about logged tuples. I just realized that myself. The code was still doing it the hard way (eg, logging *both* before and after events for each tuple), but it does seem necessary to log all events if there is either an UPDATE or DELETE deferred trigger. However I'm suspicious if KEY_CHANGED check is necessary. Removing KEY_CHANGED stuff seems to solve the TODO FOREIGN KEY INSERT UPDATE/DELETE in transaction "change violation" though it may introduce other bugs. I suspect it just masks the problem by preventing the trigger code from executing ... regards, tom lane
Re: [HACKERS] This script will crash the connection
Bruce Momjian [EMAIL PROTECTED] writes: OK, added to TODO: * Allow NOTIFY in rules Uh, what does that have to do with the problem? It's certainly not an accurate rendering of either the current or proposed status ... Oops, can you give me a line. What was the issue? "Allow NOTIFY in conditional rules" would be an approximation. It's not the whole story though, because presently we also have to fail if the rule is applied to a query with conditions, even if the rule itself is unconditional. As of my last commit: regression=# create rule r1 as on update to int4_tbl do notify foo; CREATE regression=# update int4_tbl set f1 = f1; UPDATE 5 regression=# update int4_tbl set f1 = f1 where f1 0; ERROR: Conditional NOTIFY is not implemented which is pretty ugly but at least it doesn't pretend to do something it can't, which was the 7.0 behavior. (In 7.0 you'd have gotten a NOTIFY whether the update updated any rows or not.) regards, tom lane
Re: [HACKERS] This script will crash the connection
Bruce Momjian [EMAIL PROTECTED] writes: OK, added to TODO: * Allow NOTIFY in rules Uh, what does that have to do with the problem? It's certainly not an accurate rendering of either the current or proposed status ... Oops, can you give me a line. What was the issue? "Allow NOTIFY in conditional rules" would be an approximation. It's not the whole story though, because presently we also have to fail if the rule is applied to a query with conditions, even if the rule itself is unconditional. As of my last commit: regression=# create rule r1 as on update to int4_tbl do notify foo; CREATE regression=# update int4_tbl set f1 = f1; UPDATE 5 regression=# update int4_tbl set f1 = f1 where f1 0; ERROR: Conditional NOTIFY is not implemented which is pretty ugly but at least it doesn't pretend to do something it can't, which was the 7.0 behavior. (In 7.0 you'd have gotten a NOTIFY whether the update updated any rows or not.) Added to TODO: * Allow NOTIFY in rules involving conditionals This covers both cases of conditionals in the rule or the query. -- 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
[HACKERS] Open 7.1 items
Here are the open items for 7.1. Much shorter: Reorder INSERT firing in rules JDBC LargeObject short read return value missing LAZY VACUUM JDBC setMaxRows() is global variable affecting other objects Fix for pg_dump of bad system tables ODBC not disconnecting properly? Magnus Hagander ODBC issues? Merge MySQL/PgSQL translation scripts Fix ipcclean on Linux unixODBC -- 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] Sure enough, the lock file is gone
On Fri, Jan 26, 2001 at 05:06:24PM -0500, Jan Wieck wrote: So the crazy-temp-vacuum-cleaner on linux doesn't touch the sockets? The tmpwatch program that comes with many Linux distributions will only unlink regular files and empty directories by default. -- Bruce Guenter [EMAIL PROTECTED] http://em.ca/~bruceg/ PGP signature
[HACKERS] reorder INSERT firing in rules
I now remember that we decided that it was too late in 7.1 to fix this: reorder INSERT firing in rules Added to TODO: Evaluate INSERT rules at end of query, rather than beginning -- 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: SourceForge Postgres (fwd)
Tim Perdue [EMAIL PROTECTED] writes: Do we need to do a bunch of testing on Beta3 before deployment or is it so much more stable that it absolutely will have no problems? Well, it's more stable than any pre-beta snapshot is likely to be ... We haven't had any problems with the ~Nov 17 snapshot, so we figure why mess with a good thing. That RelFileNodeEquals bug absolutely *will* eat you for breakfast sooner or later. If you want to live dangerously, stick with the snapshot you have, but I beg you to apply this patch: === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/include/storage/relfilenode.h,v retrieving revision 1.3 retrieving revision 1.4 diff -c -r1.3 -r1.4 *** pgsql/src/include/storage/relfilenode.h 2000/10/18 05:50:16 1.3 --- pgsql/src/include/storage/relfilenode.h 2001/01/09 02:15:16 1.4 *** *** 17,22 #define RelFileNodeEquals(node1, node2) \ ((node1).relNode == (node2).relNode \ ! (node2).tblNode == (node2).tblNode) #endif/* RELFILENODE_H */ --- 17,22 #define RelFileNodeEquals(node1, node2) \ ((node1).relNode == (node2).relNode \ !(node1).tblNode == (node2).tblNode) #endif/* RELFILENODE_H */ regards, tom lane
[HACKERS] Re: Re: MySQL has transactions
At 10:02 AM 1/25/01 -0500, you wrote: When Postgresql 6.5 came out it, it was VERY MUCH better ( many many thanks to the developers and all involved). And I'm waiting for a solid 7.1 to fix that 8KB issue. Technically.. = BLCKSZ (can be up to 32k) I've been using PostgreSQL with a 32k BLCKSZ since 7.0 (on a productions server) and haven't had a problem one.. Yep but doesn't quite help my webmail app :). I'm wondering if TOAST is going to be efficient enough for me to plonk multimegabyte email attachments into the database. However I've also a suspicion that there might be problems doing INSERT INTO mytable (a) values ( 'aa...'); Where aa... is a few megabytes long :). There's probably a query size limit somewhere between my app and TOAST. Cheerio, Link.
Re: [HACKERS] Re: Re: MySQL has transactions
Lincoln Yeoh [EMAIL PROTECTED] writes: I'm wondering if TOAST is going to be efficient enough for me to plonk multimegabyte email attachments into the database. Should work. The main limitation on TOAST is that it wants to treat each datum as a unit, ie you must fetch or store the whole value in one go. When your datums get big enough that that's inconvenient, you won't like TOAST so much. I don't foresee it being a big issue for emailable items though ... However I've also a suspicion that there might be problems doing INSERT INTO mytable (a) values ( 'aa...'); Where aa... is a few megabytes long :). There's probably a query size limit somewhere between my app and TOAST. I've tested this, it works fine since 7.0 or so. Amusing anecdote: since 7.0, MySQL's "crashme" test crashes when run against Postgres. Postgres is fine, it's the perl job running the crashme script that goes belly-up. It seems that crashme's loop that tries to discover the maximum query length is more memory-hungry than Postgres itself, and so the perl job hits the kernel-imposed maximum process size before the backend does. Moral: before assuming Postgres can't do something, make sure your own code can hold up its end... regards, tom lane
Re: [HACKERS] new version of contrib-intarray
On Sat, 27 Jan 2001, Bruce Momjian wrote: Oleg, do you want this in /contrib for 7.1? yes, if it's possible. btw, is there way to specify default ops for index ? We have two methods of index creation for intarrays and would like to define which should be used by default Mark, we prepared new version of contrib-intarray - index support for 1-D integer arrays using GiST. Changes: - Improved regression test - Current implementation provides index support for one-dimensional array of int4's - gist__int_ops, suitable for small and medium size of arrays, and gist__intbig_ops for indexing large arrays (we use superimposed signature with length of 4096 bits to represent sets, see Sven Helmer,1997). Archive is available from http://www.sai.msu.su/~megera/postgres/gist/code/7.1/contrib-intarray.tar.gz Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] Which version?
I just checked the md5 signature against the one that is online, and they
are exactly the same ... what is at the URL you present is *exactly* the
same as the one that is on ftp.postgresql.org ...
On Fri, 26 Jan 2001, Sasha Pachev wrote:
On Friday 26 January 2001 19:04, The Hermit Hacker wrote:
Need more information ... specifically what OS are you running? I *just*
built PgSQL 7.0.3 on my freshly installed FreeBSD 4.2-RELEASE box, and it
compiled cleanly ...
This happened on SuSE 7.0, compiling with gcc 2.95. Maybe I downloaded some
stale corrupted tarball with a file missing - I went to
.http://www.pgsql.com/download/ and just clicked on the top "Download"
button. Where is F_OIDEQ supposed to be defined anyway?
--
MySQL Development Team
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev [EMAIL PROTECTED]
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
___/
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
