Re: [HACKERS] module archive
On 10/25/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > From time to time people have raised the idea of a CPAN-like mechanism > for downloading, building and installing extensions and the like (types, > functions, sample dbs, anything not requiring Postgres itself to be > rebuilt), and I have been thinking on this for the last few days. What > sort of requirements would people have of such a mechanism? How do > people envision it working? >From a user's point of view, it would work like this : $ pgsql-pkg list Installed packages : -- pgpool-II v.1.2.1 plR v.8.2.0.5 $ cd /usr/src/pgsql-packages/ $ cvs update $ cd languages/plR $ make upgrade $ cd ../../compatibility/orafce $ make install $ pgsql-pkg list Installed packages : -- pgpool-II v.1.2.1 plR v.8.2.0.7 orafce v.2.1.2 A starting point worth considering could be pkgsrc , the packaging system used by NetBSD ( http://www.netbsd.org/docs/software/packages.html ) . Pkgsrc is not limited to NetBSD : it works on other OS'es as well (Linux, *BSD, Solaris, HP-UX, ... ) . The pkgsrc is based on a directory tree organized in categories. For each package there is a directory that contains the Makefile, the description, and sometimes patches . The user can do : make build , make install , make upgrade , etc. The sources are downloaded from the server where the project is originally hosted : NetBSD is not duplicating the source archives on their server. If necessary, the build system can apply patches before compiling the package. This allows the NetBSD folks to adapt the package without requiring modifications to the original sources So, the mechanism for PostgreSQL extensions could work this way : (A) The source tree would be an adapted version of pkgsrc : - the extensions are organized into directories (based on categories) - each extension would be a directory that basically contains a Makefile that contains enough information for downloading the source tarball, optionally apply patches, and install the package(extension). - probably it will be necessary to create a separate source tree for each PostgreSQL version , so that the build system wouldn't be cluttered with keeping information about which package version is compatible with which PostgreSQL version. - with such a system it is possible to include an extension even if the maintainer of that particular project doesn't modify anything for making it compatible with the extensions system . (B) Some extensions are only sql scripts that install new objects into a database, while others could also contain binaries, libraries, or maybe other stuff as well. Therefore, the installation probably has to be two-step : step 1 : 'make install' would copy the files in a new subdirectory called "extensions" : /usr/local/pgsql/extensions/bin /usr/local/pgsql/extensions/lib /usr/local/pgsql/extensions/install_scripts /usr/local/pgsql/extensions/remove_scripts /usr/local/pgsql/extensions/examples and add the extension to the list of 'installed extensions'. step 2 : for activating the extension inside a particular database the user would execute the extension's install_script. The first step is installing the extension at the database cluster level , while the second step is installing the extension inside a particular database. I think that this distinction is an important one : the user will need full control in installing the extensions only in the databases where she/he wants to. (C) It would be nice to have a table containing information about the extensions currently installed . Cheers, Adrian Maier ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] IDE
On 10/1/07, Michael Glaesemann <[EMAIL PROTECTED]> wrote: > > > Hello Pedro, > > > > You are probably looking for a tool like pgAdmin (http:// > > www.pgadmin.org) or > > PhpPgAdmin (http://phppgadmin.sourceforge.net). There are also some > > commercial applications : http://www.postgresql.org/download/ > > commercial > > > > However, please take notice that your question is not suited for the > > pgsql-hackers mailing list : this list is for discussions about > > developing > > PostgreSQL itself. > > That may be what he means. Unfortunately "develop PostgreSQL" can be > taken both ways. > > In case he's working on internals, I believe Emacs is used by a > number of PostgreSQL hackers. And as for developing PostgreSQL-backed > applications, I find $EDITOR + psql to work quite well. Oh, you are right Michael. I've missed the second interpretation of Pedro's words. My apologises if I got it wrong ... -- Adrian Maier ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IDE
On 10/1/07, Pedro Belmino <[EMAIL PROTECTED]> wrote: > Hello, > I am having problems of productivity with IDE that I am using. Exists some > IDE that recommended to develop postgresql? Hello Pedro, You are probably looking for a tool like pgAdmin (http://www.pgadmin.org) or PhpPgAdmin (http://phppgadmin.sourceforge.net). There are also some commercial applications : http://www.postgresql.org/download/commercial However, please take notice that your question is not suited for the pgsql-hackers mailing list : this list is for discussions about developing PostgreSQL itself. Cheers, Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Compilation of pg 7.4.17 fails on HP-UX
On 8/10/07, Decibel! <[EMAIL PROTECTED]> wrote: > On Fri, Aug 10, 2007 at 08:08:55AM +0300, Adrian Maier wrote: > > So it looks like this is simply a known issue that hasn't been backpatched. > > I'll simply use 8.2 . > > Ok, I'll bite... if you can use 8.2, why were you trying with 7.4 > instead? It sounds like you're paying new-car-prices for something > that's 5 years old... The first attempt was with 7.4 because our application is still running on that version in production. An upgrade is something that has to be done, but it will take a little more time to test and do it properly. Right now I am just doing some tests: i happen to have access to this PA-RISC server and was curious to see how is the application behaving if the database is running on such a machine. But there are no chances to use such a server in production, so my tests are purely ... educative . Cheers, Adrian Maier ---(end of broadcast)--- TIP 1: 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] Compilation of pg 7.4.17 fails on HP-UX
On 8/10/07, Tom Lane <[EMAIL PROTECTED]> wrote: > Decibel! <[EMAIL PROTECTED]> writes: > > On Thu, Aug 09, 2007 at 11:46:47AM -0400, Tom Lane wrote: > >> "Adrian Maier" <[EMAIL PROTECTED]> writes: > >>> I have just tried to compile postgresql 7.4.17 on a HP-UX 11.11 box > >>> (PA-RISC) and the compliation fails in gist. > >> > >> I do not think anyone cares about making 7.4.x run on platforms it did > >> not support before. Use a newer PG release. > > > Actually, this is PA-RISC, not the numerous emails we've gotten this > > week about HPUX on ia64 (what is it with the HPUX guys this week?) > > Oh, my mistake --- obviously hadn't consumed enough caffeine this > morning. > > [ digs around a bit... ] However, I might have been right for the > wrong reasons. I'm thinking Adrian is trying to build for 64-bit > HPPA (a beast the 7.4 supported-platforms matrix doesn't know about), > and is falling foul of this problem: > http://archives.postgresql.org/pgsql-hackers/2004-03/msg01196.php > Teodor fixed that in the 8.0 devel cycle, but couldn't back-patch it > because it meant an on-disk layout change of gist indexes. > > What I suspect is that gcc 3.3.3 doesn't have the specific error checks > I complained of in the above message, but simply generates bogus > assembly code for the incorrect C code :-( So it looks like this is simply a known issue that hasn't been backpatched. I'll simply use 8.2 . Thanks for your answers, Adrian Maier ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Compilation of pg 7.4.17 fails on HP-UX
Hello, I have just tried to compile postgresql 7.4.17 on a HP-UX 11.11 box (PA-RISC) and the compliation fails in gist. make[4]: Entering directory `/home/adrian/postgresql-7.4.17/src/backend/access/gist' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -c -o gist.o gist.c /var/tmp//ccxYASP0.s: Assembler messages: /var/tmp//ccxYASP0.s:1528: Error: Field not properly aligned [8] (52). /var/tmp//ccxYASP0.s:1528: Error: Invalid operands /var/tmp//ccxYASP0.s:1531: Error: Field not properly aligned [8] (44). /var/tmp//ccxYASP0.s:1531: Error: Invalid operands /var/tmp//ccxYASP0.s:1534: Error: Field not properly aligned [8] (60). /var/tmp//ccxYASP0.s:1534: Error: Invalid operands make[4]: *** [gist.o] Error 1 make[4]: Leaving directory `/home/adrian/postgresql-7.4.17/src/backend/access/gist' make[3]: *** [gist-recursive] Error 2 make[3]: Leaving directory `/home/adrian/postgresql-7.4.17/src/backend/access' make[2]: *** [access-recursive] Error 2 make[2]: Leaving directory `/home/adrian/postgresql-7.4.17/src/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/adrian/postgresql-7.4.17/src' make: *** [all] Error 2 This doesn't happen in HEAD. $ uname -a HP-UX hpdev B.11.11 U 9000/800 822196241 unlimited-user license $ gcc --version gcc (GCC) 3.3.3 Cheers, Adrian Maier ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
> The other platform I've whined about missing for some time is HP-UX, > especially on PA-RISC. But that's a whole different story. there are more obscure and rare platforms(both in terms that might be a win for the buildfarm but HP-UX is really missing. Hello, I have access to a PA-RISC machine running HP-UX 11.11. Unfortunately the machine is on a dedicated network and has no Internet access. It should be possible to create a mirror of the CVS repository on my machine (which has access to both the Internet and the dedicated network) so that the HP-UX server could get the sources from my machine. But I am not sure whether the results could be reported back to the buildfarm. Cheers, Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Statements with syntax errors are not logged
On 10/19/06, Tom Lane <[EMAIL PROTECTED]> wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: > When setting log_statement = 'all', statements that fail parsing are not > logged. > Is that intentional? The 'mod' and 'ddl' settings obviously can't be handled until after basic parsing. We could create a completely separate code path for 'all' but I'm not sure I see the point. Hello, Sometimes it can be very useful to be able to see even the incorrect commands: for example when the incorrect query is generated by an application or library that you haven't written yourself . A few days ago I was experimenting with Lazarus (an object-pascal based IDE similar to Delphi) and I was getting some unexpected syntax errors. In order to debug the problem i had to hack the sources of the postgres unit and add some writeln's right before the PQexec calls . It would have been much more convenient to see the bad queries in the logs ... -- Adrian Maier ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Buildfarm failure at "initdb" - member Cassowary
Hello, The Cassowary buildfarm memeber is curently failing when performing initdb . The corresponding log file initdb.log is empty. When running initdb manually, it dies immediately "with code 0200". Other executables (psql, createlang, createdb for example) fail in the same manner. But some others (postgres,postmaster,ecpg) seem to be ok ... My assuption is that I haven't configured "something" properly in Cygwin : it's a fresh install after having switched to a new machine. Unfortunately, without an error message, it's hard to identify the problem. The FAQ_CYGWIN suggests that modifying the cygserver config may be neccessary, but it doesn't provide more details. Does anyone have any advice ? Cheers, Adrian Maier $ gdb bin/initdb.exe (gdb) break main Breakpoint 1 at 0x403200: file initdb.c, line 2358. (gdb) run Starting program: /home/am/build/HEAD/inst/bin/initdb.exe gdb: unknown target exception 0xc022 at 0x77f966bc Program received signal ?, Unknown signal. Program exited with code 0200. ---(end of broadcast)--- TIP 1: 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] Cassowary failing to report the results back to the farm
On 9/11/06, Jeremy Drake <[EMAIL PROTECTED]> wrote: On Mon, 11 Sep 2006, Adrian Maier wrote: > It's not clear to me where does that date-in-the-future come from. > The machine's > date is set correctly: > $ date > Mon Sep 11 11:00:30 PST 2006 Um, no. I am currently in the PST time zone, and I can say from first-hand experience that the current time is 2:21 am, not 11 am. I have confirmed this by looking out the window and noticing a distinct lack of light. The time you have quoted is about 8.5 hours in the future. Suggest you either verify your time zone, or look out your window ;) Thanks Jeremy, You are right, I hadn't realised that 'PST' indicates a timezone (the wrong one..). I'll have to change the timezone to GMT+2 . Sorry for the noise ! -- Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Cassowary failing to report the results back to the farm
Hello, I'm trying to put the cassowary buildfarm member back to work (it's been inactive for almost a month because i've moved to another project and switched the machine). The run_build script has trouble with sending the test results. The error is : Status Line: 491 bad ts parameter - 1157995969 (Mon Sep 11 17:32:49 2006 GMT) is in the future. Content: bad ts parameter - 1157995969 (Mon Sep 11 17:32:49 2006 GMT) is in the future Web txn failed with status: 1 It's not clear to me where does that date-in-the-future come from. The machine's date is set correctly: $ date Mon Sep 11 11:00:30 PST 2006 Any ideas about what might cause this? -- Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.2 features status
On 04/08/06, Andreas Pflug <[EMAIL PROTECTED]> wrote: Bruce Momjian wrote: > > Right, hence "usability", not "new enterprise features". > I'm not too happy about the label "usability". "Ok, maybe postgres gets usable finally by supporting features that MySQL had for a long time" a MySql guy would say. I have the same feeling about the term "usability". It could be interpreted like : PostgreSQL was not usable until now. Best wishes, Adrian Maier ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] float8 regression failure (HEAD, cygwin)
On 01/08/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> Would this do the trick? > > I think Bruce changed the call convention for run_diff ... are you > looking at CVS tip? Otherwise it looks reasonable. You're right. I had forgotten to do a cvs update. Fixed and committed. The cassowary farm member went green, for the first time in history :) Thanks guys, Adrian Maier ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] float8 regression failure (HEAD, cygwin)
On 01/08/06, Tom Lane <[EMAIL PROTECTED]> wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: > Maybe we need to abandon trying to map float8 results exactly in the > resultmap file, and just let pg_regress pick the best fit as we do with > some other tests. I thought about that too but it seems a very bad idea. small-is-zero is distinctly "less correct" than the regular output, and I don't think we want pg_regress to be blindly accepting it as OK on any platform. Perhaps we could stick a version check into the resultmap lookup? It'd likely have been painful on the shell script implementation but now that the code is in C I think we have lots of flexibility. There's no need to feel bound by the historical resultmap format. However this is all premature unless we can verify that "cgywin's strtod() complains about float underflow after version so-and-so". Do they publish a detailed change log? There are links to the last few releases on their home page http://www.cygwin.com , in the News section. -- Adrian Maier ---(end of broadcast)--- TIP 1: 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] float8 regression failure (HEAD, cygwin)
On 01/08/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: Adrian Maier wrote: > On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote: > Apparently the regression test is comparing the results/float8.out > with expected/float8-small-is-zero.out because of the following line > in > src/test/regress/resultmap : > float8/i.86-pc-cygwin=float8-small-is-zero > > I've changed that line to : >float8/i.86-pc-cygwin=float8 > and the regression test ended successfully : "All 100 tests passed." > > I don't know why there are several expected results for the float8 test, > depending on the platform. Is the modification ok? > > I've attached the patch, and cc'ed to pgsql-patches. The problem with this is that we have another Cygwin member on buildfarm which passes the tests happily, and will thus presumably fail if we make this patch. You are running Cygwin 1.5.21 and the other buildfarm member is running 1.5.19, so that is possibly the difference. This is indeed a problem. It would be difficult or even impossible to use different expected results for different versions of cygwin. Maybe we need to abandon trying to map float8 results exactly in the resultmap file, and just let pg_regress pick the best fit as we do with some other tests. Oh, is it possible to do that? That sounds great. Which other tests work like that? Cheers, Adrian Maier ---(end of broadcast)--- TIP 1: 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] float8 regression failure (HEAD, cygwin)
On 20/07/06, Tom Lane <[EMAIL PROTECTED]> wrote: Reini Urban <[EMAIL PROTECTED]> writes: > BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also. You sure? INT64_IS_BUSTED should *not* be set in that case --- it's only supposed to be set if we couldn't find any 64-bit-int type at all. As for the regression test failure, it's odd because it looks to me that the actual test output is an exact match to the default "float8.out" file. I'm not sure why pg_regress chose to report a diff against float8-small-is-zero.out instead. This may be another teething pain of the new pg_regress-in-C code --- could you trace through it and see what's happening? Apparently the regression test is comparing the results/float8.out with expected/float8-small-is-zero.out because of the following line in src/test/regress/resultmap : float8/i.86-pc-cygwin=float8-small-is-zero I've changed that line to : float8/i.86-pc-cygwin=float8 and the regression test ended successfully : "All 100 tests passed." I don't know why there are several expected results for the float8 test, depending on the platform. Is the modification ok? I've attached the patch, and cc'ed to pgsql-patches. Cheers, Adrian Maier patch_float8.diff Description: Binary data ---(end of broadcast)--- TIP 1: 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] float8 regression failure (HEAD, cygwin)
On 20/07/06, Reini Urban <[EMAIL PROTECTED]> wrote: Thanks, Which postgresql version? The version is cvs HEAD. Can we have a regular cygwin error report please mailed to cygwin at cygwin.com please. See http://cygwin.com/problems.html (cygcheck -s -v -r > cygcheck.out) Looks like a strtod() newlib feature, but I haven't inspected closely. http://sources.redhat.com/ml/newlib/2006/msg00020.html BTW: HAVE_LONG_LONG_INT_64 is defined, so INT64_IS_BUSTED is defined also. Does it look the same on redhat fedora? Our buildfarm doesn't have these issues, this runs gcc-3.3.3 and gcc-3.4.4 I'm not sure about fedora, but on NetBSD 3.0rc5 , postgresql 8.1.3 I can see the same behaviour: am=# select version(); version PostgreSQL 8.1.3 on i386--netbsdelf, compiled by GCC gcc (GCC) 3.3.3 (NetBSD nb3 20040520) (1 row) am=# SELECT '-10e400'::float8; ERROR: "-10e400" is out of range for type double precision The problem I see is that float8in() in src/backend/utils/adt/float.c checks only for "-Infinity" and not "-inf" as returned by newlib: pg_strncasecmp(num, "-Infinity", 9) == 0 Can you test this? Sure . $ gcc test-strtod.c; ./a double: -inf, errno: 34, tail: '', isinf: 1, fabs: inf, inf>max: 1 Yes, I'm getting the same output (both on cygwin and netbsd 3.0rc5): $ ./test-strtod.exe double: -inf, errno: 34, tail: '', isinf: 1, fabs: inf,inf>max: 1 Cheers, Adrian Maier ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] float8 regression failure (HEAD, cygwin)
Hello,
While setting up a buildfarm installation for cygwin, I've
uncountered the following
regression failure :
float8 ... FAILED
== pgsql.3132/src/test/regress/regression.diffs
*** ./expected/float8-small-is-zero.out Tue Jul 18 09:24:52 2006
--- ./results/float8.outTue Jul 18 09:53:42 2006
***
*** 13,29
SELECT '-10e400'::float8;
ERROR: "-10e400" is out of range for type double precision
SELECT '10e-400'::float8;
! float8
!
! 0
! (1 row)
!
SELECT '-10e-400'::float8;
! float8
!
! -0
! (1 row)
!
-- bad input
INSERT INTO FLOAT8_TBL(f1) VALUES ('');
ERROR: invalid input syntax for type double precision: ""
--- 13,21
SELECT '-10e400'::float8;
ERROR: "-10e400" is out of range for type double precision
SELECT '10e-400'::float8;
! ERROR: "10e-400" is out of range for type double precision
SELECT '-10e-400'::float8;
! ERROR: "-10e-400" is out of range for type double precision
-- bad input
INSERT INTO FLOAT8_TBL(f1) VALUES ('');
ERROR: invalid input syntax for type double precision: ""
***
*** 377,383
--- 369,377
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
ERROR: "-10e400" is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR: "10e-400" is out of range for type double precision
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR: "-10e-400" is out of range for type double precision
-- maintain external table consistency across platforms
-- delete all values and reinsert well-behaved ones
DELETE FROM FLOAT8_TBL;
=
This happening on cygwin 1.5.20 (running on top of winXP), gcc 3.4.4.
The entire check.log can be found here :
http://www.newsoftcontrol.ro/~am/pgfarm/check.log
The other logs generated by the buildfarm can be found here:
http://www.newsoftcontrol.ro/~am/pgfarm/
Cheers,
Adrian Maier
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: Anyone still care about Cygwin? (was Re: [HACKERS] [CORE] GPL
On 23/06/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote: Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > >> There are several supported platforms not represented on the buildfarm - >> e.g. the one HPUX member has never actually reported any results. > > Yeah, and this is not a good thing. Eventually I'd like to get to a > point where every platform we consider "supported" has regular buildfarm > reports. No more calls for port reports during beta periods --- beta > work should focus on functionality testing, not getting it to build. > Then people who have access to people who own or can provide access to machines in classes not covered need to do a bit of begging ;-) The requirements are (deliberately) very modest: Once it is set up it is close to hands free - you just set up the cron job(s) or equivalent. Hello, I'll try to set up a buildfarm installation for Cygwin on my computer at work. But I'm taking the next week off, so this will have to wait until my return. Cheers, Adrian Maier ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] concurrent transactions inside the same connection
Hello hackers, I have included below a fragment of a discussion from the freepascal mailing list. Apparently, some folks expect to be able to start multiple transactions inside the *same* database connection. Since this is not possible in postgres, they would be forced to start more connections from the same application. Is such a feature possible to be implemented someday ? My feeling is that this is a false problem, caused by some interbase/firebird or delphi habits . But ... the poster claims that Oracle and SqlServer have such a feature ( Oracle has 'named' transactions - but these names seem to be just labels ) - is this true ? Best wishes, Adrian Maier -- Forwarded message -- From: Michael Van Canneyt <[EMAIL PROTECTED]> Subject: Re: [lazarus] FPC question To: lazarus@miraclec.com On Wed, 19 Apr 2006, Adrian Maier wrote: > On 4/19/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote: >>> Is this a problem with PostgreSQL itself or the component in lazarus >>> wrapping it? >> >> It's a problem of postgres. A transaction 'block' is started with the >> sql-command 'begin', from that comand on, all queries are executed >> within that transaction. Using another connection is not possible. >> Unless, offcourse, you start a new connection. Or closes the transaction >> (commit, rollback etc) > > Please pardon me for jumping in the middle of the thread, but your > phrase made me really curious. The behaviour you described seems > to be the normal one, once you execute "begin" (transaction) . What > other behaviour would someone expect postgres to have ? To allow several concurrent transactions. Interbase/Firebird allows to start several concurrent transactions in 1 connection. AFAIK Oracle and MS-SQL too (named transactions). This is extremely handy. Michael. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Strange results from to_timestamp
On 4/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Mario Weilguni <[EMAIL PROTECTED]> writes:
> > I think all except the first one should raise a warning, isn't it?
>
> to_timestamp (and friends) all seem to me to act pretty bizarre when
> faced with input that doesn't match the given format string. However,
> in the end that is an Oracle-compatibility function, and there is only
> one measure of what it should do: what does Oracle do in the same case.
> Can anyone try these examples on a recent Oracle version?
In Oracle10g Express those dates are rejected as invalid :
SQL> select to_timestamp(' 0300','mmdd hh24mi') from dual;
select to_timestamp(' 0300','mmdd hh24mi') from dual
*
ERROR at line 1:
ORA-01843: not a valid month
SQL> select to_timestamp(' 0300','mmdd hh24mi') from dual;
select to_timestamp(' 0300','mmdd hh24mi') from dual
*
ERROR at line 1:
ORA-01843: not a valid month
Cheers,
Adrian Maier
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Please help, pgAdmin3 on Debian!
On 3/28/06, lmyho <[EMAIL PROTECTED]> wrote: > Dear All, > > Which is good. But I've got big trouble to login to this initial db by > using this auto-created username "postgres" through pgAdmin:((( The first > try failed due to "Ident authentication failed", so I follow the suggestion > on the pop-up window of pgAdmin3, and changed the ident method in the > pg_hba.conf file all to md5 to try again, but the database now ask me for > the password!! which I couldn't figure out the passwd so I tried to created > rules in the pg_ident.conf file to map both the ordinary user and root user > od Debian system to postgres, and tried again. But still failed,:((( > "ident authentication failed"again!!!:((( I've tried many times for all I > could think and failed everytime failed:((( By the way each time before I > try, I did "pg_ctl reload", and I could see the failure reason changed after > I do reload. > > I've sent mail to other list but no anwser back. I believe people in this > group must know what's the reason and solution. So would you please help > me? So if there is auto-created password for this auto-created postgres > user, please anyone tell me what it is?? You could try to change the ident method to trust (in pg_hba.conf). This should allow you to login. Then, set the password of the postgres user (alter user postgres with password 'blabla1212' ; ). Then you could change the ident method back to md5 . Adrian Maier ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] How to put back??
On 3/22/06, Dhanaraj M - Sun Microsystems <[EMAIL PROTECTED]> wrote: > Hi all, > > I have recented joined and working on postgres. I fixed a bug that I > saw in the mailing list. I ran the regression test that is available in > postgres. It was successful and now I need the following details.. > > 1) Test suits that i could get to test my code.. > 2) How can I put back my fix into postgres src code.. (or) What is the > procedure that I should follow at this stage?? You might find the following document useful: http://www.postgresql.org/docs/faqs.FAQ_DEV.html Cheers, Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] compiling on windows with mingw
Gevik babakhani wrote: I would like to compile the code on windows. I understand I need mingw. on the mingw site there are may packages to download and install. Does anyone know which ones to download install in order to compile pg. Hi Gevik, When I last installed mingw I've downloaded only 2 files (bundles) MinGW-?.?.?.exe and MSYS-?.?.?.exe. Adrian Maier Thanx, Gevik. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Call for port reports
Hi, PostgreSql 8.1 RC1 ( --with-perl --with-python) passed all tests on Slackware Linux 10.2 (kernel 2.4.31, x86) Regards, Adrian Maier ---(end of broadcast)--- TIP 1: 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] when started century? PostgreSQL vs Oracle diff
Pavel Stehule wrote: Hello I am testing comformity between PostgreSQL and Oracle. I found one difference. Century started 1900-01-01 for Oracle and 1901-01-01 for PostgreSQL. What value is good? Hello, I think that 1901 is the correct year. ( The first century started in year 1 and ended in year 100. There was no year 0 ... Also, the 2nd millenium started in 2001, not in 2000 : http://staff-www.uni-marburg.de/~schittek/millenni.htm ) Best wishes, Adrian Maier Best regards Pavel Stehule _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Simplifying wal_sync_method
On 8/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Personally, my only complaint regarding either choice is the > assumption that a 'WIN32' guy is stupid, and that 'WIN32' itself is > deficient. As long as the default is well documented, I don't have a > problem with either 'faster but less reliable on systems configured > for speed over reliability at the operating system level (write > caching enabled)' or 'slower, but reliable, just in case the system is > configured for speed over reliability at the operating system level > (write caching enabled)'. As long as it is well documented, either is > fine. I'm not convinced that Linux is really that much safer anyways, > and when it comes to a standard WIN32 configuration option, I assume > that the WIN32 administrator is somewhat competent. Hello guys, There seem to be arguments for both possible default configurations "faster but less reliable" and "slower but reliable". I personally think that the safer configuration is better. Anyway, i have an idea : What do you think about letting the person who installs PostgreSQL on Win32 decide? For Windows, we have the graphical installer that can be improved so that the user is asked to choose between the two possible configurations. This way the user will be aware of this choice even if he/she does not read the docs. If we let this choice be made at installation time, it would be less important which is the default value because i think that the users who install PostgreSQL from sources on Win32 are fewer. And we can expect that, after bothering to install mingw and compile PostgreSQL, they will also bother to configure it according to their needs. Cheers, Adrian Maier ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Oracle Style packages on postgres
-- Forwarded message -- From: Adrian Maier <[EMAIL PROTECTED]> Date: May 10, 2005 12:01 PM Subject: Re: [HACKERS] Oracle Style packages on postgres To: "Jim C. Nasby" <[EMAIL PROTECTED]> On 5/9/05, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > On Sun, May 08, 2005 at 10:38:41PM -0500, Bob wrote: > > One simple benefit to packages is just organization of related code. > > Which, IMHO, is greatly diminished by the lack of > schema.package.function notation. BTW, the original post referred to > this as user.package.function, but I believe that technically it's > actually schema.package.function (Oracle tends to mix schemas and > users). In any case, schema.package.function is what would make sense in > PostgreSQL. > > Personally, I think the biggest win here would be adding package support > and syntax to plpgsql. Not only would it make porting from Oracle > easier, it would also make plpgsql much, much more powerful. Hello, What do you think about having some kind of language-independent packages ? I'm thinking that it could be handy to implement some functions in plpgsql, some functions in plpython and so . And then bundle them together into the same package. Cheers, Adrian Maier ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [pgsql-advocacy] [HACKERS] Increased company involvement
On 5/6/05, Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > Actually, if the number of "split files" (whatever their names) > > > > >>postgresql-WTKS.tar.gz (with the kitchen sink) file > > that contained > > >> everything for those that really wanted to download "it all" ... > > > > > > That would be "postgresql-x.y.z.tar.gz", right? ;-) > > > > Nope, postgresql-x.y.z.tar.gz will just be the core > > distribution ...the WTKS will be the 'with the kitchen sink' > > meta distribution and would be in the subdir that you propose > > above ... in fact, I doubt that the WTKS will even be ready > > for the next release, as it will involve alot of work on the > > build system itself, I would think ... the 'cascading > > configure's could be interesting in itself ... > > Please. *Nobody* will know what postgresql-wkts-x.y.z.tar.gz is. It's > hard enough to understand the splits as they are now (what really is in > -opt for example? I know it's in the readme, but users don't read that), > and this will certainly not make it easier. Hello, If I understood correctly, this 'wtks' distribution will contain what is now in the postgresql-?.?.?.tar.gz , plus other additional things like additional PLs ( which now have to be downloaded and compiled separately ) ?Seems to be a great idea , but i agree that the contents of the postgresql-?.?.?.tar.gz tarballs should not be reduced ! Once this 'wtks' will be available, I bet that most people who are aware of its existance will prefer to download it because it would be much more convenient.The name of the package will need to be carefully chosen, though. "wtks" does not seem to be a good choice ( native English speakers surely know what is a 'kitchen sink', but I really don't understand what it means) . Just wondering: would it be feasible to expand the existing contrib directory to a system similar to the BSD ports collection ? One would type: cd postgresql-8.1.0/contrib/pls/pljava make install ( which would download the pljava sources from pgfoundry, build it and install ) With such a system in place, various modules could be installed in a unique manner no matter where they are hosted. And they would gain visibility ... Best wishes, Adrian Maier > > > Bottom line - make it easy for the *newbies*. Those of us who know > > > exactly what we want will know where to look for it (say in > > a separate > > > subdir). (or we'll just download the whole tarball anyway > > because that > > > is *way* much more convenient... Speaking for myself there, of > > > course.) > > > > Note that "the whole tar ball" will give you the core server > > and that is it ... the WTKS is a whole seperate project from > > what is being planned ... > > > > What is being worked on right now is effectively reducing > > things down to: > > > > postgresql-server (including libpq) > > postgresql- > > Um. So instead of as I do today: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-8.0.2.tar.bz2 > tar xjf postgresql-8.0.2.tar.bz2 > ./configure --with-perl --with-python --with-tcl > gmake && gmake install > > I'll now have to do: > wget > http://ftp.sunet.se/pub/databases/relational/postgresql/source/v8.0.2/po > stgresql-docs-8.0.2.tar.bz2 > tar xjf postgresql-docs-8.0.2.tar.bz2 > ./configure > gmake && gmake install > > Remind me again how this is actually *better*, and not just making life > a whole lot worse for me? And more specifically, for a new user that > doesn't know which files to download already, and will just grab the > default file. > > Pulling the interfaces out of the main tarball was bad enough, but it > had point - ODBC and JDBC need to work with different versions, and may > be released as different times. Please don't do the same for PLs. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Urgent
On 4/18/05, ElayaRaja S <[EMAIL PROTECTED]> wrote: > Hi, > I am using Redhat Linux 9, I need to uninstall postfesql 7.3.2 and > i have to install postgresql 7.4.5. Plz let me know how to uninstall > completely - postfesql 7.3.2 Hello, You really should consider asking your question on some another mailing list, because it is quite off-topic... Regarding uninstalling: you need to find out the names of the postgresql-related packages that are installed. They might be called something like postgresql-client, postgresql-server, etc. Then, you simply uninstall them with: rpm -e Regards, Adrian Maier ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Help Needed
On Mon, 27 Dec 2004 07:55:27 +0530 (IST), Ameya S. Sakhalkar <[EMAIL PROTECTED]> wrote: > > For my project (main memory DBMS), I have written a main memory filesystem. > Idea is, the primary copy of data will reside in main memory. (Workable > only for small size data, at most 2GB). > > Now, I want to plug this filesystem with Postgres, so that, instead of > Unix filesystem, this main memory filesystem(MMFS) will now store the > data. I believe that all you need to do is to mount your filesystem somewhere, and then tell postgres to use that directory for storing the database files. 1. Mount your filesystem to a directory, e.g /mnt/mem_drive (possibly : mount -t mmfs /dev/mmfs /mnt/mem_drive) 2. export PG_DATA=/mnt/mem_drive 3. initdb 4. pg_ctl start I hope this helps. Adrian Maier > I want to know, how to plug it with Postgres. i.e. whether replacing all > calls to Unix filesystem by calls to MMFS is enough, or do I need to do > something else/more. I am really a newbie to Postgres. So, can someone pls > guide me, abt how should I go. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Romanian translation
On Thu, 4 Nov 2004 11:26:50 +0200, Alin Vaida <[EMAIL PROTECTED]> wrote: > Hello, > I'd like to translate postgres in Romanian, if nobody's doing this already. Hello! I have done some translations of the press releases into Romanian before, and I'll translate the upcoming press release, too. I don't plan to translate the po files, so you are certainly welcome to work on them. If you happen to be unsure about translating some of the phrases and you want someone else's opinion, please do not hesitate to contact me. Cheers, Adrian Maier ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] shared buffer hash table corrupted
Hello, On the production server I have PostgreSql 7.4.3 , on Mandrake Linux 9.2. In the message log on 29 july I have received several "shared buffer hash table corrupted" errors . What could cause this error ? (bad RAM maybe?) Best wishes, Adrian Maier ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Possible Commit Syntax Change for Improved TPS
Seun Osewa wrote: I observed that in in many applications there are some transactions that are more critical than others. I may have the same database instance managing website visitor accounting and financial transactions. I could tolerate the loss of a few transactions whose only job is to tell me a user has clicked a page on my website but would not dare risk this for any of the "real" financials work my web-based app is doing. It is possible to split the data over 2 database clusters: one which contains "important" data (this cluster will be configured with fsync enabled), and a second one that contains the less important data (configured with fsync=off for speed reasons). Cheers, Adrian Maier ([EMAIL PROTECTED]) ---(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
