Re: [HACKERS] Re: int8 beta5 broken?
On Wed, 28 Feb 2001, Tom Lane wrote: Olivier PRENANT [EMAIL PROTECTED] writes: Sorry to follow-up on my own post; int8 test passes if open-ssl is not used. That's difficult to believe, because int8.c doesn't include anything that even knows SSL exists. Larry, can you confirm this behavior? Hi, I've been testing a little more further and found that (with-openssl) if initdb is done with LANG=C, int8 test succeeds if initdb is done with LANG=fr int8 test fails. I'll try nowwithout openssl and LANG=fr Regards regards, tom lane -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery)
Re: AW: [HACKERS] Uh, this is *not* a 64-bit CRC ...
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: it's certainly not what I thought we had agreed to implement. Hmm, strange. I thought that we had agreed upon a 32 bit CRC on the grounds, that it would be strong enough to guard a single log record. I thought that, and still think it, but I was outvoted. However I see no value in the present actual implementation ... regards, tom lane
[HACKERS] Current ODBC driver(s) problems with 7.1
Dear list, I have made some progress about the current state of the ODBC drivers. I have tried three ODBC drivers : The original ODBC river, as compiled by Oliver Elphick in the Debian 7.1beta4 packages : this one is utterly broken : trying to use it leads to nothing : no activity is loged neither in syslog nor in postgres.log with -d2. Nick Gorham says it's because the driver and the driver manager wait mutually for each other, IIRC. The same driver patched (how ?) by Nick Gorham has some basic functionality : it can query the DB in arbitrary ways and is able to do other basic things. However, it has other problems. It displays only tables, not views, and has some serious limitations on system tables. Nick Gorham's unixODBC driver. This ione has only basic functionality : it can connect and query the backend, but only with a hand-crafted query. No way to get the list of tables, nor metadata. In the first case, I can do nothing : I'm reluctant to try to rebuild the Debian packages from source (I don't kniow how to do this from the sources and Oliver's patches). It follows that I can't do that for the second either. However, the problems exhibited by the second and third drivers are of the same nature : the SQL queries sent by them to get thje metadata are no longer valid for 7.1, since the system tables have undergo a lot of changes. I will try to fix the third and publish my result and changes, hoping to see them ported on the first one. Any thoughs ? And, BTW, where can I find the docs of the 7.0 system tables ? I know where the 7.1 docs are ... Sincerely yours, Emmanuel Charpentier
[HACKERS] WAL's single point of failure: latest CHECKPOINT record
As the WAL stuff is currently constructed, the system will refuse to start up unless the checkPoint field of pg_control points at a valid checkpoint record in the WAL log. Now I know we write and fsync the checkpoint record before we rewrite pg_control, but this still leaves me feeling mighty uncomfortable. See past discussions about how fsync order doesn't necessarily mean anything if the disk drive chooses to reorder writes. Since loss of the checkpoint record means complete loss of the database, I think we need to work harder here. What I'm thinking is that pg_control should have pointers to the last two checkpoint records, not only the last one. If we fail to read the most recent checkpoint, try the one before it (which, obviously, means we must keep the log files long enough that we still have that one too). We can run forward from there and redo the intervening WAL records the same as we would do anyway. This would mean an initdb to change the format of pg_control. However I already have a couple other reasons in favor of an initdb: the record-length bug I mentioned yesterday, and the bogus CRC algorithm. I'm not finished reviewing the WAL code, either :-( regards, tom lane
Re: [HACKERS] jdbc driver hack
At 06:15 25/02/01 -0500, Ola Sundell wrote: Hello. I have made a small contribution to the JDBC driver, in the JDBC v2.0 stuff. Whom do I send it to? The JDBC list is the best place (which I've seen you already have). PS: I'm replying this only to get this into the mail archives ;-) Peter Ola --- Ola Sundell [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://miranda.org/~ola PGP key information: pub 1024/744E6D8D 2000/02/13 Ola Sundell [EMAIL PROTECTED] Key fingerprint = 8F CA 7C 6F EC 0D C0 23 1E 08 BF 32 FC 37 24 E3
Re: [HACKERS] Release in 2 weeks ...
At 11:52 26/02/01 -0400, The Hermit Hacker wrote: Morning all ... Are there any major outstandings that ppl have on their plates, that should prevent a release? I'd like to put out an RC1 by Friday this week, with a full release schedualed for March 15th ... this would give Thomas his two weeks for the docs freeze ... It will also give me a little extra time. This week has been a tad busy work wise for me I've not been able to do anything at all (only now have I been able to find time to download the 800 emails that were waiting for me :-( ) Basically, RC1 would say to ppl that we're ready to release, there will be no more core changes that will require an initdb ... feel comfortable using this version in production, with the only major changes between now and release being docs related ... Does this work? Or is there something earth-shattering that still has to be done? Not on my front except: JDBC1.2 driver needs testing (still can't get JDK1.1.8 to install here). The JDBC 2.1 Enterprise Edition driver also needs some testing. The JDBC2.1 Standard Edition driver is ready. Some new patches to look at. PS: Did you know we are only 1 thing short of being JDBC compliant with the JDBC2.1 SE driver? The other not implemented bits are extras not technically (according to the spec) needed for compliance. But then there's not many of them either (about 11 at last count excluding CallableStatement - which isn't required which I was surprised about when I check it last weekend). Peter
[HACKERS] contrib: retep - empty documentation files
7.1beta5 in contrib/retep: Implementation and README are both empty. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD is my shepherd; I shall not want. He maketh me to lie down in green pastures: he leadeth me beside the still waters, he restoreth my soul...Surely goodness and mercy shall follow me all the days of my life; and I will dwell in the house of the LORD for ever."Psalms 23:1,2,6
Re: [HACKERS] Release in 2 weeks ...
At 17:54 27/02/01 +0100, Peter Eisentraut wrote: The Hermit Hacker writes: Are there any major outstandings that ppl have on their plates, that should prevent a release? I'd like to put out an RC1 by Friday this week, with a full release schedualed for March 15th ... this would give Thomas his two weeks for the docs freeze ... I'm interested to know what exactly takes two weeks with the docs and what could be done to speed it up. Isn't it the typsetting for the postscript/pdf docs? docbook doesn't handle tables too well in those cases and its easier to do them by hand? Peter -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Current ODBC driver(s) problems with 7.1
Emmanuel Charpentier wrote: I have tried three ODBC drivers : The original ODBC river, as compiled by Oliver Elphick in the Debian 7.1beta4 packages : this one is utterly broken : trying to use it leads to nothing : no activity is loged neither in syslog nor in postgres.log with -d2. Nick Gorham says it's because the driver and the driver manager wait mutually for each other, IIRC. I have been trying it; I get a segfault (7.1beta4), but haven't yet been able to determine the cause. Has anyone got any hints on debugging shared libraries? ... In the first case, I can do nothing : I'm reluctant to try to rebuild the Debian packages from source (I don't kniow how to do this from the sources and Oliver's patches). It follows that I can't do that for the second either. I make no changes to the ODBC library. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD is my shepherd; I shall not want. He maketh me to lie down in green pastures: he leadeth me beside the still waters, he restoreth my soul...Surely goodness and mercy shall follow me all the days of my life; and I will dwell in the house of the LORD for ever."Psalms 23:1,2,6
[HACKERS] Empty queries in src/test/bench
The following files are empty: ./src/test/bench/query21 ./src/test/bench/query22 ./src/test/bench/query24 ./src/test/bench/query25 Is that intentional? (I see they have been that way for 4 years.) -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD is my shepherd; I shall not want. He maketh me to lie down in green pastures: he leadeth me beside the still waters, he restoreth my soul...Surely goodness and mercy shall follow me all the days of my life; and I will dwell in the house of the LORD for ever."Psalms 23:1,2,6
[HACKERS] Re: contrib: retep - empty documentation files
At 20:37 01/03/01 +, Oliver Elphick wrote: 7.1beta5 in contrib/retep: Implementation and README are both empty. Hmmm, not sure what happened there. I'm committing in more of the retep contrib stuff over the weekend, so I'll fix them then. Peter -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "The LORD is my shepherd; I shall not want. He maketh me to lie down in green pastures: he leadeth me beside the still waters, he restoreth my soul...Surely goodness and mercy shall follow me all the days of my life; and I will dwell in the house of the LORD for ever."Psalms 23:1,2,6
Re: [HACKERS] WAL's single point of failure: latest CHECKPOINT record
We really need point-in-time recovery, removal of the need to vacuum, and more full-featured replication. Hopefully most can be addressed in 7.2. Hi all, Out of curiosity, does anyone know of any projects that are presently creating PostgreSQL database recovery tools? For example database corruption recovery, Point In Time restoration, and such things? It might be a good project for GreatBridge to look into if no-one else is doing it already. Regards and best wishes, Justin Clift Database Administrator Tom Lane wrote: As the WAL stuff is currently constructed, the system will refuse to start up unless the checkPoint field of pg_control points at a valid checkpoint record in the WAL log. Now I know we write and fsync the checkpoint record before we rewrite pg_control, but this still leaves me feeling mighty uncomfortable. See past discussions about how fsync order doesn't necessarily mean anything if the disk drive chooses to reorder writes. Since loss of the checkpoint record means complete loss of the database, I think we need to work harder here. What I'm thinking is that pg_control should have pointers to the last two checkpoint records, not only the last one. If we fail to read the most recent checkpoint, try the one before it (which, obviously, means we must keep the log files long enough that we still have that one too). We can run forward from there and redo the intervening WAL records the same as we would do anyway. This would mean an initdb to change the format of pg_control. However I already have a couple other reasons in favor of an initdb: the record-length bug I mentioned yesterday, and the bogus CRC algorithm. I'm not finished reviewing the WAL code, either :-( 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
[HACKERS] 7.2 tools (was: WAL's single point of failure: latest CHECKPOINT record)
Yes, there is backend functionality on tap for 7.2 (see TODO) that will need to be in place before the tools Justin mentions can be properly built. We're very interested in helping out with the tools, and will be talking to the -hackers list more about our ideas once 7.1 is out the door. Regards, Ned Bruce Momjian wrote: We really need point-in-time recovery, removal of the need to vacuum, and more full-featured replication. Hopefully most can be addressed in 7.2. Hi all, Out of curiosity, does anyone know of any projects that are presently creating PostgreSQL database recovery tools? For example database corruption recovery, Point In Time restoration, and such things? It might be a good project for GreatBridge to look into if no-one else is doing it already. Regards and best wishes, Justin Clift Database Administrator
