Re: [HACKERS] Pre-forking backend
On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > How hard would it be to pre-fork an extra backend > > > > How are you going to pass the connection socket to an already-forked > > child process? AFAIK there's no remotely portable way ... > > Umm... Apache? They use a preforking model and it works quite well for > every *NIX that Apache runs on. ;) Maybe RSE can comment on this > further... -sc It works very good for what Apache requires. Namely, to have a queue of processes ready to serve pages. Its not that simple with PostgreSQL - as the discussion so far has drawn out - since there is no simple way to guarantee that the 'right' child gets the socket. The reason why there needs to be a 'right' child is that a socket needs to be passed to a child which has started up for a given database. Otherwise, there's no benefit. This aside, isn't it possible to just copy the socket and some data about the database required into shared memory and have the preforked children pick the socket up from there. Combined with a framework which tests that there are still idle pre-forked children waiting for this database and some configuration options to allow users to specify a number of waiting backends for a given database, and this would work pretty well. Gavin ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] PL/pgSQL bug?
In the attached script, second call to test1() causes error: select test1(); test1 --- 0 (1 row) select test1(); psql:/home/t-ishii/tmp/aaa.sql:13: NOTICE: Error occurred while executing PL/pgSQL function test1 psql:/home/t-ishii/tmp/aaa.sql:13: NOTICE: line 5 at select into variables psql:/home/t-ishii/tmp/aaa.sql:13: ERROR: Relation 422543 does not exist Maybe PL/pgSQL cache problem? -- Tatsuo Ishii -- drop function test1(); create function test1() returns int as ' declare rec RECORD; begin create temp table temp_aaa (i int); select into rec * from temp_aaa; drop table temp_aaa; return 0; end; 'language 'plpgsql'; select test1(); select test1(); ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-forking backend
Gavin Sherry <[EMAIL PROTECTED]> writes: > This aside, isn't it possible to just copy the socket and some > data about the database required into shared memory and have the preforked > children pick the socket up from there. Ummm No. There's no Unix API for doing so. You can pass open file descriptors across Unix domain sockets on most systems, which is a possible way to address the problem, but probably not worth it for the reasons discussed earlier. -Doug -- In a world of steel-eyed death, and men who are fighting to be warm, Come in, she said, I'll give you shelter from the storm.-Dylan ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Glitch in handling of postmaster -o options
On Sun, Sep 30, 2001 at 12:54:25AM +0200, Peter Eisentraut wrote: > Tom Lane writes: > > While that's not a fatal problem, I could imagine *much* more serious > > misbehavior from inconsistent settings of some GUC parameters. Since > > backends believe that these parameters have PGC_POSTMASTER priority, > > they'll accept changes that they probably oughtn't. For example, > > postmaster -o --shared_buffers=N > > will cause things to blow up very nicely indeed: backends will have > > a value of NBuffers that doesn't agree with what the postmaster has. > > This is a bug. PG 7.1 wouldn't let this thing go through but with all the > changes made for the RESET ALL functionality (I think) this has snuck in. > > My best guess is that this change was made to allow using > SetConfigOption() in PostgresMain() with options that are really > postmaster-global and are passed down to the backends. But AFAICS there > aren't any such options anymore. > > > I wonder whether we should retire -o. How about putting -o stuff after -p? That way only postmaster code can set PGC_POSTMASTER options for a backend, no way for user to mess up. ATM this would break -o -F tho'. -- marko ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Glitch in handling of postmaster -o options
Marko Kreen <[EMAIL PROTECTED]> writes: >> I wonder whether we should retire -o. > How about putting -o stuff after -p? That way only postmaster > code can set PGC_POSTMASTER options for a backend, no way for > user to mess up. ATM this would break -o -F tho'. Indeed. If we're going to force people to change their scripts anyway, IMHO we might as well go all the way... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/pgSQL bug?
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Maybe PL/pgSQL cache problem? This is a well-known problem: plpgsql caches a query plan that refers to the first version of the temp table, and it doesn't know it needs to rebuild the plan. AFAIK the only workaround at present is to use EXECUTE for queries referencing the temp table. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Pre-forking backend
* Gavin Sherry ([EMAIL PROTECTED]) [010930 06:13]: > On Sat, 29 Sep 2001 [EMAIL PROTECTED] wrote: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > How hard would it be to pre-fork an extra backend > > > > > > How are you going to pass the connection socket to an already-forked > > > child process? AFAIK there's no remotely portable way ... > > > > Umm... Apache? They use a preforking model and it works quite well for > > every *NIX that Apache runs on. ;) Maybe RSE can comment on this > > further... -sc > > It works very good for what Apache requires. Namely, to have a queue of > processes ready to serve pages. Its not that simple with PostgreSQL - as > the discussion so far has drawn out - since there is no simple way to > guarantee that the 'right' child gets the socket. The reason why there > needs to be a 'right' child is that a socket needs to be passed to a child > which has started up for a given database. Otherwise, there's no benefit. Interesting: So as the number of databases served by a given system approaches one, the efficiency of this increases. Is it useful if it only works for one database within a server? I can envision applications for this. -Brad ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS changes
I've built the docs on cvs.postgresql.org, but where are the ftp and www areas these days and how does one get stuff onto them? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/pgSQL bug?
Tatsuo Ishii wrote: > In the attached script, second call to test1() causes error: Well known error. PL/pgSQL creates saved execution plans for almost every expression and query using SPI_prepare(), SPI_saveplan(). If any of the objects, referenced from such a plan get's dropped, they become invalid and for now, only reconnecting to the database can heal. 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Pre-forking backend
Doug McNaught wrote: > > You can pass open file descriptors across Unix domain sockets on most > systems, which is a possible way to address the problem, but probably > not worth it for the reasons discussed earlier. I think that it does solve the problem. The only drawback is that it's not portable. Almost all systems do support one of two methods, though. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS changes
just about to be moved to the new server, now that the new 18gi drive has been installed ... plan on getting that done this afternoon ... On Sun, 30 Sep 2001, Peter Eisentraut wrote: > I've built the docs on cvs.postgresql.org, but where are the ftp and www > areas these days and how does one get stuff onto them? > > -- > Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter > > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Pre-forking backend
Bradley McLean <[EMAIL PROTECTED]> writes: > Is it useful if it only works for one database within a server? Once we have schemas (7.3, I hope), I think a lot of installations will have only one production database. However, if we were going to do this what we'd probably do is allow the DBA to configure the postmaster to start N pre-forked backends per database, where N can depend on the database. There's no reason to limit it to just one database. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ftp.postgresql.org points to new server ...
now that the 18gig is in place and I have space once more to work, ftp.postgresql.org now points at the new server (~ftp for those that login) ... let me know if there are any problems ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Glitch in handling of postmaster -o options
> Marko Kreen <[EMAIL PROTECTED]> writes: > >> I wonder whether we should retire -o. > > > How about putting -o stuff after -p? That way only postmaster > > code can set PGC_POSTMASTER options for a backend, no way for > > user to mess up. ATM this would break -o -F tho'. Not sure what you are suggesting here. Should we keep -o but say all options after -o are passed to postgres backends: postmaster -a -b -c -o -f -g -h In this case, -abc goes to postmaster and -fgh goes to postgres. -- 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] path for contrib/intarray (current CVS)
Patch applied. Thanks. > Please apply attached patch to current CVS tree. > > Changes: > > 1. gist__int_ops is now without lossy > 2. added sort entry in picksplit > > 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 Content-Description: [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Glitch in handling of postmaster -o options
On Sun, Sep 30, 2001 at 02:13:34PM -0400, Bruce Momjian wrote: > > Marko Kreen <[EMAIL PROTECTED]> writes: > > >> I wonder whether we should retire -o. > > > > > How about putting -o stuff after -p? That way only postmaster > > > code can set PGC_POSTMASTER options for a backend, no way for > > > user to mess up. ATM this would break -o -F tho'. > > Not sure what you are suggesting here. Should we keep -o but say all > options after -o are passed to postgres backends: I am suggesting this. Like previosly discussed, postmaster -F should be used instead of postmaster '-o -F'. Other options with PGC_BACKEND, like -S keep on working. -- marko Index: src/backend/postmaster/postmaster.c === RCS file: /opt/cvs/pgsql/pgsql/src/backend/postmaster/postmaster.c,v retrieving revision 1.243 diff -u -c -r1.243 postmaster.c *** src/backend/postmaster/postmaster.c 21 Sep 2001 20:31:48 - 1.243 --- src/backend/postmaster/postmaster.c 30 Sep 2001 15:35:44 - *** *** 2035,2048 av[ac++] = debugbuf; } - /* -* Pass any backend switches specified with -o in the postmaster's own -* command line. We assume these are secure. (It's OK to mangle -* ExtraOptions since we are now in the child process; this won't -* change the postmaster's copy.) -*/ - split_opts(av, &ac, ExtraOptions); - /* Tell the backend what protocol the frontend is using. */ sprintf(protobuf, "-v%u", port->proto); av[ac++] = protobuf; --- 2035,2040 *** *** 2055,2060 --- 2047,2062 StrNCpy(dbbuf, port->database, ARGV_SIZE); av[ac++] = dbbuf; + + /* +* Pass any backend switches specified with -o in the postmaster's own +* command line. (It's OK to mangle ExtraOptions since we are now in the +* child process; this won't change the postmaster's copy.) +* +* We dont assume anymore they are secure, now only PGC_BACKEND +* options can be specified that way. +*/ + split_opts(av, &ac, ExtraOptions); /* * Pass the (insecure) option switches from the connection request. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS changes
> > > just about to be moved to the new server, now that the new 18gi drive has > been installed ... plan on getting that done this afternoon ... Don't rush. I am setting up my system to check the SGML docs every 15 minutes and rebuild if necessary. Overnight builds are not frequent enough for people modifying the SGML files. This way they can commit changes and check in fifteen minutes to see the changes in HTML. They are now at: http://candle.pha.pa.us/main/writings/pgsql/sgml I will add a link to the bottom of the developer's page. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS changes
done already, ftp should be accessible as it was before ... On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > just about to be moved to the new server, now that the new 18gi drive has > > been installed ... plan on getting that done this afternoon ... > > Don't rush. I am setting up my system to check the SGML docs every 15 > minutes and rebuild if necessary. Overnight builds are not frequent > enough for people modifying the SGML files. This way they can commit > changes and check in fifteen minutes to see the changes in HTML. > > They are now at: > > http://candle.pha.pa.us/main/writings/pgsql/sgml > > I will add a link to the bottom of the developer's page. > > -- > 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 > ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Glitch in handling of postmaster -o options
Marko Kreen <[EMAIL PROTECTED]> writes: > I am suggesting this. > [ code snipped ] Okay, that would mean that "-o '-S nnn'" still works, but "-o -F" doesn't. But ... the thing is, there is no reason for -o to exist anymore other than backwards compatibility with existing startup scripts. -o doesn't do anything you can't do more cleanly and sanely with GUC options (--sort_mem, etc). So, I don't really see much value in keeping it if you're going to break one of the more common usages --- which I'm sure -o -F is. Since the problem I identified is not likely to bite very many people, my vote is not to try to apply a code solution now. I think we should leave the code alone, and instead document in 7.2 that -o is deprecated (and explain what to do instead), with the intention of removing it in 7.3. Giving people a release cycle's worth of notice seems sufficient. Possibly we could also take this opportunity to deprecate -S and the other options that are standing in the way of unified command line options for postmasters and backends. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ftp.postgresql.org points to new server ...
> > now that the 18gig is in place and I have space once more to work, > ftp.postgresql.org now points at the new server (~ftp for those that > login) ... let me know if there are any problems ... I wonder if we should be allowing people to use non-anonymous ftp. There is no password protection there. I use scp and like it a lot. It is less interactive than ftp but is easier to automate in scripts. I believe Peter's issue is that the web server is on a different machine from our accounts and there is no way to get the SGML output into the web server. I have created an HTML copy of the SGML here so that should work for people. -- 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CVS changes
On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > just about to be moved to the new server, now that the new 18gi drive has > > been installed ... plan on getting that done this afternoon ... > > Don't rush. I am setting up my system to check the SGML docs every 15 > minutes and rebuild if necessary. Overnight builds are not frequent > Would it not be better to provide a means for developers to cause the rebuild on demand? A 15-minute wait doesn't seem convenient to me. > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS changes
> On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > > > > > > just about to be moved to the new server, now that the new 18gi drive has > > > been installed ... plan on getting that done this afternoon ... > > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > minutes and rebuild if necessary. Overnight builds are not frequent > > > Would it not be better to provide a means for developers to cause the rebuild on >demand? A 15-minute wait doesn't seem convenient to me. Yep, but it takes 15 minutes to build anyway, so I figured I would check very 15 minutes and adding another 15, that makes 1/2 hour. We don't have a mechanism to build only a few html files. You have to do the whole thing. Suggestions? -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Preparation for Beta
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, I think we are on track for Monday beta. > > One thing that I think absolutely *must* happen before we can go beta > is to fix the documentation build process at hub.org. Until the online > developer docs are up-to-date, how are beta testers going to know what > to look at? (For that matter, what are the odds that the doc tarball > generation process will succeed?) > > Personally I'd really like to see CVSWeb working again too... OK, are we ready for beta tomorrow, Monday? Are we building a tarball tomorrow? I need to pgindent before that. Also, what about /ChangeLog? Can I remove it? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-forking backend
> > Once we have schemas (7.3, I hope), I think a lot of installations will > have only one production database. However, if we were going to do this > what we'd probably do is allow the DBA to configure the postmaster to > start N pre-forked backends per database, where N can depend on the > database. There's no reason to limit it to just one database. The optimized version of Postgres-R uses pre-forked backends for handling remote write sets. It currently uses one user/database, so I'm all for having a configurable parameter for starting a pool of backends for each database. We'll have to make sure that number * the number of databases is lower than the max number of backends at start up. Darren > > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/pgSQL bug?
> This is a well-known problem: plpgsql caches a query plan that refers > to the first version of the temp table, and it doesn't know it needs > to rebuild the plan. AFAIK the only workaround at present is to use > EXECUTE for queries referencing the temp table. But EXECUTE does not support select into, does it? -- Tatsuo Ishii ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Problem on AIX with current
Per Tom's request(1000 concurrent backends), I tried current on IBM AIX 5L and found that make check hungs: parallel group (13 tests): float4 oid varchar pgbench hungs too if more than 4 or so concurrent backends are involved. Unfortunately gdb does not work well on AIX, so I'm stucked. Maybe a new locking code? BTW PostgreSQL 7.1.3 works fine. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Pre-forking backend
> > > > How hard would it be to pre-fork an extra backend for the database a > > user just requested so if they next user asks for the same database, the > > backend would already be started? Perhaps I'm missing something, but it seems to me that the cost of forking a new backend would be pretty trivial compared to the expense of processing anything but the most simple query. Am I wrong in that? steve ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] ftp.postgresql.org points to new server ...
web server and ftp server are now on the same machine, actually . everything is now merged together once more ... On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > now that the 18gig is in place and I have space once more to work, > > ftp.postgresql.org now points at the new server (~ftp for those that > > login) ... let me know if there are any problems ... > > I wonder if we should be allowing people to use non-anonymous ftp. There is > no password protection there. I use scp and like it a lot. It is less > interactive than ftp but is easier to automate in scripts. > > I believe Peter's issue is that the web server is on a different machine > from our accounts and there is no way to get the SGML output into the > web server. I have created an HTML copy of the SGML here so that should > work for people. > > -- > 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 > ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] cvs tip problems
I just grabbed cvs tip this afternoon and ran into two issues:
- First one is that the regression fails on "geometry" on what appears to be
a difference in the 13th decimal place of the output value. See the attached
regression diff.
- Second was on reloading my data, I got the following error message (4
times):
ERROR: operator class "timestamp_ops" does not accept data type
timestamp with time zone
I've not seen either of these problems before, and I've gone through this
routine at least a dozen times in the past month or so. The second problem
is caused by the following statements (auto generated by pg_dumpall):
CREATE UNIQUE INDEX "lda_idx_1" on "laser_diagnostic_activity" using btree
( "laser_sn" "varchar_ops", "diag_run_date" "timestamp_ops" );
CREATE INDEX "ldi_idx_1" on "laser_diagnostic_items" using btree (
"laser_sn" "varchar_ops", "diag_run_date" "timestamp_ops", "diag_type"
"bpchar_ops", "diag_item" "int4_ops" );
CREATE INDEX "lv_processed_hdr_idx4" on "lv_processed_hdr" using btree (
"lv_dt" "timestamp_ops" );
CREATE INDEX "lv_processed_hdr_idx3" on "lv_processed_hdr" using btree (
"laser_type" "varchar_ops", "lv_dt" "timestamp_ops" );
And the related tables look like:
CREATE TABLE "laser_diagnostic_activity" (
"lda_id" integer DEFAULT
nextval('"laser_diagnostic_act_lda_id_seq"'::text) NOT NULL,
"laser_sn" character varying(15) NOT NULL,
"diag_run_date" timestamp with time zone NOT NULL,
"diag_ul_date" timestamp with time zone NOT NULL,
Constraint "laser_diagnostic_activity_pkey" Primary Key ("lda_id")
);
CREATE TABLE "laser_diagnostic_items" (
"ldi_id" integer DEFAULT
nextval('"laser_diagnostic_ite_ldi_id_seq"'::text) NOT NULL,
"laser_sn" character varying(15) NOT NULL,
"diag_run_date" timestamp with time zone NOT NULL,
"diag_type" character(1) NOT NULL,
"diag_item" integer NOT NULL,
"diag_description" character varying(20) NOT NULL,
"diag_value" character varying(24),
"diag_units" character varying(10),
"lda_id" integer,
Constraint "laser_diagnostic_items_pkey" Primary Key ("ldi_id")
);
CREATE TABLE "lv_processed_hdr" (
"hdr_id" integer NOT NULL,
"laser_sn" character varying(15) NOT NULL,
"config_id" integer,
"file_path" character varying(255) NOT NULL,
"file_name" character varying(255) NOT NULL,
"lv_dt" timestamp with time zone NOT NULL,
"orig_lv_file" character varying(255) NOT NULL,
"app_ver" character varying(50) NOT NULL,
"lte_name" character varying(50) NOT NULL,
"lte_login" character varying(50) NOT NULL,
"integrator" character varying(25) NOT NULL,
"laser_type" character varying(50) NOT NULL,
"test_name" character varying(50) NOT NULL,
"data_set_name" character varying(50) NOT NULL,
"data_set_id" character varying(50) NOT NULL
);
Any suggestions?
Thanks,
Joe
regression.diffs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Pre-forking backend
> > > > > > How hard would it be to pre-fork an extra backend for the database a > > > user just requested so if they next user asks for the same database, the > > > backend would already be started? > > Perhaps I'm missing something, but it seems to me that the cost of forking > a new backend would be pretty trivial compared to the expense of processing > anything but the most simple query. Am I wrong in that? True on most OS's, but on Solaris, fork is pretty expensive, or at least we are told. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Pre-forking backend
At 08:16 PM 30-09-2001 -0600, Steve Wolfe wrote: >> > >> > How hard would it be to pre-fork an extra backend for the database a >> > user just requested so if they next user asks for the same database, the >> > backend would already be started? > > Perhaps I'm missing something, but it seems to me that the cost of forking >a new backend would be pretty trivial compared to the expense of processing >anything but the most simple query. Am I wrong in that? I think forking costs a lot on Solaris. That's why Sun promotes threads :). I still don't see many advantages of doing the preforking in postgresql. What would the benefits be? Able to open and close db connections many times a second? Any other advantages? Can't the apps do their own preforking? All they do is preopen their own db connections. Then they can take care of whatever initialization and details they want. It seems that opening and closing db connections over the network will always be slower than just leaving a prepared connection open, looking at just the network connection setup time alone. I suppose it is helpful for plain cgi scripts, but those don't scale do they? Cheerio, Link. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS changes
Bruce Momjian writes: > Don't rush. I am setting up my system to check the SGML docs every 15 > minutes and rebuild if necessary. Overnight builds are not frequent > enough for people modifying the SGML files. This is news to me... Do you mean you commit stuff and then wait 15 minutes to see how it looks? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS changes
On Mon, 1 Oct 2001, Peter Eisentraut wrote: > Bruce Momjian writes: > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > minutes and rebuild if necessary. Overnight builds are not frequent > > enough for people modifying the SGML files. > > This is news to me... Do you mean you commit stuff and then wait 15 > minutes to see how it looks? You mean you commit stuff before testing it locally? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pgstat dumps core if alignof(int64) > alignof(long)
I have just found a nasty portability problem in the new statistics stuff. It assumes that it can store int64 values in hashtable entries ... but the dynahash module hands back pointers that are only aligned to sizeof(long). On a machine where int64 has to be 8-byte-aligned, instant coredump. I hadn't noticed this before, even though HPPA is just such an architecture, because gcc emits pairs of single-word load and store instructions for int64, not doubleword load and store. As soon as I recompiled with HP's compiler, pgstat didn't work anymore. I think the cleanest answer is to fix dynahash so that it gives back MAXALIGN'd pointers. It looks like this will not waste a significant amount of space, and it'll probably be a necessary change in the long run anyway. While I'm messing with this, I think I will also change the API for hash_create so that one specifies the key size and the total entry size, not the key size and data size to be added together. It's too easy to get the alignment considerations wrong with the present API --- there are a number of places that are presently silently assuming that there's no padding in their hashtable entry structs, eg ri_triggers.c. And I observe that pgstat itself thinks that that's what the API is anyway... Comments, objections? I think this is a must-fix-before-beta item. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] int4eq (xid, int4)
Jean-Michel POURE wrote: > > Hello friends, > > int4eq (xid, int4) seems to be needed for proper support of MS Access2K: > CREATE FUNCTION "int4eq" (xid, int4) > RETURNS bool > AS 'int4eq' > LANGUAGE 'internal' > > Is int4eq function included in PostgreSQL 7.2? I added a '=' operator between xid and int in 7.2. The registration of int4eq and =(xid,int) for row versioning is no longer needed in 7.2. regards, Hiroshi Inoue ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS changes
> Bruce Momjian writes: > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > minutes and rebuild if necessary. Overnight builds are not frequent > > enough for people modifying the SGML files. > > This is news to me... Do you mean you commit stuff and then wait 15 > minutes to see how it looks? I have a cron job that does cvs update every 15 minutes and recreates the HTML if needed. I know you can manually run it on individual SGML files but I don't see a way to automate that. Do you? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CVS changes
> On Mon, 1 Oct 2001, Peter Eisentraut wrote: > > > Bruce Momjian writes: > > > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > > minutes and rebuild if necessary. Overnight builds are not frequent > > > enough for people modifying the SGML files. > > > > This is news to me... Do you mean you commit stuff and then wait 15 > > minutes to see how it looks? > > You mean you commit stuff before testing it locally? Not everyone has sgml tools on their local machine, do they? -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS changes
> On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > On Mon, 1 Oct 2001, Peter Eisentraut wrote: > > > > > > > Bruce Momjian writes: > > > > > > > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > > > > minutes and rebuild if necessary. Overnight builds are not frequent > > > > > enough for people modifying the SGML files. > > > > > > > > This is news to me... Do you mean you commit stuff and then wait 15 > > > > minutes to see how it looks? > > > > > > You mean you commit stuff before testing it locally? > > > > Not everyone has sgml tools on their local machine, do they? > > I understood it to be a requirement for doc development. We have lots of people who submit SGML changes with their code patches and they certainly don't have it installed. I only installed it in the past six months. -- 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS changes
On Sun, 30 Sep 2001, Bruce Momjian wrote: > > On Mon, 1 Oct 2001, Peter Eisentraut wrote: > > > > > Bruce Momjian writes: > > > > > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > > > minutes and rebuild if necessary. Overnight builds are not frequent > > > > enough for people modifying the SGML files. > > > > > > This is news to me... Do you mean you commit stuff and then wait 15 > > > minutes to see how it looks? > > > > You mean you commit stuff before testing it locally? > > Not everyone has sgml tools on their local machine, do they? I understood it to be a requirement for doc development. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] cvs tip problems
"Joe Conway" <[EMAIL PROTECTED]> writes: > I just grabbed cvs tip this afternoon and ran into two issues: > - First one is that the regression fails on "geometry" on what appears to be > a difference in the 13th decimal place of the output value. See the attached > regression diff. Looks like it was not you that changed, but Thomas' reference machine. What platform are you on, anyway? > - Second was on reloading my data, I got the following error message (4 > times): > ERROR: operator class "timestamp_ops" does not accept data type > timestamp with time zone Oh, ye olde change-of-opclass-name problem. I've stuck a hack into gram.y as we've done in the past, but I'm starting to think that we need a better answer going forward. Maybe pg_dump could be tweaked to not dump opclass names if they are default opclasses? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] CVS changes
Something is broken with anon cvs: cvs server: Updating pgsql/contrib/pgstattuple cvs server: failed to create lock directory for /projects/cvsroot/pgsql/contrib/pgstattuple' (/projects/cvsroot/pgsql/contrib/pgstattuple/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository /projects/cvsroot/pgsql/contrib/pgstattuple' cvs [server aborted]: read lock failed - giving up Oleg On Sun, 30 Sep 2001, Marc G. Fournier wrote: > > done already, ftp should be accessible as it was before ... > > On Sun, 30 Sep 2001, Bruce Momjian wrote: > > > > > > > > > > just about to be moved to the new server, now that the new 18gi drive has > > > been installed ... plan on getting that done this afternoon ... > > > > Don't rush. I am setting up my system to check the SGML docs every 15 > > minutes and rebuild if necessary. Overnight builds are not frequent > > enough for people modifying the SGML files. This way they can commit > > changes and check in fifteen minutes to see the changes in HTML. > > > > They are now at: > > > > http://candle.pha.pa.us/main/writings/pgsql/sgml > > > > I will add a link to the bottom of the developer's page. > > > > -- > > 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 > > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] ftp.postgresql.org points to new server ...
Marc, will hub.org::postgresql-ftp works Oleg On Sun, 30 Sep 2001, Marc G. Fournier wrote: > > now that the 18gig is in place and I have space once more to work, > ftp.postgresql.org now points at the new server (~ftp for those that > login) ... let me know if there are any problems ... > > > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
