Re: [HACKERS] Database Internals Presentation
On Wednesday 28 February 2001 04:04, Bruce Momjian wrote: > I have completed a database internals presentation. The PDF is at: > > http://candle.pha.pa.us/main/writings/internals.pdf > > I am interested in any comments. I need to add text to it. FYI, you > will find a system catalog chart in the presentation. Wow! That's cool. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 --
Re: [HACKERS] ExecOpenScanR: failed to open relation
Tom Lane wrote: > Pam Withnall <[EMAIL PROTECTED]> writes: > > in my java code I am creating 3 temporary tables, then calling a stored > > procedure which calls another stored procedure. > > then I drop the temporary tables. > > the first time around , eveything is OK , then when repeating the action I > > get > > "ExecOpenScanR: failed to open relation 2808495 " > > If you're using plpgsql, you can't drop and recreate temp tables between > procedure executions, because the cached query plans for the procedure > will still refer to the old version of the tables. > > Either create the temp table *once* per backend, or use pltcl, which > doesn't try to cache query plans. as long as you don't tell it to (using spi_prepare and spi_execp explicitly in PL/Tcl) :-) 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
[HACKERS] Re: mmap for zeroing WAL log
On Tue, 27 Feb 2001, Tom Lane wrote: > Matthew Kirkwood <[EMAIL PROTECTED]> writes: > > I had assumed that the overhead would come from synchronous > > metadata incurring writes of at least the inode, block bitmap > > and probably an indirect block for each syscall. > > No Unix that I've ever heard of forces metadata to disk after each > "write" call; anyone who tried it would have abysmal performance. > That's what fsync and the syncer daemon are for. My understanding was that that's exactly what ffs' synchronous metadata writes do. Am I missing something here? Do they jsut schedule I/O, but return without waiting for its completion? Matthew.
Re: [HACKERS] stuck spinlock
Tom Lane wrote: > Judging from the line number, this is in CreateCheckPoint. I'm > betting that your platform (Solaris 2.7, you said?) has the same odd > behavior that I discovered a couple days ago on HPUX: a select with > a delay of tv_sec = 0, tv_usec = 100 doesn't delay 1 second like > a reasonable person would expect, but fails instantly with EINVAL. After I finally understood what you meant, this behavior looks somehow reasonable to me as its a struct, but I must admit, that I don't have to much knowledge in this area. Anyway, after further thoughts I was curious about this odd behavior on the different platforms and I used your previously posted program, extended it a little bit and run it on all platforms I could get a hold of. Please have a look at the extracted log and comments below about the different platforms. It seems, that this functions a "good" example of a really incompatible implementation across platforms, even within the same across different versions of the OSs. Happy wondering ;-) > In short: please try the latest nightly snapshot (this fix is since > beta5, unfortunately) and let me know if you still see a problem. I did and I didn't get the error yet, but didn't run as many jobs either. If I get the error again, I'll post it. Thanks for your help, Peter = AIX 4.3.3 = Delay | elapsed Time| actual Wait --- 0 | 0.0 [msec/loop] | 0.0 [msec/sel] 500 | 10.3 [msec/loop] | 1.0 [msec/sel] 1000 | 10.3 [msec/loop] | 1.0 [msec/sel] 1500 | 15.3 [msec/loop] | 1.5 [msec/sel] 2000 | 20.3 [msec/loop] | 2.0 [msec/sel] ... 98 | 9800.3 [msec/loop] | 980.0 [msec/sel] 99 | 9899.3 [msec/loop] | 989.9 [msec/sel] -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 100 | 0.1 [msec/loop] | 0.0 [msec/sel] -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 101 | 0.1 [msec/loop] | 0.0 [msec/sel] other more granular run with steps of 10 usec after 1000: NUM_OF_LOOPS: 1000 Delay | elapsed Time| actual Wait --- 0 | 2.7090 [msec/loop] | 0.0027 [msec/sel] 100 | 1024.7370 [msec/loop] | 1.0247 [msec/sel] 200 | 1024.3160 [msec/loop] | 1.0243 [msec/sel] 300 | 1024.6510 [msec/loop] | 1.0247 [msec/sel] 400 | 1024.5030 [msec/loop] | 1.0245 [msec/sel] 500 | 1024.5400 [msec/loop] | 1.0245 [msec/sel] 600 | 1024.8340 [msec/loop] | 1.0248 [msec/sel] 700 | 1024.3110 [msec/loop] | 1.0243 [msec/sel] 800 | 1024.7030 [msec/loop] | 1.0247 [msec/sel] 900 | 1024.4560 [msec/loop] | 1.0245 [msec/sel] 1000 | 1024.2810 [msec/loop] | 1.0243 [msec/sel] 1010 | 1034.4840 [msec/loop] | 1.0345 [msec/sel] 1020 | 1044.0490 [msec/loop] | 1.0440 [msec/sel] 1030 | 1054.3530 [msec/loop] | 1.0544 [msec/sel] 1040 | 1064.6620 [msec/loop] | 1.0647 [msec/sel] 1050 | 1074.0980 [msec/loop] | 1.0741 [msec/sel] 1060 | 1084.4850 [msec/loop] | 1.0845 [msec/sel] 1070 | 1094.1270 [msec/loop] | 1.0941 [msec/sel] 1080 | 1104.4080 [msec/loop] | 1.1044 [msec/sel] 1090 | 1132.8880 [msec/loop] | 1.1329 [msec/sel] 1100 | 1124.2220 [msec/loop] | 1.1242 [msec/sel] Comments: o minimum is 1 msec until 1000 usec and than it tries to respect the actual number in usec o usec >= 1 sec not allowed HP-UX 10.20 === NUM_OF_LOOPS: 10 Delay | elapsed Time| actual Wait --- 0 | 0.1 [msec/loop] | 0.0 [msec/sel] 500 | 97.6 [msec/loop] | 9.8 [msec/sel] 1000 | 100.0 [msec/loop] | 10.0 [msec/sel] 1500 | 100.0 [msec/loop] | 10.0 [msec/sel] ... 14000 | 100.0 [msec/loop] | 10.0 [msec/sel] 14500 | 100.2 [msec/loop] | 10.0 [msec/sel] 15000 | 199.8 [msec/loop] | 20.0 [msec/sel] 15500 | 200.0 [msec/loop] | 20.0 [msec/sel] ... 24000 | 200.0 [msec/loop] | 20.0 [msec/sel] 24500 | 200.0 [msec/loop] | 20.0 [msec/sel] 25000 | 300.0 [msec/loop] | 30.0 [msec/sel] 25500 | 300.0 [msec/loop] | 30.0 [msec/sel] ... 98 | 9800.1 [msec/loop] | 980.0 [msec/sel] 99 | 9900.0 [msec/loop] | 990.0 [msec/sel] -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 100 | 0.1 [msec/loop] | 0.0 [msec/sel] -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 101 | 0.1 [msec/loop] | 0.0 [msec/sel] Comments: o minimum is 10 msec until 1000 usec o after 1000 it rounds down or up to the next 10msec o usec >= 1 sec not allowed HP-UX 11 === NUM_OF_LOOPS: 10 Delay | elapsed Time| actual Wait --- 0 | 92.7 [msec/loop] | 9.3 [msec/sel] 500 | 99.9 [msec/loop] | 10.0 [msec/sel] 1000 | 99.8 [msec/loop] | 10.0 [msec/sel] 1500 | 100.0 [msec/loop] | 10.0 [msec/sel] ... 9000 | 99.9 [msec/loop] | 10.0 [msec/sel] 9500 | 100.1 [msec/loop] | 10.0 [msec/sel] 1 | 199.9 [msec/loop] | 20.0 [msec/sel] 10500 |
Re: [HACKERS] Idea for reducing planning time
> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > Tom, do you have a plan to make a back patch for 7.0.3? > > No, I don't. No time for it now. > > > I got a bug report from a user with a script to reproduce the > > problem. Seems the backend consumes infinite memory. > > Not infinite, surely ;-) ... but possibly more than her kernel will > allow. As a workaround, I'd suggest setting geqo_threshold smaller, > perhaps 8 or 9. IIRC, the way to do that in 7.0 is > set geqo='on=8'; > Not sure if it's possible to set up a system-wide default for that > in 7.0. Yes, I thought about geqo too. However, a standard geqo settings didn't help. It still took 0:49 (7.0.2, 7.1 takes only ~3 seconds). Then I set: Pool_Size 128 Generations 10 and now the query takes only 5 seconds! > BTW, the main reason planning this join in 7.0 is so slow is that > all the options look exactly alike and so the planner has no reason to > discard any paths. As soon as you create some indexes, load up some > data and VACUUM, the symmetry would be broken and performance should > improve (geqo or not). Or at least it'd usually be broken. Is it > possible that all her tables are exactly the same size? Yes. t_cyuubunrui has four rows, and the others has only a row. -- Tatsuo Ishii
Re: [HACKERS] stuck spinlock
Interesting numbers --- thanks for sending them along. Looks like I was mistaken to think that most platforms would allow tv_usec >= 1 sec. Ah well, another day, another bug... regards, tom lane
Re: [HACKERS] regression.out and regression.diff
Tom Lane writes: > I have no idea why Peter thinks 'make installcheck' should be less > reliable than 'make check'. If installcheck fails for you, let's > see that too. In the test run that Vince had posted to his web tool, the server process apparently didn't have write permission to the source tree, so all the tests that did a COPY failed, plus all subsequent tests that depended on those tables. Additionally, the installcheck is also prone to fail if template1 was initialized with a different multibyte encoding, if there was a different locale during initdb, or if there's something fishy in postgresql.conf. At least I wouldn't accept installcheck output as a final result before seeing 'check'. Additionally, make check also tests 'make install' and 'initdb' robustness, which installcheck doesn't do, so the former should be preferred as final test result. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] Re: int8 beta5 broken?
Sorry to follow-up on my own post; int8 test passes if open-ssl is not
used.
weird!!
Regards,
On Wed, 28 Feb 2001, Olivier PRENANT wrote:
> Hi,
>
> Testing beta5 on unixware7 gives an error on int8 test while beta4 (I've
> just retested it) works ok regressions.diff follows:
>
> Also, compiling with openssl give a compile error on
> src/backend/libpq/crypt.c; this error CAN be avoided by commenting out the
> definition of des_encrypt in /ur/local/ssl/include/openssl/des.h
>
> I'm not sure this is good practice though.
>
> Anyway, even after that, there are linking errors on libecpg.so and perl
> because of a lack of -L/usr/local/ssl/lib
>
> Easyly avoid by setting ad hoc LD_LIBRARY_PATH.
>
> *** ./expected/int8.out Mon Jan 29 03:53:58 2001
> --- ./results/int8.outWed Feb 28 16:29:40 2001
> ***
> *** 5,111
> CREATE TABLE INT8_TBL(q1 int8, q2 int8);
> INSERT INTO INT8_TBL VALUES('123','456');
> INSERT INTO INT8_TBL VALUES('123','4567890123456789');
> INSERT INTO INT8_TBL VALUES('4567890123456789','123');
> INSERT INTO INT8_TBL VALUES('4567890123456789','4567890123456789');
> INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
> SELECT * FROM INT8_TBL;
> q1|q2
> ! --+---
> 123 | 456
> ! 123 | 4567890123456789
> ! 4567890123456789 | 123
> ! 4567890123456789 | 4567890123456789
> ! 4567890123456789 | -4567890123456789
> ! (5 rows)
>
> SELECT '' AS five, q1 AS plus, -q1 AS minus FROM INT8_TBL;
>five | plus | minus
> ! --+--+---
> | 123 | -123
> ! | 123 | -123
> ! | 4567890123456789 | -4567890123456789
> ! | 4567890123456789 | -4567890123456789
> ! | 4567890123456789 | -4567890123456789
> ! (5 rows)
>
> SELECT '' AS five, q1, q2, q1 + q2 AS plus FROM INT8_TBL;
>five |q1|q2 | plus
> ! --+--+---+--
> | 123 | 456 | 579
> ! | 123 | 4567890123456789 | 4567890123456912
> ! | 4567890123456789 | 123 | 4567890123456912
> ! | 4567890123456789 | 4567890123456789 | 9135780246913578
> ! | 4567890123456789 | -4567890123456789 |0
> ! (5 rows)
>
> SELECT '' AS five, q1, q2, q1 - q2 AS minus FROM INT8_TBL;
>five |q1|q2 | minus
> ! --+--+---+---
> | 123 | 456 | -333
> ! | 123 | 4567890123456789 | -456789012345
> ! | 4567890123456789 | 123 | 456789012345
> ! | 4567890123456789 | 4567890123456789 | 0
> ! | 4567890123456789 | -4567890123456789 | 9135780246913578
> ! (5 rows)
>
> SELECT '' AS three, q1, q2, q1 * q2 AS multiply FROM INT8_TBL
>WHERE q1 < 1000 or (q2 > 0 and q2 < 1000);
>three |q1|q2| multiply
> ! ---+--+--+
> | 123 | 456 | 56088
> !| 123 | 4567890123456789 | 561850485185185047
> !| 4567890123456789 | 123 | 561850485185185047
> ! (3 rows)
>
> SELECT '' AS five, q1, q2, q1 / q2 AS divide FROM INT8_TBL;
>five |q1|q2 | divide
> ! --+--+---+
> | 123 | 456 | 0
> ! | 123 | 4567890123456789 | 0
> ! | 4567890123456789 | 123 | 37137318076884
> ! | 4567890123456789 | 4567890123456789 | 1
> ! | 4567890123456789 | -4567890123456789 | -1
> ! (5 rows)
>
> SELECT '' AS five, q1, float8(q1) FROM INT8_TBL;
>five |q1|float8
> ! --+--+--
> | 123 | 123
> ! | 123 | 123
> ! | 4567890123456789 | 4.56789012345679e+15
> ! | 4567890123456789 | 4.56789012345679e+15
> ! | 4567890123456789 | 4.56789012345679e+15
> ! (5 rows)
>
> SELECT '' AS five, q2, float8(q2) FROM INT8_TBL;
>five |q2 |float8
> ! --+---+---
> | 456 | 456
> ! | 4567890123456789 | 4.56789012345679e+15
> ! | 123 | 123
> ! | 4567890123456789 | 4.56789012345679e+15
> ! | -4567890123456789 | -4.56789012345679
Re: [HACKERS] Re: int8 beta5 broken?
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? regards, tom lane
RE: [HACKERS] Re: int8 beta5 broken?
Working on it. Give me a couple of hours. LER -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:04 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Larry Rosenman Subject: Re: [HACKERS] Re: int8 beta5 broken? 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? regards, tom lane
Re: [HACKERS] Re: int8 beta5 broken?
* Larry Rosenman <[EMAIL PROTECTED]> [010228 11:13]: > Working on it. > > Give me a couple of hours. > Olivier, How did you build OpenSSL? I get the following (I only have a static lib): cc -O -K inline -K PIC -I. -I../../../src/include -I/usr/local/include -I/usr/local/ssl/include -DFRONTEND -DSYSCONFDIR='"/usr/local/pgsql/etc"' -c -o wchar.o wchar.c ar crs libpq.a `lorder fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.o wchar.o | tsort` UX:tsort: WARNING: Cycle in data UX:tsort: INFO: fe-connect.o UX:tsort: INFO: fe-auth.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: fe-exec.o UX:tsort: INFO: fe-misc.o UX:tsort: INFO: fe-connect.o : libpq.a cc -G -Wl,-z,text -Wl,-h,libpq.so.2 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.owchar.o -L/usr/local/lib -L/usr/local/ssl/lib -lssl -lcrypto -lresolv -lnsl -lsocket -Wl,-R/usr/local/pgsql/lib -o libpq.so.2.1 UX:ld: INFO: text relocations referenced from files: libssl.a(s23_meth.o) libssl.a(s23_srvr.o) libssl.a(s23_clnt.o) libssl.a(s23_lib.o) libssl.a(s23_pkt.o) libssl.a(t1_meth.o) libssl.a(t1_srvr.o) libssl.a(t1_clnt.o) libssl.a(t1_lib.o) libssl.a(t1_enc.o) libssl.a(ssl_lib.o) libssl.a(ssl_err2.o) libssl.a(ssl_cert.o) libssl.a(ssl_sess.o) libssl.a(ssl_ciph.o) libssl.a(ssl_algs.o) libssl.a(ssl_err.o) libssl.a(s2_srvr.o) libssl.a(s2_clnt.o) libssl.a(s2_lib.o) libssl.a(s2_enc.o) libssl.a(s2_pkt.o) libssl.a(s3_meth.o) libssl.a(s3_srvr.o) libssl.a(s3_clnt.o) libssl.a(s3_lib.o) libssl.a(s3_enc.o) libssl.a(s3_pkt.o) libssl.a(s3_both.o) libssl.a(ssl_rsa.o) libcrypto.a(cryptlib.o) libcrypto.a(mem.o) libcrypto.a(ex_data.o) libcrypto.a(md5_dgst.o) libcrypto.a(sha1dgst.o) libcrypto.a(hmac.o) libcrypto.a(fcrypt.o) libcrypto.a(bn_lib.o) libcrypto.a(rsa_lib.o) libcrypto.a(rsa_sign.o) libcrypto.a(dsa_vrf.o) libcrypto.a(dsa_sign.o) libcrypto.a(dh_key.o) libcrypto.a(dh_lib.o) libcrypto.a(buffer.o) libcrypto.a(bio_lib.o) libcrypto.a(bss_file.o) libcrypto.a(bss_sock.o) libcrypto.a(bf_buff.o) libcrypto.a(b_print.o) libcrypto.a(stack.o) libcrypto.a(lhash.o) libcrypto.a(rand_lib.o) libcrypto.a(err.o) libcrypto.a(err_all.o) libcrypto.a(o_names.o) libcrypto.a(obj_dat.o) libcrypto.a(obj_lib.o) libcrypto.a(obj_err.o) libcrypto.a(digest.o) libcrypto.a(evp_enc.o) libcrypto.a(e_des.o) libcrypto.a(e_idea.o) libcrypto.a(e_des3.o) libcrypto.a(e_rc4.o) libcrypto.a(names.o) libcrypto.a(e_rc2.o) libcrypto.a(m_md2.o) libcrypto.a(m_md5.o) libcrypto.a(m_sha1.o) libcrypto.a(m_dss1.o) libcrypto.a(p_sign.o) libcrypto.a(p_verify.o) libcrypto.a(p_lib.o) libcrypto.a(evp_err.o) libcrypto.a(e_null.o) libcrypto.a(evp_lib.o) libcrypto.a(evp_pbe.o) libcrypto.a(a_object.o) libcrypto.a(a_dup.o) libcrypto.a(x_sig.o) libcrypto.a(x_name.o) libcrypto.a(x_x509.o) libcrypto.a(x_x509a.o) libcrypto.a(d2i_r_pr.o) libcrypto.a(i2d_r_pr.o) libcrypto.a(d2i_pr.o) libcrypto.a(i2d_dhp.o) libcrypto.a(d2i_dhp.o) libcrypto.a(asn1_lib.o) libcrypto.a(asn1_err.o) libcrypto.a(evp_asn1.o) libcrypto.a(pem_all.o) libcrypto.a(pem_err.o) libcrypto.a(x509_d2.o) libcrypto.a(x509_cmp.o) libcrypto.a(x509_obj.o) libcrypto.a(x509_vfy.o) libcrypto.a(x509_err.o) libcrypto.a(x509_ext.o) libcrypto.a(x509type.o) libcrypto.a(x509_lu.o) libcrypto.a(x_all.o) libcrypto.a(x509_trs.o) libcrypto.a(by_file.o) libcrypto.a(by_dir.o) libcrypto.a(v3_lib.o) libcrypto.a(v3err.o) libcrypto.a(v3_alt.o) libcrypto.a(v3_skey.o) libcrypto.a(v3_akey.o) libcrypto.a(v3_pku.o) libcrypto.a(v3_enum.o) libcrypto.a(v3_sxnet.o) libcrypto.a(v3_cpols.o) libcrypto.a(v3_crld.o) libcrypto.a(v3_purp.o) libcrypto.a(v3_info.o) libcrypto.a(conf_err.o) libcrypto.a(pkcs7err.o) libcrypto.a(pk12err.o) libcrypto.a(comp_lib.o) libcrypto.a(mem_dbg.o) libcrypto.a(cpt_err.o) libcrypto.a(md2_dgst.o) libcrypto.a(md5_one.o) libcrypto.a(set_key.o) libcrypto.a(ecb_enc.o) libcrypto.a(ecb3_enc.o) libcrypto.a(cfb64enc.o) libcrypto.a(cfb64ede.o) libcrypto.a(ofb64ede.o) libcrypto.a(ofb64enc.o) libcrypto.a(des_enc.o) libcrypto.a(fcrypt_b.o) libcrypto.a(rc2_ecb.o) libcrypto.a(rc2_skey.o) libcrypto.a(rc2_cbc.o) libcrypto.a(rc2cfb64.o) libcrypto.a(rc2ofb64.o) libcrypto.a(rc4_skey.o) libcrypto.a(i_cbc.o) libcrypto.a(i_cfb64.o) libcrypto.a(i_ofb64.o) libcrypto.a(i_ecb.o) libcrypto.a(bn_exp.o) libcrypto.a(bn_ctx.o) libcrypto.a(bn_mul.o) libcrypto.a(bn_rand.o) libcrypto.a(bn_word.o) libcrypto.a(bn_blind.o) libcrypto.a(bn_gcd.o) libcrypto.a(bn_err.o) libcrypto.a(bn_sqr.o) libcrypto.a(bn_asm.o) libcrypto.a(bn_recp.o) libcrypto.a(bn_mont.o) libcrypto.a(rsa_eay.o) libcrypto.a(rsa_err.o) libcrypto.a(rsa_pk1.o) libcrypto.a(rsa_ssl.o) libcrypto.a(rsa_none.o) libcrypto.a(rsa_oaep.o) libcrypto.a(dsa_lib.o) libcrypto.a(dsa_asn1.o) libcrypto.a(dsa_err.o) libcrypto.a(dsa_ossl.o) libcrypto.a(dh_err.o) libcrypto.a(dso_err.o) libcrypto.a(buf_err.o) libcrypto.a(bio_err.o) libcrypto.a(md_rand.o) libcrypto.a(rand_err.o) libcrypto.a(rand_win.o) libcrypto.a(evp_pkey.o) libcry
[HACKERS] Doesn't WAL fail at BLCKSZ = 32k?
I've been looking at the WAL code and trying to figure out what the "backup block" mechanism is for. It appears that that can attach up to two disk pages of info to a WAL log record. If there are any cases where more than one page is really attached to a record, then WAL will crash and burn with BLCKSZ = 32K, because the record length field in XLogRecord is only 16 bits: there's not room for 2 * BLCKSZ, let alone any additional fields. The define #define _INTL_MAXLOGRECSZ (3 * MAXLOGRECSZ) in xlog.c is even more disturbing, if accurate; that'd mean that BLCKSZ = 16k wouldn't work either. I don't like the idea of restricting the maximum blocksize, since we don't yet have a complete implementation of TOAST (cf indexes). This appears to mean that the format of WAL records will have to change; either we widen xl_len or arrange for backup blocks to be stored as separate records. Or perhaps just agree that the backup blocks aren't counted in xl_len, although that seems a tad klugy. On the other hand, if there can't really be more than one backup block per record, there's no issue. Where is this used, and for what? regards, tom lane
[HACKERS] Re: Release in 2 weeks ...
Thomas Lockhart writes: > The "official" version of the story is that it takes ~10-20 hours for me > to work through the docs to format them for hardcopy with ApplixWare, Okay, I just kept hearing the "give Thomas 2 weeks for the docs" theme... > primarily because something in the jade RTF tickles a bug in the page > formatting with Applix. (This round, I'll resort even to M$Word to avoid > that time sink, since I just don't have the time.) Is that the same MS Word that generates Postscript files as a big bitmap? I suppose by the time we release the 10th anniversary edition, the XML/XSL architecture will be mature enough to produce printable files that way, but until then -- whatever works. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[GENERAL] strange error
hi,
i have relation with 3 int's and 1 text :
\d newstexts
Table "newstexts"
Attribute | Type |Modifier
---+-+-
id| integer | not null default nextval('newstexts_seq'::text)
news_id | integer | not null default ''
class_id | integer | not null default ''
text | text| not null default ''
i also have a rather complicated trigger which does some trick *AFTER*
inserting data to this table.
when i try to insert something i got:
ERROR: newses_seq.nextval: bad magic ()
i know it's my fault. but what should i look for to trace the problem, and kill
the bug?
i would really appreciate quick answers or suggestions (i'm running out of time
...)
depesz
--
hubert depesz lubaczewski http://www.depesz.pl/
najwspanialszą rzeczą jaką dało nam nowoczesne społeczeństwo,
jest niesamowita wręcz łatwość unikania kontaktów z nim ...
Re: [HACKERS] strange error
hubert depesz lubaczewski <[EMAIL PROTECTED]> writes: > ERROR: newses_seq.nextval: bad magic () Hmm, something bad has happened to your sequence object. It would be interesting to try to figure out what caused that, but if you're in a hurry, try dropping and recreating that sequence. regards, tom lane
[GENERAL] Re: [HACKERS] BLCKSZ 0?
"Dominic J. Eidson" <[EMAIL PROTECTED]> writes: > DEBUG: Data Base System is starting up at Tue Feb 27 22:31:51 2001 > FATAL 2: database was initialized with BLCKSZ 0, > but the backend was compiled with BLCKSZ 8192. > looks like you need to initdb. > So I tried to start up the > DB using the (supposedly) old/original binaries, and the old data > directory, which is when I get the above message(s). Well, those are very clearly 7.0 or later binaries, because 6.5 didn't have any such crosscheck. Which is probably why the field's not set, too ... so your data directory is old but your executables aren't. regards, tom lane
Re: [HACKERS] BLCKSZ 0?
On Tue, 27 Feb 2001, Tom Lane wrote: > "Dominic J. Eidson" <[EMAIL PROTECTED]> writes: > > > root@blue:/usr/local/pgsql# su postgres -c "bin/postmaster -D > > /usr/local/pgsql/data " > > DEBUG: Data Base System is starting up at Tue Feb 27 22:31:51 2001 > > FATAL 2: database was initialized with BLCKSZ 0, > > but the backend was compiled with BLCKSZ 8192. > > looks like you need to initdb. > > Read that again --- it did *not* say it was compiled with BLCKSZ 0. > It said (or meant, anyway) it found zero in the pg_control field that > indicates the BLCKSZ in use in the database. Something's broken with > your pg_control file ... care to give more details? Admin installed PostgreSQL 7.0(.x?) - clueless coder comes along sometime later, decides to install 6.5.3, because debian apt-get doesn't have 7.0(.x) yet. Doesn't pg_dumpall, doesn't back up anyting (not even just a tar of /usr/local/pgsql) Believing he lost all of his DB setup, admin contacts me to try to get things back up and running. He claims apt-get installed the binaries in a different place (and assumes .deb package installs the data directory elsewhere as well.) So I tried to start up the DB using the (supposedly) old/original binaries, and the old data directory, which is when I get the above message(s). -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
[HACKERS] Uh, this is *not* a 64-bit CRC ...
I just took a close look at the COMP_CRC64 macro in xlog.c. This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done on just the odd-numbered bytes and one on just the even-numbered bytes of the datastream. That's hardly any stronger than a single 32-bit CRC; it's certainly not what I thought we had agreed to implement. We can't change this algorithm without forcing an initdb, which would be a rather unpleasant thing to do at this late stage of the release cycle. But I'm not happy with it. Comments? regards, tom lane
Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...
On Wed, Feb 28, 2001 at 04:53:09PM -0500, Tom Lane wrote: > I just took a close look at the COMP_CRC64 macro in xlog.c. > > This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > on just the odd-numbered bytes and one on just the even-numbered bytes > of the datastream. That's hardly any stronger than a single 32-bit CRC; > it's certainly not what I thought we had agreed to implement. > > We can't change this algorithm without forcing an initdb, which would be > a rather unpleasant thing to do at this late stage of the release cycle. > But I'm not happy with it. Comments? This might be a good time to update: The CRC-64 code used in the SWISS-PROT genetic database is (now) at: ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz From the README: The code in this package has been derived from the BTLib package obtained from Christian Iseli <[EMAIL PROTECTED]>. From his mail: The reference is: W. H. Press, S. A. Teukolsky, W. T. Vetterling, and B. P. Flannery, "Numerical recipes in C", 2nd ed., Cambridge University Press. Pages 896ff. The generator polynomial is x64 + x4 + x3 + x1 + 1. I would suggest that if you don't change the algorithm, at least change the name in the sources. Were you to #ifdef in a real crc-64, and make a compile-time option to select the old one, you could allow users who wish to avoid the initdb a way to continue with the existing pair of CRC-32s. Nathan Myers [EMAIL PROTECTED]
[HACKERS] Re: Release in 2 weeks ...
> > primarily because something in the jade RTF tickles a bug in the page > > formatting with Applix. (This round, I'll resort even to M$Word to avoid > > that time sink, since I just don't have the time.) > Is that the same MS Word that generates Postscript files as a big bitmap? > I suppose by the time we release the 10th anniversary edition, the XML/XSL > architecture will be mature enough to produce printable files that way, > but until then -- whatever works. I'm not counting on it even then. Some "last minute markup" will always be required imho. But I dream about it ;) - Thomas
Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...
I will just add a TODO item and we can hit it for 7.2. > On Wed, Feb 28, 2001 at 04:53:09PM -0500, Tom Lane wrote: > > I just took a close look at the COMP_CRC64 macro in xlog.c. > > > > This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > > on just the odd-numbered bytes and one on just the even-numbered bytes > > of the datastream. That's hardly any stronger than a single 32-bit CRC; > > it's certainly not what I thought we had agreed to implement. > > > > We can't change this algorithm without forcing an initdb, which would be > > a rather unpleasant thing to do at this late stage of the release cycle. > > But I'm not happy with it. Comments? > > This might be a good time to update: > > The CRC-64 code used in the SWISS-PROT genetic database is (now) at: > > ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz > > From the README: > > The code in this package has been derived from the BTLib package > obtained from Christian Iseli <[EMAIL PROTECTED]>. > From his mail: > > The reference is: W. H. Press, S. A. Teukolsky, W. T. Vetterling, and > B. P. Flannery, "Numerical recipes in C", 2nd ed., Cambridge University > Press. Pages 896ff. > > The generator polynomial is x64 + x4 + x3 + x1 + 1. > > I would suggest that if you don't change the algorithm, at least change > the name in the sources. Were you to #ifdef in a real crc-64, and make > a compile-time option to select the old one, you could allow users who > wish to avoid the initdb a way to continue with the existing pair of > CRC-32s. > > Nathan Myers > [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: [ODBC] Re: [HACKERS] Release in 2 weeks ...
Patrick Welche wrote: > > On Wed, Feb 28, 2001 at 08:53:31AM +0900, Hiroshi Inoue wrote: > ... > > I think I've fixed this bug at least for MS-Access. > > You could get the latest win32 driver from > > ftp://ftp.greatbridge.org/pub/pgadmin/stable/psqlodbc.zip . > > Please try it. > > How can I just install that file? (ie., M$ Access -> psqlodbc.dll -> real OS) > I don't know if M$-access requires MDAC now(it didn't require MDAC before). I use ADO and don't use M$-access other than testing. ADO requires MDAC and pgAdmin uses ADO AFAIK. > = aside: > > I just tried installing pgAdmin - the installer says: > > This setup requires at least version 2.5 of the Microsoft Data Access > Components (MDAC) to be installed first. If the MDAC installer > (mdac_typ.exe) is not provided with this setup, you can find it on the > Microsoft web site (www.microsoft.com) > > And after searching said website, > http://www.microsoft.com/data/download2.htm > shows: > > Microsoft Data Access Components MDAC 2.1.1.3711.11 < 2.5... > I can see the following at http://www.microsoft.com/data/download.htm Data Access Components (MDAC) redistribution releases. Five releases of MDAC are available here: The new MDAC 2.6, two of MDAC 2.5, and two of MDAC 2.1. You can Regards, Hiroshi Inoue
Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...
Added to TODO: * Correct CRC WAL code to be normal CRC32 algorithm > On Wed, Feb 28, 2001 at 04:53:09PM -0500, Tom Lane wrote: > > I just took a close look at the COMP_CRC64 macro in xlog.c. > > > > This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > > on just the odd-numbered bytes and one on just the even-numbered bytes > > of the datastream. That's hardly any stronger than a single 32-bit CRC; > > it's certainly not what I thought we had agreed to implement. > > > > We can't change this algorithm without forcing an initdb, which would be > > a rather unpleasant thing to do at this late stage of the release cycle. > > But I'm not happy with it. Comments? > > This might be a good time to update: > > The CRC-64 code used in the SWISS-PROT genetic database is (now) at: > > ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz > > From the README: > > The code in this package has been derived from the BTLib package > obtained from Christian Iseli <[EMAIL PROTECTED]>. > From his mail: > > The reference is: W. H. Press, S. A. Teukolsky, W. T. Vetterling, and > B. P. Flannery, "Numerical recipes in C", 2nd ed., Cambridge University > Press. Pages 896ff. > > The generator polynomial is x64 + x4 + x3 + x1 + 1. > > I would suggest that if you don't change the algorithm, at least change > the name in the sources. Were you to #ifdef in a real crc-64, and make > a compile-time option to select the old one, you could allow users who > wish to avoid the initdb a way to continue with the existing pair of > CRC-32s. > > Nathan Myers > [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
[HACKERS] int8 beta5 broken?
Hi,
Testing beta5 on unixware7 gives an error on int8 test while beta4 (I've
just retested it) works ok regressions.diff follows:
Also, compiling with openssl give a compile error on
src/backend/libpq/crypt.c; this error CAN be avoided by commenting out the
definition of des_encrypt in /ur/local/ssl/include/openssl/des.h
I'm not sure this is good practice though.
Anyway, even after that, there are linking errors on libecpg.so and perl
because of a lack of -L/usr/local/ssl/lib
Easyly avoid by setting ad hoc LD_LIBRARY_PATH.
*** ./expected/int8.outMon Jan 29 03:53:58 2001
--- ./results/int8.out Wed Feb 28 16:29:40 2001
***
*** 5,111
CREATE TABLE INT8_TBL(q1 int8, q2 int8);
INSERT INTO INT8_TBL VALUES('123','456');
INSERT INTO INT8_TBL VALUES('123','4567890123456789');
INSERT INTO INT8_TBL VALUES('4567890123456789','123');
INSERT INTO INT8_TBL VALUES('4567890123456789','4567890123456789');
INSERT INTO INT8_TBL VALUES('4567890123456789','-4567890123456789');
SELECT * FROM INT8_TBL;
q1|q2
! --+---
123 | 456
! 123 | 4567890123456789
! 4567890123456789 | 123
! 4567890123456789 | 4567890123456789
! 4567890123456789 | -4567890123456789
! (5 rows)
SELECT '' AS five, q1 AS plus, -q1 AS minus FROM INT8_TBL;
five | plus | minus
! --+--+---
| 123 | -123
! | 123 | -123
! | 4567890123456789 | -4567890123456789
! | 4567890123456789 | -4567890123456789
! | 4567890123456789 | -4567890123456789
! (5 rows)
SELECT '' AS five, q1, q2, q1 + q2 AS plus FROM INT8_TBL;
five |q1|q2 | plus
! --+--+---+--
| 123 | 456 | 579
! | 123 | 4567890123456789 | 4567890123456912
! | 4567890123456789 | 123 | 4567890123456912
! | 4567890123456789 | 4567890123456789 | 9135780246913578
! | 4567890123456789 | -4567890123456789 |0
! (5 rows)
SELECT '' AS five, q1, q2, q1 - q2 AS minus FROM INT8_TBL;
five |q1|q2 | minus
! --+--+---+---
| 123 | 456 | -333
! | 123 | 4567890123456789 | -456789012345
! | 4567890123456789 | 123 | 456789012345
! | 4567890123456789 | 4567890123456789 | 0
! | 4567890123456789 | -4567890123456789 | 9135780246913578
! (5 rows)
SELECT '' AS three, q1, q2, q1 * q2 AS multiply FROM INT8_TBL
WHERE q1 < 1000 or (q2 > 0 and q2 < 1000);
three |q1|q2| multiply
! ---+--+--+
| 123 | 456 | 56088
!| 123 | 4567890123456789 | 561850485185185047
!| 4567890123456789 | 123 | 561850485185185047
! (3 rows)
SELECT '' AS five, q1, q2, q1 / q2 AS divide FROM INT8_TBL;
five |q1|q2 | divide
! --+--+---+
| 123 | 456 | 0
! | 123 | 4567890123456789 | 0
! | 4567890123456789 | 123 | 37137318076884
! | 4567890123456789 | 4567890123456789 | 1
! | 4567890123456789 | -4567890123456789 | -1
! (5 rows)
SELECT '' AS five, q1, float8(q1) FROM INT8_TBL;
five |q1|float8
! --+--+--
| 123 | 123
! | 123 | 123
! | 4567890123456789 | 4.56789012345679e+15
! | 4567890123456789 | 4.56789012345679e+15
! | 4567890123456789 | 4.56789012345679e+15
! (5 rows)
SELECT '' AS five, q2, float8(q2) FROM INT8_TBL;
five |q2 |float8
! --+---+---
| 456 | 456
! | 4567890123456789 | 4.56789012345679e+15
! | 123 | 123
! | 4567890123456789 | 4.56789012345679e+15
! | -4567890123456789 | -4.56789012345679e+15
! (5 rows)
SELECT '' AS five, 2 * q1 AS "twice int4" FROM INT8_TBL;
five |twice int4
! --+--
| 246
! | 246
! | 9135780246913578
! | 9135780246913578
! | 9135780246913578
! (5 rows)
SELECT '' AS five, q1 * 2 AS "twice int4" FROM INT8_TBL;
five |
Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...
On Wed, Feb 28, 2001 at 09:17:19PM -0500, Bruce Momjian wrote: > > On Wed, Feb 28, 2001 at 04:53:09PM -0500, Tom Lane wrote: > > > I just took a close look at the COMP_CRC64 macro in xlog.c. > > > > > > This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > > > on just the odd-numbered bytes and one on just the even-numbered bytes > > > of the datastream. That's hardly any stronger than a single 32-bit CRC; > > > it's certainly not what I thought we had agreed to implement. > > > > > > We can't change this algorithm without forcing an initdb, which would be > > > a rather unpleasant thing to do at this late stage of the release cycle. > > > But I'm not happy with it. Comments? > > > > This might be a good time to update: > > > > The CRC-64 code used in the SWISS-PROT genetic database is (now) at: > > > > ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/old/SPcrc.tar.gz > > > > From the README: > > > > The code in this package has been derived from the BTLib package > > obtained from Christian Iseli <[EMAIL PROTECTED]>. > > From his mail: > > > > The reference is: W. H. Press, S. A. Teukolsky, W. T. Vetterling, and > > B. P. Flannery, "Numerical recipes in C", 2nd ed., Cambridge University > > Press. Pages 896ff. > > > > The generator polynomial is x64 + x4 + x3 + x1 + 1. > > > > I would suggest that if you don't change the algorithm, at least change > > the name in the sources. Were you to #ifdef in a real crc-64, and make > > a compile-time option to select the old one, you could allow users who > > wish to avoid the initdb a way to continue with the existing pair of > > CRC-32s. > > Added to TODO: > > * Correct CRC WAL code to be normal CRC32 algorithm Um, how about * Correct CRC WAL code to be a real CRC64 algorithm instead? Nathan Myers [EMAIL PROTECTED]
Re: [HACKERS] Uh, this is *not* a 64-bit CRC ...
> > Added to TODO: > > > > * Correct CRC WAL code to be normal CRC32 algorithm > > Um, how about > > * Correct CRC WAL code to be a real CRC64 algorithm > > instead? Done. -- 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] SunOS4
> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > I have committed massive changes for SunOS4 port. Tested on: > > SunOS 4.1.4 > > Vine Linux 2.1 (variant of RedHat Linux 6.2J) > > FreeBSD 4.2-RELEASE > > Please let me know if I have broken something. > > Everything still builds and passes regression on HPUX, but I concur with > Peter that the HAVE_OPTARG configure stuff must be unnecessary. Please > observe that > src/backend/bootstrap/bootstrap.c > src/backend/postmaster/postmaster.c > src/backend/tcop/postgres.c > src/bin/pg_dump/pg_dump.c > src/bin/psql/startup.c > src/interfaces/ecpg/preproc/ecpg.c > all seem to be getting along fine with no configure test. There are > also a bunch of contrib modules that use optarg, and would also need > to be changed if you want to apply a configure test. > > I suggest reverting the configure and config.h changes and instead > making pg_restore and pg_id follow the coding practices used in the > above-mentioned files for optarg. > > regards, tom lane done. -- Tatsuo Ishii
Re: [HACKERS] int8 beta5 broken?
Olivier PRENANT writes: > Testing beta5 on unixware7 gives an error on int8 test while beta4 (I've > just retested it) works ok regressions.diff follows: This doesn't happen to be caused by the compiler bug described in doc/FAQ_SCO? > Anyway, even after that, there are linking errors on libecpg.so and perl > because of a lack of -L/usr/local/ssl/lib Can you post some screen output, so we can see what the command was that caused the error? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[BUGS] Re: [HACKERS] int8 beta5 broken?
Olivier PRENANT <[EMAIL PROTECTED]> writes: > Testing beta5 on unixware7 gives an error on int8 test while beta4 (I've > just retested it) works ok. That's odd. int8.c hasn't changed since beta3 (except in the float-to-int8 routine, which isn't involved here). Is there any difference in the src/include/config.h file generated by the two versions? regards, tom lane
AW: [HACKERS] Uh, this is *not* a 64-bit CRC ...
> I just took a close look at the COMP_CRC64 macro in xlog.c. > > This isn't a 64-bit CRC. It's two independent 32-bit CRCs, one done > on just the odd-numbered bytes and one on just the even-numbered bytes > of the datastream. That's hardly any stronger than a single > 32-bit CRC; > 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. Andreas
[ADMIN] Still some problems importing with COPY
Hi, I want to import from a .txt file, I usually use: COPY noticies FROM '/home/teixi/_6tm_/_elbulli/premsai.txt' USING DELIMITERS '|' \g a) If table 'noticies' has a date row and is null on data file it claims: Unable to import date filed '' so how to admit date fields null? b) When there are some 'carriage returns' on a field in the data file is understood as a new |row1data1|row1data2|row1data3|^M |row2data1^M stillrow2data1|row2data2|row2data2|^M is interpreted as a 3 row data file when in reallity is a 2 row data file. how could I handle this when importing ? bests from barcelona, jaume teixi ps: weather loops between 5ºC to 30ºC, crazy.
