Re: [HACKERS] ecpg build on AIX 4.2.1
On Tue, Sep 23, 2003 at 04:21:10PM -0400, Samuel A Horwitz wrote: I am getting Undefined symbols in build ecpg ... ld: 0711-317 ERROR: Undefined symbol: .PQfinish ld: 0711-317 ERROR: Undefined symbol: .PQexec ld: 0711-317 ERROR: Undefined symbol: .PQclear ld: 0711-317 ERROR: Undefined symbol: .PQresultErrorField ld: 0711-317 ERROR: Undefined symbol: .PQsetdbLogin ld: 0711-317 ERROR: Undefined symbol: .PQstatus ld: 0711-317 ERROR: Undefined symbol: .PQsetNoticeReceiver ld: 0711-317 ERROR: Undefined symbol: .PQerrorMessage ld: 0711-317 ERROR: Undefined symbol: .last_path_separator collect2: ld returned 8 exit status gmake[4]: *** [libecpg_compat.so] Error 1 gmake[4]: Leaving directory `/usr/local/postgres/pgsql/src/interfaces/ecpg/compatlib' Looks like a missing -lpq but i wonder why you get it in compatlib. No libpq function is called there directly. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PERFORM] osdl-dbt3 run results - puzzled by the execution
On Fri, 19 Sep 2003 11:35:35 -0700, Jenny Zhang [EMAIL PROTECTED] wrote: I posted more results as you requested: Unfortunately they only confirm what I suspected earlier: 2) - Index Scan using i_ps_suppkey on partsupp (cost=0.00..323.16 rows=80 width=34) (actual time=0.16..2.98 rows=80 loops=380) ctr=108.44 the planner does not account for additional index scans hitting pages in the cache that have been brought in by preceding scans. This is a known problem PF1 = estimated number of page fetches for one loop ~ 320 L = estimated number of loops ~ 400 P = number of pages in relation ~ 21000 Cutting down the number of heap page fetches if PF1 * L P and P effective_cache_size seems like an obvious improvement, but I was not able to figure out where to make this change. Maybe it belongs into costsize.c near run_cost += outer_path_rows * (inner_path-total_cost - inner_path-startup_cost) * joininfactor; in cost_nestloop() or it should be pushed into the index cost estimation functions. Hackers? For now you have to keep lying about effective_cache_size to make the planner overestimate merge joins to compensate for the planner's overestimation of nested loops. Sorry for having no better answer. Servus Manfred ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ecpg build on AIX 4.2.1
Michael Meskes wrote: On Tue, Sep 23, 2003 at 04:21:10PM -0400, Samuel A Horwitz wrote: I am getting Undefined symbols in build ecpg ... ld: 0711-317 ERROR: Undefined symbol: .PQfinish ld: 0711-317 ERROR: Undefined symbol: .PQexec ld: 0711-317 ERROR: Undefined symbol: .PQclear ld: 0711-317 ERROR: Undefined symbol: .PQresultErrorField ld: 0711-317 ERROR: Undefined symbol: .PQsetdbLogin ld: 0711-317 ERROR: Undefined symbol: .PQstatus ld: 0711-317 ERROR: Undefined symbol: .PQsetNoticeReceiver ld: 0711-317 ERROR: Undefined symbol: .PQerrorMessage ld: 0711-317 ERROR: Undefined symbol: .last_path_separator collect2: ld returned 8 exit status gmake[4]: *** [libecpg_compat.so] Error 1 gmake[4]: Leaving directory `/usr/local/postgres/pgsql/src/interfaces/ecpg/compatlib' Looks like a missing -lpq but i wonder why you get it in compatlib. No libpq function is called there directly. Michael Correct. I had the same error on AIX 5.1 last week (see hackers' list). As far as 7.4beta is referred two additional patches are needed (see postings by Tom Lane on this topics). Adding the linker options will solve your problems and PostgreSQL will work nicely. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg build on AIX 4.2.1
Are these patches going to be applied soon? On Wed, 24 Sep 2003, [ISO-8859-1] Hans-Jürgen Schönig wrote: Date: Wed, 24 Sep 2003 13:18:32 +0200 From: [ISO-8859-1] Hans-Jürgen Schönig [EMAIL PROTECTED] To: Michael Meskes [EMAIL PROTECTED] Cc: Samuel A Horwitz [EMAIL PROTECTED], PostgreSQL Hackers [EMAIL PROTECTED] Subject: Re: [HACKERS] ecpg build on AIX 4.2.1 Michael Meskes wrote: On Tue, Sep 23, 2003 at 04:21:10PM -0400, Samuel A Horwitz wrote: I am getting Undefined symbols in build ecpg ... ld: 0711-317 ERROR: Undefined symbol: .PQfinish ld: 0711-317 ERROR: Undefined symbol: .PQexec ld: 0711-317 ERROR: Undefined symbol: .PQclear ld: 0711-317 ERROR: Undefined symbol: .PQresultErrorField ld: 0711-317 ERROR: Undefined symbol: .PQsetdbLogin ld: 0711-317 ERROR: Undefined symbol: .PQstatus ld: 0711-317 ERROR: Undefined symbol: .PQsetNoticeReceiver ld: 0711-317 ERROR: Undefined symbol: .PQerrorMessage ld: 0711-317 ERROR: Undefined symbol: .last_path_separator collect2: ld returned 8 exit status gmake[4]: *** [libecpg_compat.so] Error 1 gmake[4]: Leaving directory `/usr/local/postgres/pgsql/src/interfaces/ecpg/compatlib' Looks like a missing -lpq but i wonder why you get it in compatlib. No libpq function is called there directly. Michael Correct. I had the same error on AIX 5.1 last week (see hackers' list). As far as 7.4beta is referred two additional patches are needed (see postings by Tom Lane on this topics). Adding the linker options will solve your problems and PostgreSQL will work nicely. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at [EMAIL PROTECTED] (Samuel A Horwitz) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] creating/accessing new runtime parameters
I am writing a backend C function whose behavior should depend on the setting of a new runtime parameter that can be set with SET. I have several questions concerning how to implement this, as I can find no information in the documentation. - How can I introduce a new variable (e.g., XXX) to the system so that for example SET XXX=1 will work? - How can I access the value of such a variable from within a backend C function? Thanks for your help. Cheers, Brook ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ecpg build on AIX 4.2.1
Samuel A Horwitz wrote: Are these patches going to be applied soon? Correct. I had the same error on AIX 5.1 last week (see hackers' list). As far as 7.4beta is referred two additional patches are needed (see postings by Tom Lane on this topics). Adding the linker options will solve your problems and PostgreSQL will work nicely. Regards, Hans puh, good question. I think I have seen that Tom has applied at least one. I think the one you have requested has not been applied yet. You have to check the COMMITTERS' list to find out. To be honest I don't have it in mind. Tom or Michael Meskes will know for sure. Regards, Hans -- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706; +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_dump doesn't dump binary compatible casts
On Tue, 2003-09-23 at 22:40, Greg Stark wrote: [But then I'm not a fan of treating pg_dump files as if they were backups.] If you don't use pg_dump for backups what do you use? Stop the database and copy the data directory? That is not a valid choice for most people. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] creating/accessing new runtime parameters
[EMAIL PROTECTED] writes: - How can I introduce a new variable (e.g., XXX) to the system so that for example SET XXX=1 will work? The basic thing is to add an appropriate table entry to guc.c. You might try searching the sources for all references to one of the lesser-used GUC variables, perhaps default_statistics_target, to get a feeling for what's involved. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PERFORM] osdl-dbt3 run results - puzzled by the execution
Manfred Koizar [EMAIL PROTECTED] writes: Cutting down the number of heap page fetches if PF1 * L P and P effective_cache_size seems like an obvious improvement, but I was not able to figure out where to make this change. Maybe it belongs into costsize.c near run_cost += outer_path_rows * (inner_path-total_cost - inner_path-startup_cost) * joininfactor; I've been intending for some time to try to restructure the cost estimator so that repeated indexscans can be costed more accurately. Within the context of the heap-fetch-estimating algorithm, I think the entire execution of a nestloop-with-inner-index-scan could probably be treated as a single scan. I'm not sure how we adjust the estimates for the index-access part, though clearly those are too high as well. This doesn't seem to be a localized change unfortunately. Certainly costsize.c can't do it alone. regards, tom lane ---(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] no subject
Hello , I m new to this list . Hopefully some feedback is coming to my questions. 1) Did somebody a compile with the Intel ICC inclusive performance logging 2) Is there a hint where to find in the source the REGEX module and is there any connection to inheritance of table.(module ???). 3) Is there a short description for shared memory use in PostgreSQL Thanks in advance Gottfried ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] compile failure with beta3 and --with-perl
Slackware 8.1, linux 2.4.18 i586, gcc version 2.95.3 20010315 (release)
This is perl, v5.6.1 built for i386-linux (is this too old?)
parts from config.log
configure:4214: checking for perl
configure:4232: found /usr/local/bin/perl
configure:4244: result: /usr/local/bin/perl
configure:4253: checking for Perl archlibexp
configure:4256: result: /usr/lib/perl5/i386-linux
configure:4258: checking for Perl privlibexp
configure:4261: result: /usr/lib/perl5
configure:4263: checking for Perl useshrplib
configure:4266: result: false
configure:4269: checking for flags to link embedded Perl
configure:4274: result: -L/usr/local/lib
/usr/lib/perl5/i386-linux/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/i386-linux/CORE -lperl -lnsl -ldl -lm -lc -lcrypt
-lutil
ac_cv_path_PERL=/usr/local/bin/perl
make[4]: Leaving directory
`/usr/local/src/postgresql-7.4beta3/src/pl/tcl/modules'
make[3]: Leaving directory
`/usr/local/src/postgresql-7.4beta3/src/pl/tcl'
make[3]: Entering directory
`/usr/local/src/postgresql-7.4beta3/src/pl/plperl'
gcc -O2 -g -fpic -I. -I/usr/lib/perl5/i386-linux/CORE
-I../../../src/include -c -o plperl.o plperl.c -MMD
plperl.c: In function `plperl_create_sub':
plperl.c:306: warning: passing arg 1 of `perl_call_pv' from incompatible
pointer type
plperl.c:306: warning: passing arg 2 of `perl_call_pv' makes pointer
from integer without a cast
plperl.c:306: too few arguments to function `perl_call_pv'
plperl.c:317: `thr' undeclared (first use in this function)
plperl.c:317: (Each undeclared identifier is reported only once
plperl.c:317: for each function it appears in.)
plperl.c: In function `plperl_call_perl_func':
plperl.c:425: warning: passing arg 1 of `perl_call_sv' from incompatible
pointer type
plperl.c:425: warning: passing arg 2 of `perl_call_sv' makes pointer
from integer without a cast
plperl.c:425: too few arguments to function `perl_call_sv'
plperl.c:437: `thr' undeclared (first use in this function)
plperl.c: In function `plperl_build_tuple_argument':
plperl.c:810: warning: passing arg 1 of `perl_eval_pv' from incompatible
pointer type
plperl.c:810: warning: passing arg 2 of `perl_eval_pv' makes pointer
from integer without a cast
plperl.c:810: too few arguments to function `perl_eval_pv'
make[3]: *** [plperl.o] Error 1
make[3]: Leaving directory
`/usr/local/src/postgresql-7.4beta3/src/pl/plperl'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/local/src/postgresql-7.4beta3/src/pl'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/postgresql-7.4beta3/src'
make: *** [all] Error 2
any ideas?
need any other info?
thanks in advance,
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] creating/accessing new runtime parameters
Tom Lane writes: The basic thing is to add an appropriate table entry to guc.c. I take it there is not way to do this dynamically, for example to support a dynamically loaded function? All runtime variables are hard-coded into the backend? Thanks for your help. Cheers, Brook ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] creating/accessing new runtime parameters
[EMAIL PROTECTED] writes: Tom Lane writes: The basic thing is to add an appropriate table entry to guc.c. I take it there is not way to do this dynamically, for example to support a dynamically loaded function? Not at the moment, although IIRC the guc.c data structures are designed to make it possible to add things on-the-fly. (There's a pointer table that's built dynamically, and in theory could contain more entries than are in the hardcoded tables.) You'd need to add a routine to actually add an entry ... and figure out where to call it from ... regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] creating/accessing new runtime parameters
[EMAIL PROTECTED] wrote: Tom Lane writes: The basic thing is to add an appropriate table entry to guc.c. I take it there is not way to do this dynamically, for example to support a dynamically loaded function? All runtime variables are hard-coded into the backend? Maybe you can implement your stuff using a temporary table? Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] invalid tid errors in latest 7.3.4 stable.
Hello Tom, In trying to come up with a test scenario, I loaded this db into a 7.4 db and got a similar message. It shows up as follows: dropsites= begin; BEGIN dropsites= delete from te_users where reseller = 21; ERROR: attempted to mark4update invisible tuple CONTEXT: PL/pgSQL function c_delete_categories line 14 at SQL statement dropsites= Is this the same message using the new error reporting framework? -Wade On September 23, 2003 09:44 pm, Tom Lane wrote: Wade Klaver [EMAIL PROTECTED] writes: Stumbled across an odd problem while cleaning data out of a database. I am getting these invalid tid errors. I tried the upgrade from 7.3.2 to 7.3.4. Hm. We fixed something with a similar symptom as of 7.3.3: http://archives.postgresql.org/pgsql-hackers/2003-03/msg01099.php If you are still seeing it in 7.3.4 then maybe there's another related problem. Could you work up a self-contained test case? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Wade Klaver Wavefire Technologies Corporation GPG Public Key at http://archeron.wavefire.com /\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ecpg build on AIX 4.2.1
On Wed, Sep 24, 2003 at 01:18:32PM +0200, Hans-Jrgen Schnig wrote: Correct. I had the same error on AIX 5.1 last week (see hackers' list). As far as 7.4beta is referred two additional patches are needed (see postings by Tom Lane on this topics). So adding $(filter -lssl -lm) does fix this? Adding the linker options will solve your problems and PostgreSQL will work nicely. Probably in the same manner. I'm sorry, I didn't see the other mails. They simply got lost in that virus flood happening these days. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] creating/accessing new runtime parameters
Andreas Pflug writes: Maybe you can implement your stuff using a temporary table? Perhaps, but the runtime variable route is much more natural from a user interface perspective, as there are strong parallels with existing variables. I'll see what I can do in that arena first. Thanks for the idea, though. Cheers, Brook ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] invalid tid errors in latest 7.3.4 stable.
Wade Klaver [EMAIL PROTECTED] writes: In trying to come up with a test scenario, I loaded this db into a 7.4 db and got a similar message. It shows up as follows: ERROR: attempted to mark4update invisible tuple CONTEXT: PL/pgSQL function c_delete_categories line 14 at SQL statement Is this the same message using the new error reporting framework? Yes, I believe so. regards, tom lane ---(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] [GENERAL] pgindented tsearch2 for 7.3.4
Nigel J. Andrews wrote:
I never knew running indent was so damn complicated. All three of my
development systems can not manage it without throughing a fault (I've
absolutely no idea why indent in the shell works but doesn't in pgindent on
one).
Anyway, has anyone pgindented the version of tsearch2 that runs with 7.3.4? If
so please email it to me. The tar file is tsearch-v2-stable.tar.gz, just for
clarity and I can supply it if someone volunteers but doesn't have it.
There are about 6 files that can't be run through pgindent, and tsearch2
has one of them:
$ pgindent *.c
Hope you installed /src/tools/pgindent/indent.bsd.patch.
gistidx.c
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
[EMAIL PROTECTED]: Unbalanced parens
[EMAIL PROTECTED]: Extra )
It is actually this code that is causing it:
LOOPBYTE(
if ((sign[i] 0xff) != 0xff)
PG_RETURN_POINTER(retval);
);
With the macro being:
#define LOOPBYTE(a) \
for(i=0;iSIGLEN;i++) {\
a;\
}
If you ask me, this is just _weird_ code and should not be allowed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] creating/accessing new runtime parameters
Tom Lane wrote: [EMAIL PROTECTED] writes: I take it there is not way to do this dynamically, for example to support a dynamically loaded function? Not at the moment, although IIRC the guc.c data structures are designed to make it possible to add things on-the-fly. (There's a pointer table that's built dynamically, and in theory could contain more entries than are in the hardcoded tables.) You'd need to add a routine to actually add an entry ... and figure out where to call it from ... I had a patch about 80% complete to do this, but it was rejected. The comment was that I should use a temp table instead. I still think it would be useful myself. See this thread: http://archives.postgresql.org/pgsql-hackers/2002-12/msg00988.php Joe ---(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] pg_dump doesn't dump binary compatible casts
Matthew T. O'Connor [EMAIL PROTECTED] writes: On Tue, 2003-09-23 at 22:40, Greg Stark wrote: [But then I'm not a fan of treating pg_dump files as if they were backups.] If you don't use pg_dump for backups what do you use? Stop the database and copy the data directory? That is not a valid choice for most people. It's currently the only way to do a real backup though. I haven't gone to production yet with my first postgres project but that's certainly what I'm planning to recommend to my client. pg_dump files are not backups. When you've restored a pg_dump you don't necessarily get back the exact same data you had when you dumped it. Every piece of data is serialized and then unserialized, space has to be allocated anew, the DDL has to be reinterpreted. pg_dump has to spend the time to rebuild tables and indexes too. A straight physical backup doesn't have to do any of that. pg_dumps are a logical export, not a physical backup. A lot of work goes into guaranteeing pg_dump/pg_restore reliably generates equivalent databases, but even so there are always corner cases as the original post describes. What if there's a bug and some piece of data doesn't unserialize correctly (arrays didn't in 7.3 if their lower bound wasn't 1 for example). Or if there's a bug and the database core dumps trying to rebuild indexes? Or for that matter if the machine available just wasn't powerful enough to generate the indexes at all. I would tend to prefer pg_dump/pg_restore files if they were an option because the resulting database would be more compact, the indexes more balanced, and any data corruption would be cleaned up. but I wouldn't feel safe unless I had a real physical backup ready to use in case the pg_dump didn't work, or took too long. Every time I've tried to restore from a pg_dump I've run into small problems like this. That's fine when I'm doing development, but in a crisis you have to have an image you can restore and be sure it'll be *exactly* the same as it was before the failure. Fwiw, there is a hardware solution to doing 24x7 operation without online backups. You store the database on a raid mirror (preferably a 3-way mirror so you're never without mirroring). When the time comes to do the backup you break the mirror, use the inactive side to do the backup. The backup you get is exactly what you would have gotten had the machine crashed at the point in time that you broke the mirror. We used to do something similar even with Oracle because it was easier and faster than its hot backup system. This solution requires money for good raid controllers and lots of disks though. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [GENERAL] pgindented tsearch2 for 7.3.4
Bruce Momjian wrote:
It is actually this code that is causing it:
LOOPBYTE(
if ((sign[i] 0xff) != 0xff)
PG_RETURN_POINTER(retval);
);
With the macro being:
#define LOOPBYTE(a) \
for(i=0;iSIGLEN;i++) {\
a;\
}
If you ask me, this is just _weird_ code and should not be allowed.
Amen :-)
This reminds me of the famous Real Programmers Don't Use Pascal, which
says:
If you ignore the fact that it's structured, even 'C' programming can
be appreciated by the Real Programmer: after all, there's no type
checking, variable names are seven (ten? eight?) characters long, and
the added bonus of the Pointer data type is thrown in-like having the
best parts of *FORTRAN * and assembly language in one place (not to
mention some of the more creative uses for *#DEFINE*).
:-)
cheers
andrew
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Darwin compile flags
Tom Lane wrote: CVSROOT: /cvsroot Module name: pgsql-server Changes by: [EMAIL PROTECTED] 03/09/19 17:47:59 Modified files: src/template : darwin Log message: Latest version of gcc from Apple does not work well with -traditional-cpp (it rejects some system header files...). Use -no-cpp-precomp instead. I think it is okay to change this unconditionally, but if we hear complaints from people still using very old compilers on Darwin, we could put in a test to see which switch the compiler likes. Yes, I saw this failure in Atlanta on their Mac's. The compiler is clearly broken with that flag. Why is that flag used anyway? I see it in template/darwin, or it used to be there before the commit. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] [GENERAL] pgindented tsearch2 for 7.3.4
On Wed, 24 Sep 2003, Bruce Momjian wrote: Nigel J. Andrews wrote: I never knew running indent was so damn complicated. All three of my development systems can not manage it without throughing a fault ... There are about 6 files that can't be run through pgindent, and tsearch2 has one of them: $ pgindent *.c Hope you installed /src/tools/pgindent/indent.bsd.patch. gistidx.c [EMAIL PROTECTED]: Unbalanced parens [EMAIL PROTECTED]: Extra ) [EMAIL PROTECTED]: Unbalanced parens ... It was a far more basic problem than that! I'd have been pleased if I'd got as far as that. You developers of today don't know you're born. Back in my day we used to have to get up before noon just to turn the computer on... Actually, I had a problem in that I only had GNU indent and BSD indent that was core dumping but it was unpatched, plus I couldn't find the BSD indent source on the web. Eventually found it, in a linux distribution of all places, and then I got the above errors, by which time I was quite prepared to not count those as such. There are a few macro's defined that make me think of fortran programmers moving to C. Anyway Bruce, you'll see the patch eventually generated lower down you inbox. -- Nigel J. Andrews ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Darwin compile flags
Bruce Momjian writes: Yes, I saw this failure in Atlanta on their Mac's. The compiler is clearly broken with that flag. Why is that flag used anyway? I see it in template/darwin, or it used to be there before the commit. In early versions you needed to use it to turn of the header precompiler. (The precompiler is apparently buggy.) Now there is a separate flag for that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Darwin compile flags
Peter Eisentraut [EMAIL PROTECTED] writes: In early versions you needed to use it to turn of the header precompiler. (The precompiler is apparently buggy.) Now there is a separate flag for that. I just two days ago verified that with Apple's latest compiler release, you can only build PG with -no-cpp-precomp. -traditional-cpp fails, and so does leaving off the cpp option entirely (in a different way though). They seem to have changed the behavior of -traditional-cpp, because it used to work with older Apple compilers. (So much for tradition ...) I think these failures represent bugs in Apple's preprocessors, given that everything else under the sun can compile PG. But it's not really worth worrying about; we'll just use the recommended flag and be done with it. 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] PostgreSQL not ACID compliant?
Philip Yarra wrote: It's funny timing - I had to prepare a comparison between PostgreSQL and MySQL recently, explaining why we would prefer PostgreSQL. I know some people here have issues with the MySQL crashme test results, but I have to say I found it possibly one of the best postgreSQL advertisements available. A 4-way comparison between Sybase, Oracle, MySQL and PostgreSQL shows PostgreSQL in an extremely flattering light. They have been improving their fairness over at MySQL. I know Zak Greant (added as CC) removed all the inaccurate PostgreSQL stuff that was in the MySQL manuals. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] no subject
Gottfried F. Zojer writes: 1) Did somebody a compile with the Intel ICC inclusive performance logging There have been varying degrees of success with the Intel compiler suite. The 7.4 development branch can be compiled with icc, earlier versions not without extra hacking. Some people have reported slight performance improvements, but in general PostgreSQL is I/O bound, so it shouldn't matter much. Others have also reported that binaries generated by icc corrupt the database or don't start at all. See the archives for details. My opinion is that it's not really worth the trouble. 2) Is there a hint where to find in the source the REGEX module src/backend/regexp and is there any connection to inheritance of table.(module ???). No. 3) Is there a short description for shared memory use in PostgreSQL You can find some small hints at http://www.postgresql.org/docs/7.3/static/kernel-resources.html#SYSVIPC but there isn't really any developer-level documentation for that. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] creating/accessing new runtime parameters
Joe Conway writes: I had a patch about 80% complete to do this, but it was rejected. The comment was that I should use a temp table instead. I still think it would be useful myself. See this thread: http://archives.postgresql.org/pgsql-hackers/2002-12/msg00988.php I'm sorry that was rejected. I can see that there might be error checking issues, but perhaps that simply means some hooks to register validation functions dynamically that could be called during SET. As far as the general utility of it goes, I claim that it could be quite valuable. I am thinking of complex new datatypes (that might be dynamically loaded) that could benefit from having some run-time variables specify some aspect of their behavior. Currently, we have variables controlling the I/O of dates and times, for example. Something analogous would potentially be useful for other datatypes. Without the ability to dynamically add to the set of run-time variables, it is impossible to write a datatype that has this property. In these cases, one really does want run-time variables, not temporary tables, as the use exactly corresponds to the use for existing variables: modifying the behavior of interal functions. Cheers, Brook ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] creating/accessing new runtime parameters
[EMAIL PROTECTED] writes: As far as the general utility of it goes, I claim that it could be quite valuable. I am thinking of complex new datatypes (that might be dynamically loaded) that could benefit from having some run-time variables specify some aspect of their behavior. Currently, we have variables controlling the I/O of dates and times, for example. Something analogous would potentially be useful for other datatypes. Consider it an encouragement to have your data types not duplicate any of the various insane properties that date/time types have, imposed by the real world. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Is this a commit problem?
I've been observing a interesting behavior with our DBT-2 workload. It appears that a commit to a transaction is taking some time to occur. I'll try to briefly describe what we're seeing. The transaction goes something like this: 1. BEGIN 2. SELECT d_next_o_id INTO current_o_id FROM district WHERE d_w_id = 1 AND d_id = 8 3. UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_w_id = 1 AND d_id = 8 4. INSERT INTO new_order (no_o_id, no_w_id, no_d_id) VALUES (current_o_id, 1, 8) 5. COMMIT/ROLLBACK The transaction is implemented as a C stored function and is called through the liqpq interface with an isolation level of read committed and autocommit set to false. The first pass through this transaction appears to execute correctly, and a COMMIT is executed in step 5. The second pass through reads an old d_next_i_id in step 2. For example, if d_next_o_id is 300 in the first pass, it should also be updated to 301. The next time this transaction is called, it is still 300. Also, on the second instance the transaction is called, step 4 causes the libpq library to throw a 'Cannot insert a duplicate key into unique index pk_new_order' error so my application executes a ROLLBACK, since the no_o_id, no_w_id, no_d_id columns are the primary key in the new_order table. I can verify that the first transaction is eventually committed to the database by examining the data in the database after the test has run. This only occurs about 1% of the time. I'm not sure how else to analyze the situation. Let me know if I can clarify anything or provide any more information. Thanks! -- Mark Wong - - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503) 626-2455 x 32 (office) (503) 626-2436 (fax) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] invalid tid errors in latest 7.3.4 stable.
Wade Klaver [EMAIL PROTECTED] writes: OK, I set you up a login on arch.wavefire.com Okay, what I find is this sequence of events: 1. delete from te_users where id = 954; 2. The ON DELETE CASCADE RI constraint propagates this to a delete of some row(s) in c_categories. 3. That fires the c_delete_categories BEFORE DELETE trigger. 4. That does several things including UPDATE c_categories SET lft = lft - 2 WHERE lft old.rgt; 5. This update command suffers a Halloween problem, namely trying to update rows it's already updated. Why does it do that, you ask? Because ReferentialIntegritySnapshotOverride is true, since we are inside the ON DELETE CASCADE RI trigger and haven't yet returned from any trigger. So instead of using the correct snapshot for the UPDATE command, tqual.c mistakenly uses SnapshotNow rules. We have successfully executed a select or two inside the trigger function already, so CurrentCommandId is greater than the command ID associated with the UPDATE command, making the updated rows visible. Oops. I think this is proof of something I've felt since day one, namely that a global ReferentialIntegritySnapshotOverride flag is an unusable hack. How can we get rid of it? Why did we need it in the first place? (I suspect the proper answer for how can we get rid of it will be to extend the Executor API so that the RI functions can tell the executor to use SnapshotNow as es_snapshot, instead of a standard query snapshot. But I'm wondering why we have to do this at all.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] More Prelimiary DBT-2 Test Results with PostgreSQL
On 22 Sep, Greg Stark wrote: [EMAIL PROTECTED] writes: http://developer.osdl.org/markw/74/ Are those response times in the right unit? 7-10s? Yeah, the database really isn't tuned at all. I've gotten some suggestions off the list that I will be trying. I'll report them as I complete them. Are these mostly full table scans and big batch updates? The plans (http://developer.osdl.org/markw/74/db/plan0.out) don't show any table scans. They appears to be mostly index scans. There aren't any batch updates. Personally, I'm more interested in seeing OLTP-oriented benchmarks testing quick index based transactions in the 20-200ms range, not big i/o-bound batch transactions. There's certainly a need for both, but I think the former are much more important to micro-optimize, at least for my needs. Right, and when this thing is tuned better, I expect the transactions to be down in the 20-200ms range. I do have about 70 drives for the database, so it really shouldn't be i/o bound at with the size of the database I'm using now, which is about 20 or 30 GB. Mark ---(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] creating/accessing new runtime parameters
Peter Eisentraut [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: As far as the general utility of it goes, I claim that it could be quite valuable. I am thinking of complex new datatypes (that might be dynamically loaded) that could benefit from having some run-time variables specify some aspect of their behavior. Currently, we have variables controlling the I/O of dates and times, for example. Something analogous would potentially be useful for other datatypes. Consider it an encouragement to have your data types not duplicate any of the various insane properties that date/time types have, imposed by the real world. Unfortunately, real-world requirements impinge upon most things ;-) I'm somewhat persuaded by Brook's argument. The original discussion didn't really reject the idea of allowing addition of new GUC variables; the concerns were about how and when to do that. We didn't like Joe's suggestion of registering any random name that happens to appear in postgresql.conf (no error checking, and besides how would you deduce the type and other properties?). However, it seems like you *would* like added-on names to be settable from postgresql.conf, so just allowing dynamically loaded modules to add them when first invoked by a backend would be very limiting. Now that we have the notion of postmaster-preloaded dynamic libraries, I was thinking maybe we could let those libraries define new GUC variables. Right now, preload_libraries doesn't get processed until after we've scanned guc.c, but maybe that could be rethought. Could we preload a library at the instant we see the preload_library setting in guc.c, allowing it to define GUC vars that will be recognized later in the file? There are probably other ways we could attack it, too, but that was the first thing that came to mind. regards, tom lane ---(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] Is this a commit problem?
[EMAIL PROTECTED] writes: This only occurs about 1% of the time. I'm not sure how else to analyze the situation. Let me know if I can clarify anything or provide any more information. Are you running more than one of these transactions in parallel, overlapping? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Is this a commit problem?
On 25 Sep, Peter Eisentraut wrote: [EMAIL PROTECTED] writes: This only occurs about 1% of the time. I'm not sure how else to analyze the situation. Let me know if I can clarify anything or provide any more information. Are you running more than one of these transactions in parallel, overlapping? Yes, but each transaction has a unique d_w_id, d_id pair, so there is never any 2 transactions touching the same row in the district table. Mark ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [ADMIN] postgres 6.2 vacuum
I wonder if we should have an auto-responder so when someone says they are running 6.5, we can reply --- Yikes, upgrade. In fact, we could go with a little chart: 7.3.4 great 7.3.0-3 please upgrade, it is easy 7.2 consider upgrading 7.1 wow, that is old 7.0 you need an upgrade, pal =6.5 run, don't walk, to the nearest PostgreSQL ftp server --- Hornyak Laszlo wrote: Yes, at the end we did the port at night, and in the morning the system started without any problem. Some of the dumps from pg 6.2 was not realy acceptable by 7.3, but it was easy to fix. Thank you for your help! Laszlo Hornyak On Tue, 23 Sep 2003, scott.marlowe wrote: On Mon, 22 Sep 2003, Hornyak Laszlo wrote: Hi all! We have a database on postgreSQL 6.2 and it is extremely slow, so we started vacuum on it. I know it locks the tables, so clients can not use it until the process is finished, but it is extremely slow on a 1.800.000 record table and we don't know how to make it faster. Can anybody help me? It seems it is writing an index file, but it grows very slowly. I know we should use 7.3 at least, we are working on it, but we need to survive this day with 6.2 :( In all honesty, it'd probably be faster to convert than to wait for that vacuum to finish. seriously. 6.2 is like the model A of Postgresql versions. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] More Prelimiary DBT-2 Test Results with PostgreSQL 7.3.4
[EMAIL PROTECTED] writes: On 22 Sep, Greg Stark wrote: Are those response times in the right unit? 7-10s? The plans (http://developer.osdl.org/markw/74/db/plan0.out) don't show any table scans. They appears to be mostly index scans. There aren't any batch updates. Would it be easy to generate this file doing explain analyze instead? It would give me a better idea what you're doing since I don't know much about the data. Just looking at the plans I don't see how any of these queries could possibly take 7s. There are two that could possibly take a few hundred milliseconds, the others I would expect to be under 100ms. Obviously this is all just a gut reaction, not having looked at the data, and it would depend on the hardware. But none of the queries look like they should measuring reaction times in seconds. Right, and when this thing is tuned better, I expect the transactions to be down in the 20-200ms range. I do have about 70 drives for the database, so it really shouldn't be i/o bound at with the size of the database I'm using now, which is about 20 or 30 GB. 70 drives for 20-30G? That's pretty extreme. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] compile failure with beta3 and --with-perl
Robert Treat [EMAIL PROTECTED] writes: Slackware 8.1, linux 2.4.18 i586, gcc version 2.95.3 20010315 (release) This is perl, v5.6.1 built for i386-linux (is this too old?) Hm. On HPUX 10.20, I can report that CVS tip plperl seems to work with perl 5.8.0 (at least it can execute a simple function). Using 5.6.1 instead, it builds without complaint and I can createlang plperl, but executing the perl_max example from the docs causes a core dump inside the Perl interpreter. I have some recollection that I never could get 5.6.1 to work with plperl on this machine, so this isn't necessarily a regression. It's odd that you see a compile failure though. Are you sure you have used matching header files and Perl libraries? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] invalid tid errors in latest 7.3.4 stable.
On Wed, 24 Sep 2003, Tom Lane wrote: Wade Klaver [EMAIL PROTECTED] writes: OK, I set you up a login on arch.wavefire.com Okay, what I find is this sequence of events: 1. delete from te_users where id = 954; 2. The ON DELETE CASCADE RI constraint propagates this to a delete of some row(s) in c_categories. 3. That fires the c_delete_categories BEFORE DELETE trigger. 4. That does several things including UPDATE c_categories SET lft = lft - 2 WHERE lft old.rgt; 5. This update command suffers a Halloween problem, namely trying to update rows it's already updated. Why does it do that, you ask? Because ReferentialIntegritySnapshotOverride is true, since we are inside the ON DELETE CASCADE RI trigger and haven't yet returned from any trigger. So instead of using the correct snapshot for the UPDATE command, tqual.c mistakenly uses SnapshotNow rules. We have successfully executed a select or two inside the trigger function already, so CurrentCommandId is greater than the command ID associated with the UPDATE command, making the updated rows visible. Oops. I think this is proof of something I've felt since day one, namely that a global ReferentialIntegritySnapshotOverride flag is an unusable hack. How can we get rid of it? Why did we need it in the first place? (I suspect the proper answer for how can we get rid of it will be to extend the Executor API so that the RI functions can tell the executor to use SnapshotNow as es_snapshot, instead of a standard query snapshot. But I'm wondering why we have to do this at all.) I think if you have something like: create table test1 (id int primary key, otherid int references test1); insert into test1 values (4,4); T1: begin; T1: set transaction isolation level serializable; T1: select * from test1; T2: begin; T2: insert into test1 values (5,4); T2: end; T1: delete from test1 where id=4; -- I think the standard snapshot rules would mean that the row 5,4 would be hidden from the select in the trigger, which means that the delete would be allowed, where it should fail since that'd leave an orphaned child row. Or at least I've commented out the updates to ReferentialIntegritySnapshotOverride in my local ri_triggers.c and see behavior consistent with that (that the delete succeeds and the child row is orphaned). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] More Prelimiary DBT-2 Test Results with PostgreSQL
On 24 Sep, Greg Stark wrote: [EMAIL PROTECTED] writes: On 22 Sep, Greg Stark wrote: Are those response times in the right unit? 7-10s? The plans (http://developer.osdl.org/markw/74/db/plan0.out) don't show any table scans. They appears to be mostly index scans. There aren't any batch updates. Would it be easy to generate this file doing explain analyze instead? It would give me a better idea what you're doing since I don't know much about the data. No problem: http://developer.osdl.org/markw/misc/plana.out Just looking at the plans I don't see how any of these queries could possibly take 7s. There are two that could possibly take a few hundred milliseconds, the others I would expect to be under 100ms. Obviously this is all just a gut reaction, not having looked at the data, and it would depend on the hardware. But none of the queries look like they should measuring reaction times in seconds. I have a 4-way 1.5Ghz Xeon with 256KB cache and hyper-threading enabled and 4GB of memory. Although the disk controllers are reducing my physical memory by about 500MB. I can provide more details if you like. Right, and when this thing is tuned better, I expect the transactions to be down in the 20-200ms range. I do have about 70 drives for the database, so it really shouldn't be i/o bound at with the size of the database I'm using now, which is about 20 or 30 GB. 70 drives for 20-30G? That's pretty extreme. Yeah, we're starting small but we'll increase the database size as we move along. Mark ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Is this a commit problem?
[EMAIL PROTECTED] wrote: 2. SELECT d_next_o_id INTO current_o_id FROM district WHERE d_w_id = 1 AND d_id = 8 3. UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_w_id = 1 AND d_id = 8 I don't know exactly what you are trying to do but usualy in cases like this, in order to avoid further problem in the commit phase you ought to do a SELECT FOR UPDATE instead. Regards Gaeatano Mendola ---(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] More Prelimiary DBT-2 Test Results with PostgreSQL 7.3.4
[EMAIL PROTECTED] writes: On 24 Sep, Greg Stark wrote: [EMAIL PROTECTED] writes: On 22 Sep, Greg Stark wrote: Are those response times in the right unit? 7-10s? No problem: http://developer.osdl.org/markw/misc/plana.out Ok, I guess I misunderstood you. These queries are taking 0.5ms - 300ms except for the last aggregate query which takes just over 1s. -- greg ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Error message cleanup
On Sun, Sep 21, 2003 at 05:37:59PM +0200, Peter Eisentraut wrote: I've looked through the messages in the backend and identified some areas that still deserve some cleanup. Below I list some issues that deserve some discussion or that deserve being remembered by other developers. id, oid, pid - ID, OID, PID attribute - column tuple - row or row state, depending on context Are you going to change relation to table? In most cases that is the intended meaning. ISTM in some other cases it refers to anything that can appear in pg_class, but I'm not 100% sure. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Announcement: planned open source billing system demonstration
Ruben Safir Secretary NYLXS wrote: And what is the licensing? Looking at their web pages, they provide the services, not the software. On Tue, Sep 23, 2003 at 06:06:00PM -0700, Richard Schilling wrote: Just wanted to drop you all a quick note that CogBilling, an online billing system which integrates with GnuCash, is now available for review at http://www.rsmba.biz/download. CogBilling is an online database driven billing system written entirely on open source products. In its present state it's intentionally void of heavy graphic images and creature features to maximize flexibility in developing future versions. CogBilling is intended to be useful for any professional services organization, but ultimately should function especially well in organizations that do software development, legal services and the like. Furthermore, CogBilling is intended to be integrated into large IT infrastructures such as those found in healthcare institutions, clinics and physician practices. . -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)612-INET http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] [pgsql-advocacy] Announcement: planned open source billing system demonstration now available
I'll be posting the license on our website soon. But, the license for our original work, prior to an Open Source release, is an open source license except that the end user cannot distribute the product beyond their immediate control (e.g. their company). And, the changes one client makes to the product becomes available to all the other clients. It's kind of like an open source license that applies just to our clients. The only restriction really is non-distribution. If/when a software product gets released under and open source license we incorporate the changes that clients have made to customize the product prior to release. So, if we have 20 customers using the same product and they've had customizations done. It's working out pretty well. We're using this model for the software we built for http://www.thenew-hometeam.com. So, yes, the mature version of the home listing search engine we built will eventually be released under a general open source license. Richard Schilling On 2003.09.23 18:15 Ruben Safir Secretary NYLXS wrote: And what is the licensing? On Tue, Sep 23, 2003 at 06:06:00PM -0700, Richard Schilling wrote: Just wanted to drop you all a quick note that CogBilling, an online billing system which integrates with GnuCash, is now available for review at http://www.rsmba.biz/download. CogBilling is an online database driven billing system written entirely on open source products. In its present state it's intentionally void of heavy graphic images and creature features to maximize flexibility in developing future versions. CogBilling is intended to be useful for any professional services organization, but ultimately should function especially well in organizations that do software development, legal services and the like. Furthermore, CogBilling is intended to be integrated into large IT infrastructures such as those found in healthcare institutions, clinics and physician practices. This application is the first public release of our planned open source applications. Once we can sustain continuous development of the application through the sale of services and website hosting we will release the whole thing under a traditional open source license (e.g. Gnu, BSD, etc . . .). At the present, we expect this to occur in the spring or summer of 2004. For the more technically inclined, CogBilling was written in Embedded Perl (Embperl), and uses a PostgreSQL database as the backend. It is hosted on the latest version of the Apache web server. This is the first beta release of the product, so the user interface promises to be a bit rough, and the online manual is not presently available. However, you will find that the system's basic functionality works. Future directions we have planned with this product is deeper integration with GnuCash at the database level, integration with GnoTime, and integration with Issue Tracker. You can e-mail me directly, but for the benefit of the Open Source community you should also post comments, criticisms or suggestions posted to this discussion list. Thank you. Richard Schilling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Brooklyn Linux Solutions __ DRM is THEFT - We are the STAKEHOLDERS http://fairuse.nylxs.com http://www.mrbrklyn.com - Consulting http://www.inns.net -- Happy Clients http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive or stories and articles from around the net http://www2.mrbrklyn.com/downtown.html - See the New Downtown Brooklyn 1-718-382-0585 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(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] Announcement: planned open source billing system demonstration now available
And what is the licensing? On Tue, Sep 23, 2003 at 06:06:00PM -0700, Richard Schilling wrote: Just wanted to drop you all a quick note that CogBilling, an online billing system which integrates with GnuCash, is now available for review at http://www.rsmba.biz/download. CogBilling is an online database driven billing system written entirely on open source products. In its present state it's intentionally void of heavy graphic images and creature features to maximize flexibility in developing future versions. CogBilling is intended to be useful for any professional services organization, but ultimately should function especially well in organizations that do software development, legal services and the like. Furthermore, CogBilling is intended to be integrated into large IT infrastructures such as those found in healthcare institutions, clinics and physician practices. This application is the first public release of our planned open source applications. Once we can sustain continuous development of the application through the sale of services and website hosting we will release the whole thing under a traditional open source license (e.g. Gnu, BSD, etc . . .). At the present, we expect this to occur in the spring or summer of 2004. For the more technically inclined, CogBilling was written in Embedded Perl (Embperl), and uses a PostgreSQL database as the backend. It is hosted on the latest version of the Apache web server. This is the first beta release of the product, so the user interface promises to be a bit rough, and the online manual is not presently available. However, you will find that the system's basic functionality works. Future directions we have planned with this product is deeper integration with GnuCash at the database level, integration with GnoTime, and integration with Issue Tracker. You can e-mail me directly, but for the benefit of the Open Source community you should also post comments, criticisms or suggestions posted to this discussion list. Thank you. Richard Schilling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Brooklyn Linux Solutions __ DRM is THEFT - We are the STAKEHOLDERS http://fairuse.nylxs.com http://www.mrbrklyn.com - Consulting http://www.inns.net -- Happy Clients http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive or stories and articles from around the net http://www2.mrbrklyn.com/downtown.html - See the New Downtown Brooklyn 1-718-382-0585 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Announcement: planned open source billing system demonstration now available
Just wanted to drop you all a quick note that CogBilling, an online billing system which integrates with GnuCash, is now available for review at http://www.rsmba.biz/download. CogBilling is an online database driven billing system written entirely on open source products. In its present state it's intentionally void of heavy graphic images and creature features to maximize flexibility in developing future versions. CogBilling is intended to be useful for any professional services organization, but ultimately should function especially well in organizations that do software development, legal services and the like. Furthermore, CogBilling is intended to be integrated into large IT infrastructures such as those found in healthcare institutions, clinics and physician practices. This application is the first public release of our planned open source applications. Once we can sustain continuous development of the application through the sale of services and website hosting we will release the whole thing under a traditional open source license (e.g. Gnu, BSD, etc . . .). At the present, we expect this to occur in the spring or summer of 2004. For the more technically inclined, CogBilling was written in Embedded Perl (Embperl), and uses a PostgreSQL database as the backend. It is hosted on the latest version of the Apache web server. This is the first beta release of the product, so the user interface promises to be a bit rough, and the online manual is not presently available. However, you will find that the system's basic functionality works. Future directions we have planned with this product is deeper integration with GnuCash at the database level, integration with GnoTime, and integration with Issue Tracker. You can e-mail me directly, but for the benefit of the Open Source community you should also post comments, criticisms or suggestions posted to this discussion list. Thank you. Richard Schilling ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PostgreSQL not ACID compliant?
Zak Greant wrote: Thanks for the Cc: and for noticing the fixes! To be fair, Paul DuBois and Andrey Stroganov did the actual work - I only did some pointing and grunting. I am not sure that we have removed everything yet - I still need to do a full sweep of the docs. In any case, this is a good start Also, I noticed the long GPL/MySQL related thread on [GENERAL]. It looked like there are some good points in the discussion. Once I get some other licensing-related issues taken care up, I will take a look at cleaning up the licensing overview docs that were mentioned and critiqued. Thanks again. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Error message cleanup
Alvaro Herrera [EMAIL PROTECTED] writes: Are you going to change relation to table? In most cases that is the intended meaning. ISTM in some other cases it refers to anything that can appear in pg_class, but I'm not 100% sure. Quite a lot of the code considers relation to mean anything that has a pg_class entry, which is a definition that's gotten fuzzier and fuzzier as we've thrown more stuff into pg_class. (Standalone composite types, for example, hardly qualify as a relation by anyone's understanding of the term. But they have pg_class entries now.) I don't mind rewording error messages to say table when in fact they could only be referring to plain tables. But let's not just move the fuzziness over from relation to table. 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])
