AW: AW: AW: [HACKERS] Re: tinterval - operator problems on AIX
On AIX mktime(3) leaves tm_isdst at -1 if it does not have timezone info for that particular year and returns -1. The following code then makes savings time out of the -1. tz = (tm-tm_isdst ? (timezone - 3600) : timezone); Hmm. That description is consistant with what I see in the Linux man page. So I should check for (tm-tm_isdst 0) rather than checking for non-zero? It is obviously not possible to determine tm_isdst with mktime for a negative time_t. Thus with above fix PST works, but PDT is then busted :-( Obvious to AIX only? Yes. The whole subject only concerns AIX (at least so far). My conclusion is that the AIX timezone database is damaged or missing for pre-1970 dates, but that other systems bothered to get it at least somewhat right. Is there another issue here that I'm missing? The tz db is neighter damaged nor missing anything (see below). Only mktime does not work for some (maybe even avoidable) reason for dates before 1970. localtime does convert a negative time_t correctly including dst. Is there another way to determine tm_isdst ? Yes. Replace AIX with Linux or something else, then recompile Postgres ;) As I see it, the Linux results are also not 100 % correct in respect to dates before 1970. (based on assumption that Solaris is correct) e.g.: 1503c1503 | Sat May 10 23:59:12 1947 PST --- | Sat May 10 23:59:12 1947 PDT Was 1947 PDT or PST ? In eighter case one result is one hour off, Solaris or Linux. This raises another issue. Why do we distribute expected files with bogus results in them ? Imho it would be better to only have expected files for rounding issues and the like. Else the user feels that horology works fine on his machine, but as it looks it only works on a few. Andreas
Re: [HACKERS] Re: GiST for 7.1 !!
On Wed, 10 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: we've almost totally rewrite gist.c because old code and algorithm were not suitable for variable size keys. I think it might be submitted into 7.1 beta source tree. Urgh. Dropping in a total rewrite when we're already past beta3 doesn't strike me as good project management practice --- especially if the rewrite was done to add features (ie variable-size keys) not merely fix bugs. I think it might be more prudent to hold this for 7.2. OK. If our changes will not go to 7.1, is't possible to create feature archive and announce it somewhere. It would be nice if people could test it. Anyway, I'll create web page with all docs and patches. I'm afraid one more year to 7.2 is enough for GiST to die :-) regards, tom lane 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
AW: [HACKERS] Re: GiST for 7.1 !!
we've almost totally rewrite gist.c because old code and algorithm were not suitable for variable size keys. I think it might be submitted into 7.1 beta source tree. Urgh. Dropping in a total rewrite when we're already past beta3 doesn't strike me as good project management practice --- especially if the rewrite was done to add features (ie variable-size keys) not merely fix bugs. I think it might be more prudent to hold this for 7.2. OK. If our changes will not go to 7.1, is't possible to create feature archive and announce it somewhere. It would be nice if people could test it. Anyway, I'll create web page with all docs and patches. I'm afraid one more year to 7.2 is enough for GiST to die :-) I think featureism is the the most prominent argument for PostgreSQL. Thus standing before a decision to eighter fix GiST bugs and risc a new bug (limited to GiST) because of an added feature or shipping a known broken GiST, my vote would definitely be to add Oleg's patch. Andreas
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Zeugswetter Andreas SB wrote: we've almost totally rewrite gist.c because old code and algorithm were not suitable for variable size keys. I think it might be submitted into 7.1 beta source tree. Urgh. Dropping in a total rewrite when we're already past beta3 doesn't strike me as good project management practice --- especially if the rewrite was done to add features (ie variable-size keys) not merely fix bugs. I think it might be more prudent to hold this for 7.2. OK. If our changes will not go to 7.1, is't possible to create feature archive and announce it somewhere. It would be nice if people could test it. Anyway, I'll create web page with all docs and patches. I'm afraid one more year to 7.2 is enough for GiST to die :-) I think featureism is the the most prominent argument for PostgreSQL. Thus standing before a decision to eighter fix GiST bugs and risc a new bug (limited to GiST) because of an added feature or shipping a known broken GiST, my vote would definitely be to add Oleg's patch. Definetely, our changes limited to GiST insert algorithm only. Other changes are bugfixes. I encourage people interested in GiST to test my submission. Our implementation of RD-Tree which we used to support of indexing of int4 arrays will works only with our version of gist.c (actually our interest to GiST was motivated by index support of int4 arrays). Regards, Oleg Andreas _ 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
[HACKERS] drop table and pg_proc
Suppose a function using table t1 as its argument: create table t1(... create fuction f1(t1) returns... And if I drop t1 then do pg_dump, I would got something like: failed sanity check, type with oid 1905168 was not found This is because the type t1 does not exist anynmore. Since not being able to make a back up of database is a critical problem, I think we have to fix this. 1) remove that proc entry from pg_proc if t1 is deleted 2) fix pg_dump so that it ignores sunch a bogus entry 3) do both 1) and 2) Comments? -- Tatsuo Ishii
Re: AW: AW: [HACKERS] Re: tinterval - operator problems on AIX
Zeugswetter Andreas SB writes: Try the attachment with negative values, and tell us whether mktime returns anything other that -1. Do you have an idea how else we could determine daylight savings time ? mktime always returns -1 for tm's that might expect to return a negative number. In those cases the tm is not normalized and tm_isdst is set to -1. When mktime returns zero or positive then tm is normalized and tm_isdst is set to 0 or 1. localtime sets all the fields of tm correctly, including tm_isdst, for all values of time_t, including negative ones. When I say correctly, there is the usual limitation that the rules to specify when DST is in force cannot express a variation from year to year. (You can specify e.g. the last Sunday in a month.) My observations were consistent across AIX 4.1.5, 4.2.1, and 4.3.3. If you have a time_t, then you can use localtime to determine DST. If you have a tm then you cannot work out DST for dates before the epoch. One workaround would be to add 4*n to tm_year and subtract (365*4+1) *24*60*60*n from the time_t returned. (All leap years are multiples of 4 in the range 1901 to 2038. If tm_wday is wanted, that will need to be adjusted as well.) But don't you do time interval arithmetic using PostgreSQL date types rather than accepting the limitations of POSIX/UNIX? -- 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] Re: GiST for 7.1 !!
Oleg ... how about a contrib/patches directory that we put this into for
v7.1 release, so that ppl have access to it, and then we apply the patch
first thing for part of v7.2?
On Thu, 11 Jan 2001, Oleg Bartunov wrote:
On Wed, 10 Jan 2001, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
we've almost totally rewrite gist.c because old code and algorithm
were not suitable for variable size keys. I think it might be
submitted into 7.1 beta source tree.
Urgh. Dropping in a total rewrite when we're already past beta3 doesn't
strike me as good project management practice --- especially if the
rewrite was done to add features (ie variable-size keys) not merely
fix bugs. I think it might be more prudent to hold this for 7.2.
OK. If our changes will not go to 7.1, is't possible to create
feature archive and announce it somewhere. It would be nice if
people could test it. Anyway, I'll create web page with all
docs and patches. I'm afraid one more year to 7.2 is enough for
GiST to die :-)
regards, tom lane
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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: AW: AW: [HACKERS] Re: tinterval - operator problems on AIX
Pete Forman writes: One workaround would be to add 4*n to tm_year and subtract (365*4+1) *24*60*60*n from the time_t returned. (All leap years are multiples of 4 in the range 1901 to 2038. If tm_wday is wanted, that will need to be adjusted as well.) FWIW, that should be to add 28*n to tm_year and subtract (365*4+1)*7 *24*60*60*n from the time_t returned. That calculates tm_wday correctly. Also I should have been more explicit that this applies only to AIX and IRIX. Those return -1 from mktime(year 1970) and do not allow DST rules to vary from year to year. Linux and Solaris have more capable date libraries. -- Pete Forman http://www.bedford.waii.com/wsdev/petef/PeteF_links.html WesternGeco http://www.crosswinds.net/~petef Manton Lane, Bedford, mailto:[EMAIL PROTECTED] MK41 7PA, UK tel:+44-1234-224798 fax:+44-1234-224804
[HACKERS] UNDER?
Is UNDER being stripped out for 7.1? I'm looking at documentation and don't want to write about it if it won't be in there. -- 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: GiST for 7.1 !!
The Hermit Hacker wrote: Oleg ... how about a contrib/patches directory that we put this into for v7.1 release, so that ppl have access to it, and then we apply the patch first thing for part of v7.2? And have Mandrake ship postgresql-v7.1-GiST-1mdk.rpm by default ;) I would even vote for including the ability to index int(4) arrays in the main distribution and not in contrib, similar to the current state of plpgsq and other pl* - ie they are compiled by default but not "activated". Assumption that arrays are indexable seems to come up once or twice a month on the mailing lists. --- Hannu
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Hannu Krosing [EMAIL PROTECTED] writes: That's my vote too, specially if there will be some regression tests accompanying the patches. The current (pre-patch) state of affairs with GiST could probably be described as security-by-obscurity anyhow i.e. "we have't tried it so we think it probably works" ;-) Au contraire, there *are* a few users of GiST out there now, Gene Selkov to name one. So there is a definite risk of breaking things that worked in 7.0 and before, in the name of adding new features. If I thought that we had adequate ability to test the new GiST implementation during the remaining beta period, I wouldn't be so worried. But at this point, Oleg's changes could not appear in the beta series before beta4, and between the late date, the lack of regression test, and the few interested people to test it, I doubt that we'll get any useful coverage. I would recommend that Oleg do like Ryan K. did for awhile with the Alpha patches: make them available as a set of diffs to be applied to the official distribution. We'll be happy to merge them in for 7.2, but the calendar says it's too late for 7.1. regards, tom lane
[HACKERS] Re: Re: BETWEEN [SYMMETRIC | ASYMMETRIC]
At 1/10/2001 09:10 PM, you wrote: Thomas Swan [EMAIL PROTECTED] writes: Actually if it were possible to look at the values before expanding. You could reorder the expression so that it was always the case that B C, then your cost would only be one comparison plus the sequential scan. Uh ... what if B and C are not constants? Hmmm... I see your point. I was looking back through the sources and was thinking. I'd hate doing the work twice. Is there something in place to reorder or sort or compare results? Possibly expanding to something like a = max(b,c) and a = min(b,c)
Re: [HACKERS] UNDER?
"Robert B. Easter" wrote: Is UNDER being stripped out for 7.1? I'm looking at documentation and don't want to write about it if it won't be in there. Thats' how I understand the outcome of a discussion about 1 week ago here: Tom Lane wrote on Tue Jan 2 20:19:18 2001: Anyway, we seem to have a clear consensus to pull the UNDER clause from the grammar and stick with INHERITS for 7.1. I will take care of that in the next day or so. -- Hannu
[HACKERS] Status of ALTER TABLE
Hi Im new here. I was wondering if anybody is working on ALTER TABLE to make it more complete. More specifically drop constraints Sincerely Per-Olof Pettersson
[HACKERS] Re: UNDER?
Is UNDER being stripped out for 7.1? I'm looking at documentation and don't want to write about it if it won't be in there. Already gone. Check the recent archives for the discussion... - Thomas
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: That's my vote too, specially if there will be some regression tests accompanying the patches. The current (pre-patch) state of affairs with GiST could probably be described as security-by-obscurity anyhow i.e. "we have't tried it so we think it probably works" ;-) Au contraire, there *are* a few users of GiST out there now, Gene Selkov to name one. Yes, he is the only one (except Oleg) whom I know to use it too ;) So there is a definite risk of breaking things that worked in 7.0 and before, in the name of adding new features. True. Could we ask Gene to test 7.1 with Oleg's patches ? If I thought that we had adequate ability to test the new GiST implementation during the remaining beta period, I wouldn't be so worried. But at this point, Oleg's changes could not appear in the beta series before beta4, and between the late date, the lack of regression test, and the few interested people to test it, I doubt that we'll get any useful coverage. Or if in fact there _are_ only a few people using it now we could get _all_ the coverage to be sufficiently sure we don't break anyones code. GiST being such an obscure and underused feature I'm pretty sure that most (all?) active users are on Hackers list and read everything that has GiST in subject. I would recommend that Oleg do like Ryan K. did for awhile with the Alpha patches: make them available as a set of diffs to be applied to the official distribution. We'll be happy to merge them in for 7.2, but the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? Hannu
Re: [HACKERS] UNDER?
"Robert B. Easter" [EMAIL PROTECTED] writes: Is UNDER being stripped out for 7.1? It's history. regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Hannu Krosing [EMAIL PROTECTED] writes: ... the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? If he were submitting only bugfixes, we wouldn't be having this discussion. Look, I don't like postponing improvements either. But if we don't adhere to project management discipline, we are never going to get releases out the door at all --- or if we do, they'll be too buggy to be reliable. It's not like "no new features during beta" is such a draconian or difficult-to-understand rule. The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. regards, tom lane
Re: AW: [HACKERS] Re: tinterval - operator problems on AIX
I have machines running AIX 4.1.5, 4.2.1, and 4.3.3 if you would like to send me your test programs. I haven't yet actually fixed the code, but will post patches when I've done so (assuming that a fix is possible). - Thomas
RE: [HACKERS] Lock on arbitrary string feature
In contrast the current alternatives appear to be either LOCK the entire table (preventing ALL inserts and selects), SHARE ROW EXCLUSIVE mode doesn't prevent selects... or to create a UNIQUE constraint (forcing complete rollbacks and restarts in event of a collision :( ). Hopefully, savepoints will be in 7.2 Any comments, suggestions or tips would be welcome. It looks like quite a complex thing to do - I've only just started looking at the postgresql internals and the lock manager. It's very easy to do (from my PoV -:)) We need in yet another pseudo table like one we use in XactLockTableInsert/XactLockTableWait - try to look there... Vadim
Re: [HACKERS] drop table and pg_proc
Tatsuo Ishii [EMAIL PROTECTED] writes: Suppose a function using table t1 as its argument: create table t1(... create fuction f1(t1) returns... And if I drop t1 then do pg_dump, I would got something like: failed sanity check, type with oid 1905168 was not found This is because the type t1 does not exist anynmore. Since not being able to make a back up of database is a critical problem, I think we have to fix this. This is just one instance of the generic problem that we don't enforce referential integrity across system catalogs. Since this issue has always been there, I'm not inclined to panic about it (ie, I don't want to try to solve it for 7.1). But we should think about a long-term fix. 1) remove that proc entry from pg_proc if t1 is deleted 2) fix pg_dump so that it ignores sunch a bogus entry 3) do both 1) and 2) Ultimately we should probably do both. #2 looks easier and is probably the thing to work on first. In general, pg_dump is fairly brittle when it comes to missing cross-references, eg, I think it fails to even notice a table that has no corresponding owner in pg_shadow (it should be doing an outer not inner join for that). It'd be worth fixing pg_dump so that it issues warnings about such cases but tries to plow ahead anyway. regards, tom lane
Re: [HACKERS] Lock on arbitrary string feature
On Thu, Jan 11, 2001 at 03:43:39PM +0800, Lincoln Yeoh wrote: Hi, Has anyone any input to offer on adding an arbitrary locking feature? Where GETLOCK "string" will lock on "string", the lock being only released at the end of a transaction. While the lock is held, other processes trying to do GETLOCK "string" will block until the lock is released. This feature can allow applications to better serialize things. For example: inserting unique records. Cooperating applications could just do something like: GETLOCK "mytable.key2=1234"; SELECT count(*) from mytable where key2=1234 for update; if count==0, insert the stuff. elsif count==1 update the stuff instead else something is wrong! The lock will thus only affect applications interested in mytable where key2=1234 We do something like this with listen/notify pairs. To syncronize two clients, we have them each listen for the other's token string, send a notify, and then block on select(), checking for incoming notifications. When they get the notification, they send a notify back to the other side to un-block it. If anything, it would be nice if there were a way to make a LISTEN block the connection on a specific event tag, which is essentially what we are doing in our interface library. -- Adam Haberlach|A cat spends her life conflicted between a [EMAIL PROTECTED] |deep, passionate, and profound desire for http://www.newsnipple.com |fish and an equally deep, passionate, and '88 EX500 |profound desire to avoid getting wet.
RE: AW: [HACKERS] Re: GiST for 7.1 !!
The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. I mostly sure that Oleg' changes touch *only* gist subdir (Oleg?) so *nothing* will be broken in other areas. That's why I don't object new gist in 7.1. RelFileNodeEquals is quite another thing, thanks for fix again -:) Vadim
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: ... the calendar says it's too late for 7.1. Even for the _real_ bugfixes in gist.c ? If he were submitting only bugfixes, we wouldn't be having this discussion. But he had very little incentive to fix bugs in the version he would not use. Look, I don't like postponing improvements either. But if we don't adhere to project management discipline, But should we do that _blindly_? I'd think that improving/fixing things in seldom-visited corners of postgres should be a little more tolerable than messing around in core. we are never going to get releases out the door at all --- or if we do, they'll be too buggy to be reliable. It's not like "no new features during beta" is such a draconian or difficult-to-understand rule. I'd rather describe his changes as "a (bug)fix that required a major rewrite" ;) The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. BTW, What do people use for stress-testing ? Think about that for awhile before you campaign for inserting untested new features at this point. Rather new variants of little-tested features ;) We need to focus on TESTING, people, not new features. I make a personal promise to spend at least 5 hours of testing new GiST functionality during this weekend if it is commited to 7.1 CVS. (ok, I do it anyhow, just that currently I'm testing it using the patches ;) - Hannu
RE: [HACKERS] drop table and pg_proc
This is just one instance of the generic problem that we don't enforce referential integrity across system catalogs. Since this issue has Wouldn't be easy to do for views (rules) anyway - table oids are somewhere in the body of rule, they are not just keys in column. Also, triggers are handled by Executor and we don't use it for DDL statements. I think it's ok, we have just add "isdurty" column to some tables (to be setted when some of refferenced objects deleted/altered and to be used as flag that "re-compiling" is required) and new table to remember object relationships. Guys here, in Sectorbase, blames PostgreSQL a much for this thing -:) They are Oracle developers and development under PostgreSQL makes them quite unhappy. Probably, work in this area will be sponsored by my employer (with me as superviser and some guys in Russia as developers), we'll see. Vadim
RE: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Mikheev, Vadim wrote: The RelFileNodeEquals() bug we found on Monday proves that no one had yet done enough stress-testing on 7.1 to discover that multiple databases were broken. Think about that for awhile before you campaign for inserting untested new features at this point. We need to focus on TESTING, people, not new features. I mostly sure that Oleg' changes touch *only* gist subdir (Oleg?) Yes, and only one file - gist.c so *nothing* will be broken in other areas. That's why I don't object new gist in 7.1. We prepare regression test for RD-Tree in the same way as Gene does for his contribution. I put all files on http://www.sai.msu.su/~megera/postgres/gist/. btw, all Gene's test for seg and cube in contrib area are passed. It would be better Gene check his application himself. I'm sorry for trouble with my submission - I hoped we will be ready before beta2,3, but we spent too many time to get old insertion algoritm works with variable size keys until we realized it's just not suitable for this. I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Also, we found GiST part of postgres documentation is too short, so we'll try to contribute something sometime later. From other side, GiST was too hidden for people, while it's very powerfull feature and many people for sure really needs GiST power. Frankly speaking I discovered GiST power myself by accident :-) Now we have many plans to use GiST in our real life applications such as Web site management system, full text search (killer application !), data mining and others. There are several improvements and new features we plan to add to GiST which could be go to 7.2. 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: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Hannu Krosing wrote: I make a personal promise to spend at least 5 hours of testing new GiST functionality during this weekend if it is commited to 7.1 CVS. (ok, I do it anyhow, just that currently I'm testing it using the patches ;) Hanny, latest version is available at http://www.sai.msu.su/~megera/postgres/gist/ nothing changed in code (in compare with my submission), just added some info and regression test. Let me know if you need some help. Oleg - Hannu 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] Lock on arbitrary string feature
Tom Lane wrote: Lincoln Yeoh [EMAIL PROTECTED] writes: Has anyone any input to offer on adding an arbitrary locking feature? Where GETLOCK "string" will lock on "string", the lock being only released at the end of a transaction. Any comments, suggestions or tips would be welcome. It looks like quite a complex thing to do - I've only just started looking at the postgresql internals and the lock manager. A lock is basically an entry in a shared hash table, so you could implement this just by having a different kind of key (ie, the given string) for these sorts of locks. However, the whole thing strikes me as more of an ugly kluge than a clean solution to the real problem. If you're not using a UNIQUE constraint then you're relying on application logic to guarantee consistency, which is bad. If you do have a UNIQUE constraint and want to layer this sort of application lock on top of it, then you still have the problem of unexpected failures if some instance/portion of your application does inserts without remembering to get the application-level lock. So, as Vadim remarked, doing the insert and rolling back to a savepoint on failure would be a much better answer. You're right that it's ugly, but at least it'd be a temporary "solution" for the fact that we cannot catch exceptions in triggers yet. So the if/else logic will currently not work reliable in a trigger without beeing able to lock before the SELECT. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] #
[HACKERS] Overprotectiveness in DefineQueryRewrite?
I was just shown the following example: CREATE TABLE profile (haushaltseinkommen_pm numeric(22,2)); CREATE VIEW profile_view AS SELECT *, haushaltseinkommen_pm*12 AS haushaltseinkommen_pa FROM profile; 7.0.* pg_dump produces the following for the view: CREATE TABLE "profile_view" ( "haushaltseinkommen_pm" numeric(22,2), "haushaltseinkommen_pa" numeric ); CREATE RULE "_RETprofile_view" AS ON SELECT TO profile_view DO INSTEAD SELECT profile.haushaltseinkommen_pm, (profile.haushaltseinkommen_pm * '12'::"numeric") AS haushaltseinkommen_pa FROM profile; AFAICS this is perfectly legitimate, but both 7.0.* and current backends will reject the CREATE RULE with ERROR: select rule's target entry 2 has different size from attribute haushaltseinkommen_pa The problem here is that DefineQueryRewrite checks if (attr-atttypmod != resdom-restypmod) elog(ERROR, "select rule's target entry %d has different size from attribute %s", i, attname); where attr will have the default precision/scale for NUMERIC, as set up by the CREATE TABLE, but resdom will have -1 because that's what you're going to get from a numeric expression. (In the CREATE VIEW case, they both have -1, evidently because CREATE VIEW doesn't force a default NUMERIC precision to be inserted in the table definition. Not sure if that's OK or not.) I think we'd better fix this, else we will have problems reading 7.0 dump files. I can see two possible answers: 1. Remove this check entirely. 2. Allow the typmods to be different if one of them is -1. I'm not entirely sure which way to jump. The former seems simpler but might perhaps allow creation of bogus views --- any opinions? regards, tom lane
Re: [HACKERS] Install Failure [7.1beta2 tarballs]
Thomas Swan [EMAIL PROTECTED] writes: When trying to run initdb I get the following error: The program '/usr/bin/postgres' needed by initdb does not belong to PostgreSQL version 7.1beta2. Check your installation. Hm. Either install failed to overwrite the existing /usr/bin/postgres, or your compiled copy of the executable still has the beta1 version string (did you do "make clean" before rebuilding?) regards, tom lane
RE: [HACKERS] postgresql.conf and postgres options
1. There are some undocumented options which appear to relate to WAL: ... Is there any text anywhere to explain what these do? (Point me to that or some commented code, and I'll write a documentation patch.) I'll send description to you soon, thanks. Vadim
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Regards, Oleg regards, tom lane 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
[HACKERS] Java Classes
Can PostgreSQL 7.1 store java classes or objects?
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Oleg Bartunov wrote: On Thu, 11 Jan 2001, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: I understand Tom's arguments and respect his experience, so I think it's possible to put link to my page in 7.1 docs for people interested in GiST features. Bear in mind that I only have one core vote ;-). We've already had some private core discussion about whether to accept this patch now, and so far I think I'm outvoted. There are several Tom Lane, judge by your activity. You probably need several votes. Did I understand you to say that you'd added some regression tests for GiST? That would lessen my unhappiness a little bit ... Yes, we did. Currently all files are available from my page http://www.sai.msu.su/~megera/postgres/gist/ I could submit them to hackers list if CORE people got consensus Okay, if there are appropriate regression tests, I'm going to say go for it ... Does anyone have any objections to my downloading the tar file (doing that now), committing the changes and wrapping up a quick Beta4 just so that we have a tar ball that is testable right away? Save Lamar and the other packagers a bit of work by avoiding beta3 packages :)
Re: [HACKERS] PostgreSQL v7.1BETA3 Bundled and Available ...
The Hermit Hacker writes: Due to the large number of changes made since Beta1 was released, we have included a Changelog file detailing all changes, that is viewable in the ChangeLogs subdirectory. Shouldn't that be in the HISTORY file? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Install Failure [7.1beta2 tarballs]
Thomas Swan writes: When trying to run initdb I get the following error: The program '/usr/bin/postgres' needed by initdb does not belong to PostgreSQL version 7.1beta2. Check your installation. If you are updating your sources via 'cvs update' you should do 'make clean' before recompilation, or configure with '--enable-depend' next time. Most likely the postgres program still thinks it's beta1. (Try --version.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
just downloaded it and can't find any regression tests ... ?
it's in the contrib-intarray.tar.gz
gmake, gmake install, gmake installcheck
Oleg
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
I understand Tom's arguments and respect his experience, so I think it's
possible to put link to my page in 7.1 docs for people interested in
GiST features.
Bear in mind that I only have one core vote ;-). We've already had some
private core discussion about whether to accept this patch now, and so
far I think I'm outvoted.
There are several Tom Lane, judge by your activity. You probably need
several votes.
Did I understand you to say that you'd added some regression tests for
GiST? That would lessen my unhappiness a little bit ...
Yes, we did. Currently all files are available from my page
http://www.sai.msu.su/~megera/postgres/gist/
I could submit them to hackers list if CORE people got consensus
Okay, if there are appropriate regression tests, I'm going to say go for
it ...
Does anyone have any objections to my downloading the tar file (doing that
now), committing the changes and wrapping up a quick Beta4 just so that we
have a tar ball that is testable right away?
Save Lamar and the other packagers a bit of work by avoiding beta3
packages :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
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] postgresql.conf and postgres options
Oliver Elphick writes: 2. The following command line options to postgres don't have an equivalent in postgresql.conf. Is that intentional? (I suppose it is in several cases, and I have left out some where it is obviously intentional.) I can't see why these items can't be put in the configuration file: -C Noversion = true [not documented in postgres man page] This option doesn't do anything. -D potential_Datadir = arg [set PGDATA] This option can't be in the config file because it is used to *find* the config file. -E EchoQuery = true [echo queries to log] Hmm, there's debug_print_query. This will probably be consolidated in the future. -e EuroDates = true [use European format for dates] This should be a config file option, but Thomas Lockhart couldn't make up his mind what to call it. ;-) -N UseNewLine = 0 [newline is not a query separator] I don't think this is useful. -o [set stdout, stderr to file arg] I think this is broken or not well maintained. Will be cleaned up in some later release. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PostgreSQL v7.1BETA3 Bundled and Available ...
The Hermit Hacker writes: ChangeLogs is meant to be more detailed then HISTORY, for those that would like to see results similar to 'cvs log', but without cvs access ... In that case it would be more useful (and customary) to put the complete ChangeLog (since the beginning of time) into *one* file called 'ChangeLog'. (The version bumps will be apparent since some file will be changed to reflect it.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] PostgreSQL v7.1BETA3 Bundled and Available ...
On Fri, 12 Jan 2001, Peter Eisentraut wrote: The Hermit Hacker writes: ChangeLogs is meant to be more detailed then HISTORY, for those that would like to see results similar to 'cvs log', but without cvs access ... In that case it would be more useful (and customary) to put the complete ChangeLog (since the beginning of time) into *one* file called 'ChangeLog'. (The version bumps will be apparent since some file will be changed to reflect it.) Thought of that, tried it, the resultant file was *humongous* with all of the TODO changes and such ... what I included was a cvs2cl.pl of just those changes since REL7_1 was tag'd, with a manual cleaning of the "TODO updated" lines ...
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
just downloaded it and can't find any regression tests ... ?
it's in the contrib-intarray.tar.gz
gmake, gmake install, gmake installcheck
erk, can we get this somehow done in such a way that its part of the
*standard* regression tests? so when ppl do 'make test', the GiST stuff
is checked also? My worry, as with others, isn't that GiST itself is
broken by the changes, its that *somehow* there is an interaction that is
with the rest of the system that isn't being tested ...
Oleg
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
I understand Tom's arguments and respect his experience, so I think it's
possible to put link to my page in 7.1 docs for people interested in
GiST features.
Bear in mind that I only have one core vote ;-). We've already had some
private core discussion about whether to accept this patch now, and so
far I think I'm outvoted.
There are several Tom Lane, judge by your activity. You probably need
several votes.
Did I understand you to say that you'd added some regression tests for
GiST? That would lessen my unhappiness a little bit ...
Yes, we did. Currently all files are available from my page
http://www.sai.msu.su/~megera/postgres/gist/
I could submit them to hackers list if CORE people got consensus
Okay, if there are appropriate regression tests, I'm going to say go for
it ...
Does anyone have any objections to my downloading the tar file (doing that
now), committing the changes and wrapping up a quick Beta4 just so that we
have a tar ball that is testable right away?
Save Lamar and the other packagers a bit of work by avoiding beta3
packages :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
just downloaded it and can't find any regression tests ... ?
it's in the contrib-intarray.tar.gz
gmake, gmake install, gmake installcheck
erk, can we get this somehow done in such a way that its part of the
*standard* regression tests? so when ppl do 'make test', the GiST stuff
is checked also? My worry, as with others, isn't that GiST itself is
broken by the changes, its that *somehow* there is an interaction that is
with the rest of the system that isn't being tested ...
No way, we need to load functions. there are several contributions
which depends on loaded functions. If you suggest how to do this
in general way, it would fine. To test GiST you need to define some
data structure ( in our case - RD-tree) and functions to access it
Oleg
On Thu, 11 Jan 2001, The Hermit Hacker wrote:
On Fri, 12 Jan 2001, Oleg Bartunov wrote:
On Thu, 11 Jan 2001, Tom Lane wrote:
Oleg Bartunov [EMAIL PROTECTED] writes:
I understand Tom's arguments and respect his experience, so I think it's
possible to put link to my page in 7.1 docs for people interested in
GiST features.
Bear in mind that I only have one core vote ;-). We've already had some
private core discussion about whether to accept this patch now, and so
far I think I'm outvoted.
There are several Tom Lane, judge by your activity. You probably need
several votes.
Did I understand you to say that you'd added some regression tests for
GiST? That would lessen my unhappiness a little bit ...
Yes, we did. Currently all files are available from my page
http://www.sai.msu.su/~megera/postgres/gist/
I could submit them to hackers list if CORE people got consensus
Okay, if there are appropriate regression tests, I'm going to say go for
it ...
Does anyone have any objections to my downloading the tar file (doing that
now), committing the changes and wrapping up a quick Beta4 just so that we
have a tar ball that is testable right away?
Save Lamar and the other packagers a bit of work by avoiding beta3
packages :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
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] PostgreSQL v7.1BETA3 Bundled and Available ...
The Hermit Hacker writes: ChangeLogs is meant to be more detailed then HISTORY, for those that would like to see results similar to 'cvs log', but without cvs access ... In that case it would be more useful (and customary) to put the complete ChangeLog (since the beginning of time) into *one* file called 'ChangeLog'. (The version bumps will be apparent since some file will be changed to reflect it.) Thought of that, tried it, the resultant file was *humongous* with all of the TODO changes and such ... what I included was a cvs2cl.pl of just those changes since REL7_1 was tag'd, with a manual cleaning of the "TODO updated" lines ... Those that like to see something similar to 'cvs log' are surely not interested into just the changes since beta 1 but at least since the branch from 7.0. If we're going to have a new changelog file for each subrelease-to-subrelease then it's not going to be useful. Maybe make ChangeLog_7_1, later ChangeLog_7_2, then ChangeLog_7_3 and remove ChangeLog_7_1, so you make a reasonable compromise between storage space and preserving the traditional nature and functionality of ChangeLogs. Should be under doc/ too, I think. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
RE: AW: [HACKERS] Re: GiST for 7.1 !!
erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Vadim
RE: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Mikheev, Vadim wrote: erk, can we get this somehow done in such a way that its part of the *standard* regression tests? so when ppl do 'make test', the GiST stuff is checked also? My worry, as with others, isn't that GiST itself is broken by the changes, its that *somehow* there is an interaction that is with the rest of the system that isn't being tested ... No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Thanks Vadim for tips. Will do this way, but tommorow. It's 3:19 am already and I have to sleep :-) Vadim 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: AW: [HACKERS] Re: GiST for 7.1 !!
Oleg Bartunov [EMAIL PROTECTED] writes: No way, we need to load functions. there are several contributions which depends on loaded functions. If you suggest how to do this in general way, it would fine. To test GiST you need to define some data structure ( in our case - RD-tree) and functions to access it Look at regress/input/create_function_1.source for hints from SPI tests... Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? regards, tom lane
RE: AW: [HACKERS] Re: GiST for 7.1 !!
Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Ops, agreed. And I fear that in current code there is no one GiST index implementation -:( Should we worry about regress tests? -:) Vadim
Re: [HACKERS] A post-7.1 wish-list.
Another "obvious solution" (delegating the use of the thesaurus to the client application) is also a non-solution : how do you join your data and the thesaurus data ? The usual way as in any relational data base: by referencing the information. That makes the client application a relational RDBMS with capability to access more than one database at a time. This was MS Access for us, up until now. And I would *love* to get rid of it ... The ability to "attach" (MS-Access parlance) a table or a view from another database is quite helpful. And I think that it has a lot of applications outside my (quite limited) realm. It is quite disastrous for referential integrity. Would you please amplify ? You might have a point, but I do not (yet) see it. -- Emmanuel Charpentier definitely isolating different databases is a non-practical idea, how can you image things will be changed in future? do you believe that you'll never reference data in other databases? it sound likes that you are still in 80's, in that time, PC are mostly not connected together via Network, when we need migrate data to another PC, we should use floppy :(, this time I should use the barbarism method again --- dump table to a file then load the file to another database even they are on same server! maybe I should write a stupid program to do task periodically. Regards, XuYifeng
RE: [HACKERS] Lock on arbitrary string feature
At 09:20 AM 11-01-2001 -0800, Mikheev, Vadim wrote: In contrast the current alternatives appear to be either LOCK the entire table (preventing ALL inserts and selects), SHARE ROW EXCLUSIVE mode doesn't prevent selects... Sorry, I meant all inserts and selects on the locked table. At least so far it seems to block those selects in 7.0.3 (I hope it does in all cases! If not uhoh!). or to create a UNIQUE constraint (forcing complete rollbacks and restarts in event of a collision :( ). Hopefully, savepoints will be in 7.2 Yep that'll solve some things. Still think the getlock feature will be very handy in many other cases. BTW would there be a significant performance/resource hit with savepoints? Any comments, suggestions or tips would be welcome. It looks like quite a complex thing to do - I've only just started looking at the postgresql internals and the lock manager. It's very easy to do (from my PoV -:)) We need in yet another pseudo table like one we use in XactLockTableInsert/XactLockTableWait - try to look there... Thanks! I think by the time I succeed Postgresql will be version 7.2 or even 8 :). Cheerio, Link.
Re: [HACKERS] Lock on arbitrary string feature
At 01:26 PM 11-01-2001 -0500, Tom Lane wrote: Lincoln Yeoh [EMAIL PROTECTED] writes: GETLOCK "string" will lock on "string", the lock being only released at the end of a transaction. However, the whole thing strikes me as more of an ugly kluge than a clean solution to the real problem. If you're not using a UNIQUE But doesn't that go well with SQL :). The joys of INSERT vs UPDATE. And "select .. for update" too! So far I haven't left out any "for updates", at least I think so ;). I did consider using select for update to simulate it but it doesn't work when the values are very variable. application-level lock. So, as Vadim remarked, doing the insert and rolling back to a savepoint on failure would be a much better answer. Yep, savepoints will allow better consistency. But a getlock feature can be very handy in lots of other scenarios. BTW, you should consider whether you couldn't use the existing USERLOCK feature as a short-term alternative. If you can squeeze the key value you need to insert into a user lock tag, that will do as well as your proposed general-string-tag locks. Looks interesting. Probably what it does is similar enough to what I'm trying to do. Copy from the best :). But meantime, back to lock table... Cheerio, Link.
[HACKERS] alter table drop column
I read the transcript of the alter table drop column discussion (old discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop, and I have something to add: People mentioned such ideas as a hidden column and a really deleted column, and it occurred to me that perhaps "vacuum" would be a good option to use. When a delete was issued, the column would be hidden (by a negative/invalid logical column number, it appears was the consensus). Upon issuing a vacuum, it could perform a complete deletion. This method would allow users to know that the process may take a while (I think the agreed method for a complete delete was to "select into..." the right columns and leave out the deleted ones, then delete the old table). Furthermore, I liked the idea of some kind of "undelete", as long as it was just hidden. This could apply to anything that is cleaned out with a vacuum (before it is cleaned out), although I am not sure how feasible this is, and it isn't particularly important to me. Regards, Jeff -- Jeff Davis Dynamic Works [EMAIL PROTECTED] http://dynworks.com
[HACKERS] CRCs (was Re: [GENERAL] Re: Loading optimization)
"Mikheev, Vadim" [EMAIL PROTECTED] writes: Actually, I'd expect the CRC check to catch an all-zeroes page (if it fails to complain, then you misimplemented the CRC), so that would be the place to deal with it now. I've used standard CRC32 implementation you pointed me to -:) But CRC is used in WAL records only. Oh. I thought we'd agreed that a CRC on each stored disk block would be a good idea as well. I take it you didn't do that. Do we want to consider doing this (and forcing another initdb)? Or shall we say "too late for 7.1"? regards, tom lane
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Um, you do realize that a contrib module that gets used as part of the regress tests may as well be mainstream? At least in terms of the portability requirements it will have to meet? I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. But that was 7.0. (autoinc and refint.). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Re: Lock on arbitrary string feature
At 09:38 AM 11-01-2001 -0800, Adam Haberlach wrote: We do something like this with listen/notify pairs. To syncronize two clients, we have them each listen for the other's token string, send a notify, and then block on select(), checking for incoming notifications. When they get the notification, they send a notify back to the other side to un-block it. If anything, it would be nice if there were a way to make a LISTEN block the connection on a specific event tag, which is essentially what we are doing in our interface library. Actually what you are talking about is almost an inverse of this locking thing. One is stop until it's ok to go. The other is stop if it's not ok to go. You're looking for a WAIT for "notification" feature :). I actually was looking for this too, and I thought I was the only one interested in this. Wow a 100% increase in interest ;). I'm also trying to see how this can be done. It looks a lot easier to do than the getlock feature. But I can't figure out what to select/wait/snooze on, when the routine is in the inside looking about (async.c: Async_Wait(char *relname) yeah oxymoronic I know). Rather than outside looking in (in which case it's select PQsocket or something like that). Would like to use as little CPU as possible when waiting - think of postgresql on battery powered wearable "servers" + wireless LAN. Cheerio, Link.
Re: AW: [HACKERS] Re: GiST for 7.1 !!
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. Sure, but they've been there awhile. All of my concerns here are schedule-driven: do we really want to be wringing out a new contrib module, to the point where it will run everywhere, before we can release 7.1? Are the benefits worth the effort? Can the current GiST developers pull it off in time? If the answer to either question is not a resounding YES then we really don't need to go down this road. Either leave it in contrib and regression testless (with a test script in the contrib), or make it a feature patch. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: AW: [HACKERS] Re: GiST for 7.1 !!
On Thu, 11 Jan 2001, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I'm unhappy again. Bad enough we accepted a new feature during beta; now we're going to expect an absolutely virgin contrib module to work everywhere in order to pass regress tests? Last I checked, two contrib modules had to be built for regression testing. Sure, but they've been there awhile. All of my concerns here are schedule-driven: do we really want to be wringing out a new contrib module, to the point where it will run everywhere, before we can release 7.1? Hrmmm ... just a thought here, but how about a potential 'interactive' regression test, where it asks if you want to run regress on GiST? If so, do it, if not, ignore it ... ?
[HACKERS] Pg7.1beta3: FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock.
what happens? valter. [i've done vacuum analyze while query are running... vacuum stopped at some point, then i've decided to ctrl-c, then killed postmaster] - postgres@lora:~$ /usr/pg71/bin/pg_ctl -D /usr/pg71/data/ stop Smart Shutdown request at Fri Jan 12 05:46:11 2001 postmaster successfully shut down. postgres@lora:~$ /usr/pg71/bin/pg_ctl -D /usr/pg71/data/ start pg_ctl: It seems another postmaster is running. Trying to start postmaster anyway. Lock file "/usr/pg71/data//postmaster.pid" already exists. Is another postmaster (pid 11320) running in "/usr/pg71/data/"? pg_ctl: Cannot start postmaster. Is another postmaster is running? postgres@lora:~$ /usr/pg71/bin/pg_ctl -D /usr/pg71/data/ restart Waiting for postmaster to shut down. FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock. Aborting. FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock. Aborting. Startup failed - abort done. postmaster successfully shut down. postmaster successfully started up postgres@lora:~$ /usr/pg71/bin/postmaster: invalid argument -- '-D' Try '/usr/pg71/bin/postmaster --help' for more information. postgres@lora:~$ /usr/pg71/bin/pg_ctl -D /usr/pg71/data/ start postmaster successfully started up postgres@lora:~$ DEBUG: starting up DEBUG: database system was interrupted being in recovery at 2001-01-12 05:45:33 This propably means that some data blocks are corrupted and you will have to use last backup for recovery. DEBUG: CheckPoint record at (0, 107606368) DEBUG: Redo record at (0, 107467584); Undo record at (0, 107484188); Shutdown FALSE DEBUG: NextTransactionId: 46738; NextOid: 59680 DEBUG: database system was not properly shut down; automatic recovery in progress... DEBUG: redo starts at (0, 107467584) FATAL 2: out of free buffers: time to abort ! postgres@lora:~$ postgres@lora:~$ FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock. Aborting. FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock. Aborting. Startup failed - abort _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
[HACKERS] Bruce Momjian's interview in LWN.
In Linux Weekly News, an Interview with Bruce (from Nov 30): http://lwn.net/2001/features/Momjian/ :-) Go get'em, Bruce -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Pg7.1beta3: FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock.
Some of the noise here is coming from the fact that you didn't wait for
the old postmaster to quit before you tried to start another. ("pg_ctl
stop" doesn't wait unless you say -w ... there's been some talk of
reversing that default ...)
However, it still looks like you had other problems. What sort of
platform is this on? Do the regression tests pass for you?
regards, tom lane
Re: [HACKERS] Pg7.1beta3: FATAL: s_lock(0x401f7010) at spin.c:147, stuck spinlock.
Architecture and regression.diffs:
valter.
-
valter@lora:$ uname -a:
Linux lorax 2.2.17 #3 Mon Oct 2 23:11:04 UTC 2000 i686 unknown
-
valter@lora:$ less
./src/test/regress/regression.diffs
*** ./expected/random.out Thu Jan 6 06:40:54 2000
--- ./results/random.outFri Jan 12 06:18:18 2001
***
*** 25,31
GROUP BY random HAVING count(random) 1;
random | count
+---
! (0 rows)
SELECT random FROM RANDOM_TBL
WHERE random NOT BETWEEN 80 AND 120;
--- 25,32
GROUP BY random HAVING count(random) 1;
random | count
+---
! 103 | 2
! (1 row)
SELECT random FROM RANDOM_TBL
WHERE random NOT BETWEEN 80 AND 120;
==
From: Tom Lane [EMAIL PROTECTED]
To: "Valter Mazzola" [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Pg7.1beta3: FATAL: s_lock(0x401f7010) at spin.c:147,
stuck spinlock.
Date: Thu, 11 Jan 2001 23:08:14 -0500
Some of the noise here is coming from the fact that you didn't wait for
the old postmaster to quit before you tried to start another. ("pg_ctl
stop" doesn't wait unless you say -w ... there's been some talk of
reversing that default ...)
However, it still looks like you had other problems. What sort of
platform is this on? Do the regression tests pass for you?
regards, tom lane
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: [HACKERS] drop table and pg_proc
Add to TODO: * Enforce referential integrity for system tables Tatsuo Ishii [EMAIL PROTECTED] writes: Suppose a function using table t1 as its argument: create table t1(... create fuction f1(t1) returns... And if I drop t1 then do pg_dump, I would got something like: failed sanity check, type with oid 1905168 was not found This is because the type t1 does not exist anynmore. Since not being able to make a back up of database is a critical problem, I think we have to fix this. This is just one instance of the generic problem that we don't enforce referential integrity across system catalogs. Since this issue has always been there, I'm not inclined to panic about it (ie, I don't want to try to solve it for 7.1). But we should think about a long-term fix. 1) remove that proc entry from pg_proc if t1 is deleted 2) fix pg_dump so that it ignores sunch a bogus entry 3) do both 1) and 2) Ultimately we should probably do both. #2 looks easier and is probably the thing to work on first. In general, pg_dump is fairly brittle when it comes to missing cross-references, eg, I think it fails to even notice a table that has no corresponding owner in pg_shadow (it should be doing an outer not inner join for that). It'd be worth fixing pg_dump so that it issues warnings about such cases but tries to plow ahead anyway. 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] alter table drop column
Added to TODO.detail/drop. [ Charset ISO-8859-1 unsupported, converting... ] I read the transcript of the alter table drop column discussion (old discussion) at http://www.postgresql.org/docs/pgsql/doc/TODO.detail/drop, and I have something to add: People mentioned such ideas as a hidden column and a really deleted column, and it occurred to me that perhaps "vacuum" would be a good option to use. When a delete was issued, the column would be hidden (by a negative/invalid logical column number, it appears was the consensus). Upon issuing a vacuum, it could perform a complete deletion. This method would allow users to know that the process may take a while (I think the agreed method for a complete delete was to "select into..." the right columns and leave out the deleted ones, then delete the old table). Furthermore, I liked the idea of some kind of "undelete", as long as it was just hidden. This could apply to anything that is cleaned out with a vacuum (before it is cleaned out), although I am not sure how feasible this is, and it isn't particularly important to me. Regards, Jeff -- Jeff Davis Dynamic Works [EMAIL PROTECTED] http://dynworks.com -- 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] CRCs (was Re: [GENERAL] Re: Loading optimization)
"Mikheev, Vadim" [EMAIL PROTECTED] writes: Actually, I'd expect the CRC check to catch an all-zeroes page (if it fails to complain, then you misimplemented the CRC), so that would be the place to deal with it now. I've used standard CRC32 implementation you pointed me to -:) But CRC is used in WAL records only. Oh. I thought we'd agreed that a CRC on each stored disk block would be a good idea as well. I take it you didn't do that. No, I thought we agreed disk block CRC was way overkill. If the CRC on the WAL log checks for errors that are not checked anywhere else, then fine, but I thought disk CRC would just duplicate the I/O subsystem/disk checks. -- 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] Bruce Momjian's interview in LWN.
I announced this on Announce/General a few hours ago. I wanted to mention that all general PostgreSQL news goes to those two lists, on the assumption that all people are subscribed to either of those two lists. I don't post to hackers by default because I don't want to duplicate these postings. In Linux Weekly News, an Interview with Bruce (from Nov 30): http://lwn.net/2001/features/Momjian/ :-) Go get'em, Bruce -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- 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] Pg7.1beta3: connect failed: The DB System is starting up.
With Apache Mod Perl, Apache::DBI, stress test with apache bench (ab -n 10 -c 4) in apache error_log i've got: [Pg7.1beta3 with standard conf files.] .. [Fri Jan 12 07:48:58 2001] [error] DBI-connect(dbname=mydb) failed: The Data Base System is starting up Architecture: Linux 2.2.17 #3 Mon Oct 2 23:11:04 UTC 2000 i686 unknown Also messages: "DB in recovery ...". What is the problem? In pg7.0.2 it's all ok. valter _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: [GENERAL] Java Classes
[EMAIL PROTECTED] wrote: Can PostgreSQL 7.1 store java classes or objects? Sure it can, but not automatically. just serialize your object to a byte array and store that String. -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com
Re: [HACKERS] CRCs (was Re: [GENERAL] Re: Loading optimization)
Bruce Momjian [EMAIL PROTECTED] writes: Oh. I thought we'd agreed that a CRC on each stored disk block would be a good idea as well. I take it you didn't do that. No, I thought we agreed disk block CRC was way overkill. If the CRC on the WAL log checks for errors that are not checked anywhere else, then fine, but I thought disk CRC would just duplicate the I/O subsystem/disk checks. A disk-block CRC would detect partially written blocks (ie, power drops after disk has written M of the N sectors in a block). The disk's own checks will NOT consider this condition a failure. I'm not convinced that WAL will reliably detect it either (Vadim?). Certainly WAL will not help for corruption caused by external agents, away from any updates that are actually being performed/logged. regards, tom lane
Re: [HACKERS] CRCs (was Re: [GENERAL] Re: Loading optimization)
At 21:55 11/01/01 -0500, Tom Lane wrote: Oh. I thought we'd agreed that a CRC on each stored disk block would be a good idea as well. I take it you didn't do that. Do we want to consider doing this (and forcing another initdb)? Or shall we say "too late for 7.1"? I thought it was coming too. I'd like to see it - if it's not too hard in this release. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] CRCs (was Re: [GENERAL] Re: Loading optimization)
No, I thought we agreed disk block CRC was way overkill. If the CRC on the WAL log checks for errors that are not checked anywhere else, then fine, but I thought disk CRC would just duplicate the I/O subsystem/disk checks. A disk-block CRC would detect partially written blocks (ie, power drops after disk has written M of the N sectors in a block). The disk's own checks will NOT consider this condition a failure. I'm not convinced that WAL will reliably detect it either (Vadim?). Certainly WAL will Idea proposed by Andreas about "physical log" is implemented! Now WAL saves whole data blocks on first after checkpoint modification. This way on recovery modified data blocks will be first restored *as a whole*. Isn't it much better than just detection of partially writes? Only one type of modification isn't covered at the moment - updated t_infomask of heap tuples. not help for corruption caused by external agents, away from any updates that are actually being performed/logged. What do you mean by "external agents"? Vadim
[HACKERS] Re: CRCs (was Re: [GENERAL] Re: Loading optimization)
But CRC is used in WAL records only. Oh. I thought we'd agreed that a CRC on each stored disk block would be a good idea as well. I take it you didn't do that. Do we want to consider doing this (and forcing another initdb)? Or shall we say "too late for 7.1"? I personally was never agreed to this. Reasons? Vadim
