[HACKERS] pgsql_data/base mapping
Are the numbers of the directories in the base diretory and the numbers of the directories under that, etc. traceable to a reference somewhere in the postgresql server using that data directory (such as the pg_database table or such)? If so, is there somewhere this is documented? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Where's mybus? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] source code indexer
HI all, Sorry to interrupt your busy list. I was wondering if you could recomend a good source code db/indexer that could be used to search through the postgresql code? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(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] source code indexer
Ah. Great! I had download lxr and was starting to dig in to insatall it and thought I would check with the pgers to see what they recommended. Glad to see someone has done this. Thanks, L. On Fri, 30 Aug 2002, Joe Conway wrote: > Laurette Cisneros wrote: > > HI all, > > > > Sorry to interrupt your busy list. > > > > I was wondering if you could recomend a good source code db/indexer that > > could be used to search through the postgresql code? > > I think the real pros use grep and emacs ;-) > > But for us mere mortals, I find LXR very useful. I have set one up for > my own use -- it gets rebuilt from cvs nightly. If you are interested see: > >https://www.joeconway.com/lxr.pgsql/ > > use login name "lxr" and password "pglxr" (without the quotes) > > HTH, > > Joe > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] source code indexer
Thanks to everyone who made suggestions. I have found Source Navigator to be very close and useful for what I was looking for! Thanks again, L. On Fri, 30 Aug 2002, Manfred Koizar wrote: > On Fri, 30 Aug 2002 11:57:17 -0700 (PDT), Laurette Cisneros > <[EMAIL PROTECTED]> wrote: > >I was wondering if you could recomend a good source code db/indexer that > >could be used to search through the postgresql code? > > I use Source Navigator v5.1 http://sourceforge.net/projects/sourcenav/ > > Servus > Manfred > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS]
I am trying move my development database to 7.3b1. However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get the following error: pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp pg_restore: [archiver (db)] could not execute query: ERROR: function plpgsql_call_handler() does not return type language_handler Any ideas? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(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]
Thanks! On 9 Sep 2002, Oliver Elphick wrote: > On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote: > > > > I am trying move my development database to 7.3b1. > > > > However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get > > the following error: > > > > pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp > > > > pg_restore: [archiver (db)] could not execute query: ERROR: function > > plpgsql_call_handler() does not return type language_handler > > > > Any ideas? > > At the moment, you have to edit the dump. Where the language handler > function is declared, change "RETURNS opaque" to "RETURNS > language_handler". > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(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]
Ok, am I missing somethig here? In 7.3, the -Fp option has been removed which leaves the -Fc (which we use in our 7.2 dumps) or -Ft. How does one edit a compressed or tar file? Also, is this problem going to be fixed in a later beta or regular release of 7.3? This could pose a problem to restore full database dumps. Thanks, L. On 9 Sep 2002, Oliver Elphick wrote: > On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote: > > > > I am trying move my development database to 7.3b1. > > > > However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get > > the following error: > > > > pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp > > > > pg_restore: [archiver (db)] could not execute query: ERROR: function > > plpgsql_call_handler() does not return type language_handler > > > > Any ideas? > > At the moment, you have to edit the dump. Where the language handler > function is declared, change "RETURNS opaque" to "RETURNS > language_handler". > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS]
Ok, I made the changes in the compressed pg_dump file. Now pg_restore crashes: pg_restore: [archiver] out of memory *sigh* L. On 9 Sep 2002, Oliver Elphick wrote: > On Mon, 2002-09-09 at 21:34, Laurette Cisneros wrote: > > > > I am trying move my development database to 7.3b1. > > > > However, when I try to restore from a 7.2.2 dump to the 7.3.b1 server I get > > the following error: > > > > pg_restore -U nbadmin -h lnc -p 5432 -d stats -Fc /tmp/stats.pgdmp > > > > pg_restore: [archiver (db)] could not execute query: ERROR: function > > plpgsql_call_handler() does not return type language_handler > > > > Any ideas? > > At the moment, you have to edit the dump. Where the language handler > function is declared, change "RETURNS opaque" to "RETURNS > language_handler". > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS]
I do this to begin with (createdb -T template0 db). FYI: Here's what I've determined is the best thing to do: 1. create the database from template0 2. create the needed languages (plpgsql, plperl, plpython) in the database 3. create the needed tables, functions, types, etc. from script files. 4. restore only the data from the dump. Seems to be the "easiest" and safest way to convert the database(s) to 7.3b1 (we have a mirad of databases for different needs each having their own set of types, functions and languages that they use). I'll let you know if I run into problems with this - as this, in my opinion, should not! Thanks to all for the help, L. On Tue, 10 Sep 2002, Bruce Momjian wrote: > > I am confused. This wording seems fine to me. > > --- > > Oliver Elphick wrote: > > On Tue, 2002-09-10 at 00:50, Philip Warner wrote: > > > > > ALTERNATIVELY, define the language in template1, then just edit dump1.lis > > > to remove the line for the language definition, and run pg_restore -L > > > dump1.lis. > > > > That doesn't work for a dump and reload, because 7.3's pg_dumpall writes > > a script to create the databases from template0 rather than template1. > > > > The 7.3 documentation for pg_dump says: > > > > Notes > > > > If your installation has any local additions to the template1 > > database, be careful to restore the output of pg_dump into a truly > > empty database; otherwise you are likely to get errors due to > > duplicate definitions of the added objects. To make an empty > > database without any local additions, copy from template0 not > > template1, for example: > > > > CREATE DATABASE foo WITH TEMPLATE = template0; > > > > but this seems to be out of date. pg_dumpall actually uses template0 > > itself. > > > > -- > > Oliver Elphick[EMAIL PROTECTED] > > Isle of Wight, UK > > http://www.lfix.co.uk/oliver > > GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C > > > > "Draw near to God and he will draw near to you. > > Cleanse your hands, you sinners; and purify your > > hearts, you double minded." James 4:8 > > > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] timestamp column default changed?
If you define a column as: coltimestamp In 7.2.x didn't it default to timestamp with timezone? And now in 7.3(b1) it defaults to timestamp without timezone? Is this right? -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] timestamp column default changed?
I'm sure you all have discussed this ad-nauseum but this sure does create a pain in the butt when converting. Ok, I had my say. Thanks for all your hard work, L. On Wed, 11 Sep 2002, Bruce Momjian wrote: > Laurette Cisneros wrote: > > > > If you define a column as: > > coltimestamp > > In 7.2.x didn't it default to timestamp with timezone? > > > > And now in 7.3(b1) it defaults to timestamp without timezone? > > /HISTORY says right at the top: > > * TIMESTAMP and TIME data types now default to WITHOUT TIMEZONE > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] timestamp column default changed?
I understand. Thanks for pointing that out. L. On Wed, 11 Sep 2002, Bruce Momjian wrote: > > I think the SQL standards required the change. > > --- > > Laurette Cisneros wrote: > > I'm sure you all have discussed this ad-nauseum but this sure does create a > > pain in the butt when converting. > > > > Ok, I had my say. > > > > Thanks for all your hard work, > > > > L. > > On Wed, 11 Sep 2002, Bruce Momjian wrote: > > > > > Laurette Cisneros wrote: > > > > > > > > If you define a column as: > > > > coltimestamp > > > > In 7.2.x didn't it default to timestamp with timezone? > > > > > > > > And now in 7.3(b1) it defaults to timestamp without timezone? > > > > > > /HISTORY says right at the top: > > > > > > * TIMESTAMP and TIME data types now default to WITHOUT TIMEZONE > > > > > > > > > > -- > > Laurette Cisneros > > The Database Group > > (510) 420-3137 > > NextBus Information Systems, Inc. > > www.nextbus.com > > -- > > A wiki we will go... > > > > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- A wiki we will go... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] pg7.3b1
I am so glad that postgres now keeps track of relationships between rule, views, functions, tables, etc. I've had to re-do all my creation and drop scripts but this is definitely for the better. During my testing of my scripts, I have come across this message: psql:/u1/cvs73/DataBase/Config/Schema/logconfig.sql:142: WARNING: Relcache reference leak: relation "positions" has refcnt 1 instead of 0 What does this indicate? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com --- NextBus say: Riders prefer to arrive just minute before bus than just minute after. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg7.3b1
I'll see if I can pare down my scripts (they are long) to reproduce this easier. L. On 26 Sep 2002, Rod Taylor wrote: > On Thu, 2002-09-26 at 16:46, Laurette Cisneros wrote: > > > > I am so glad that postgres now keeps track of relationships between rule, > > views, functions, tables, etc. I've had to re-do all my creation and drop > > scripts but this is definitely for the better. > > > > During my testing of my scripts, I have come across this message: > > psql:/u1/cvs73/DataBase/Config/Schema/logconfig.sql:142: WARNING: Relcache >reference leak: relation "positions" has refcnt 1 instead of 0 > > > > What does this indicate? > > Someone (probably me) made a mistake and forgot to release a cache > handle. > > Do you happen to have a sequence of commands that can reproduce this? > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com --- NextBus say: Riders prefer to arrive just minute before bus than just minute after. ---(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] pg7.3b1
Ok, finally had time to narrow this down. Here's the simplified script that will reproduce this (this sequence reroduces on my system using 7.3b2): \echo BEGIN tst.sql create table pp ( x integer , i text ); create view p as select * from pp where i is null; comment on view p is 'This is a comment.'; create rule p_ins as on insert to p do instead insert into pp values ( new.x , null ); comment on rule p_ins is 'insert to p goes to pp'; \echo END tst.sql On 26 Sep 2002, Rod Taylor wrote: > On Thu, 2002-09-26 at 16:46, Laurette Cisneros wrote: > > > > I am so glad that postgres now keeps track of relationships between rule, > > views, functions, tables, etc. I've had to re-do all my creation and drop > > scripts but this is definitely for the better. > > > > During my testing of my scripts, I have come across this message: > > psql:/u1/cvs73/DataBase/Config/Schema/logconfig.sql:142: WARNING: Relcache >reference leak: relation "positions" has refcnt 1 instead of 0 > > > > What does this indicate? > > Someone (probably me) made a mistake and forgot to release a cache > handle. > > Do you happen to have a sequence of commands that can reproduce this? > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- Do you know where your bus is? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pgsql 7.2.3 crash
A lot of different things going on but my perl program (whose backend crashed) was doing a lot of insert into table as select * from another table for a lot of different tables. I see triggers referenced here and it should be noted that for one of the tables the triggers were first disabled (update pg_class) and re-enabled after the inserts are done (or it takes forever). The pgsql log shows: ... 2002-10-08 15:48:38 [18033] DEBUG: recycled transaction log file 005200B1 2002-10-08 15:49:24 [28612] DEBUG: server process (pid 16003) was terminated by signal 11 2002-10-08 15:49:24 [28612] DEBUG: terminating any other active server processes 2002-10-08 18:49:24 [28616] NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. ... A core file was found in /base/326602604 and a backtrace shows: (gdb) bt #0 DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0, newtup=0x8348150) at trigger.c:2056 #1 0x080b9d0c in ExecARInsertTriggers (estate=0x8333778, relinfo=0x83335f0, trigtuple=0x8348150) at trigger.c:952 #2 0x080c0f23 in ExecAppend (slot=0x8333660, tupleid=0x0, estate=0x8333778) at execMain.c:1280 #3 0x080c0dcd in ExecutePlan (estate=0x8333778, plan=0x83336f0, operation=CMD_INSERT, numberTuples=0, direction=ForwardScanDirection, destfunc=0x8334278) at execMain.c:1119 #4 0x080c026c in ExecutorRun (queryDesc=0x826fd88, estate=0x8333778, feature=3, count=0) at execMain.c:233 #5 0x0810b2d5 in ProcessQuery (parsetree=0x826c500, plan=0x83336f0, dest=Remote, completionTag=0xbfffec10 "") at pquery.c:259 #6 0x08109c83 in pg_exec_query_string ( query_string=0x826c168 "insert into jobsequences select * from rev_000_jobsequences", dest=Remote, parse_context=0x8242cd8) at postgres.c:811 #7 0x0810abee in PostgresMain (argc=4, argv=0xbfffee40, username=0x8202d59 "laurette") at postgres.c:1929 #8 0x080f24fe in DoBackend (port=0x8202c28) at postmaster.c:2243 #9 0x080f1e9a in BackendStartup (port=0x8202c28) at postmaster.c:1874 #10 0x080f10e9 in ServerLoop () at postmaster.c:995 #11 0x080f0c56 in PostmasterMain (argc=1, argv=0x81eb398) at postmaster.c:771 #12 0x080d172b in main (argc=1, argv=0xb7d4) at main.c:206 #13 0x401e7177 in __libc_start_main (main=0x80d15a8 , argc=1, ubp_av=0xb7d4, init=0x80676ac <_init>, fini=0x81554f0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xb7cc) at ../sysdeps/generic/libc-start.c:129 Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- It's 10 o'clock... Do you know where your bus is? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pgsql 7.2.3 crash
On Wed, 9 Oct 2002, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > A core file was found in /base/326602604
> > and a backtrace shows:
> > (gdb) bt
> > #0 DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0,
> > newtup=0x8348150) at trigger.c:2056
>
> Hm. Line 2056 is this:
>
> for (i = 0; i < ntriggers; i++)
> {
> Trigger*trigger = &trigdesc->triggers[tgindx[i]];
>
> ->new_event->dte_item[i].dti_tgoid = trigger->tgoid;
>
> It seems there must be something wrong with the trigdesc data structure
> for that table, but what? Can you poke around in the corefile with gdb
> print commands and determine what's wrong with the trigdesc?
Here's my poking/printing around with gdb:
(gdb) print trigger
$1 = (Trigger *) 0x1272c9a0
(gdb) print *trigger
Cannot access memory at address 0x1272c9a0
(gdb) print trigger->tgoid
Cannot access memory at address 0x1272c9a0
(gdb) print trigdesc
$2 = (TriggerDesc *) 0x4c86b2d8
(gdb) print &trigdesc
$3 = (TriggerDesc **) 0xbfffea18
(gdb) print *trigdesc
$4 = {n_before_statement = {5378, 22310, 37184, 2085}, n_before_row =
{51128, 19585,
62320, 19589}, n_after_row = {45784, 19590, 52748, 2084},
n_after_statement = {
0, 0, 0, 0}, tg_before_statement = {0x4c86b2d8, 0x8259910, 0x0, 0x0},
tg_before_row = {0xa0, 0x35, 0x1f, 0x4006}, tg_after_row =
{0x8242920,
0x4c860cb0, 0x4c86eec0, 0x0}, tg_after_statement = {0x0, 0x0, 0x0,
0x0},
triggers = 0x4c86e7a0, numtriggers = 8}
>
> > I see triggers referenced here and it should be
> > noted that for one of the tables the triggers were first disabled (update
> > pg_class) and re-enabled after the inserts are done (or it takes
> > forever).
>
> Did that happen while this backend was running?
Yes. I had run this perl program about 4-5 times in a row (which includes
the sequence, disable triggers, insert rows, enable triggers) and then it
crashed on one of the runs.
Thanks,
--
Laurette Cisneros
The Database Group
(510) 420-3137
NextBus Information Systems, Inc.
www.nextbus.com
--
It's 10 o'clock...
Do you know where your bus is?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgsql 7.2.3 crash
Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it could have walked on it. Thanks. L. On Sat, 12 Oct 2002, Tom Lane wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > I see triggers referenced here and it should be > > noted that for one of the tables the triggers were first disabled (update > > pg_class) and re-enabled after the inserts are done (or it takes > > forever). > >> > >> Did that happen while this backend was running? > > > Yes. I had run this perl program about 4-5 times in a row (which includes > > the sequence, disable triggers, insert rows, enable triggers) and then it > > crashed on one of the runs. > > Hm. The stack trace shows that this backend crashed while executing the > command > insert into jobsequences select * from rev_000_jobsequences > Is it possible that you disabled and re-enabled triggers on jobsequences > *while this command was running* ? > > The gdb info makes it look like the triggers code is using a stale > trigger description structure. The pointer that's being used is cached > in the ResultRelInfo struct (ri_TrigDesc) during query startup. If > some external operation changed the trigger state while the query is > running, trouble would ensue. > > This looks like something we ought to fix in any case, but I'm unsure > whether it explains your crash. Do you think that that's what could > have happened? > > > Hackers: we might reasonably fix this by doing a deep copy of the > relcache's trigger info during initResultRelInfo(); or we could fix it > by getting rid of ri_TrigDesc and re-fetching from the relcache every > time. The former would imply that trigger state would remain unchanged > throughout a query, the latter would try to track currently-committed > trigger behavior. Either way has got pitfalls I think. > > The fact that there's a problem at all is because people are using > direct poking of the system catalogs instead of some kind of ALTER TABLE > command to disable/enable triggers; an ALTER command would presumably > gain exclusive lock on the table and thereby delay until active queries > finish. But that technique is out there (even in pg_dump files :-() and > so we'd best try to make the system proof against it. > > Any thoughts on which way to go? > > regards, tom lane > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- It's 10 o'clock... Do you know where your bus is? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql 7.2.3 crash
Great. I am working my way toward 7.3 anyway... Thanks! L. On Mon, 14 Oct 2002, Tom Lane wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > Yeah I think that could have happened since I was running it several times and had > > cancelled it (ctrl-c) it a couple of those times. Could be the backend of one > > cancelled run hadn't finished what it was doing and if that was renabling > > triggers it could have walked on it. > > Sounds like we've got the explanation, then. > > I've just committed fixes into 7.3 to prevent this scenario in future. > The patch is probably too large to risk back-patching into 7.2.* though. > > regards, tom lane > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- It's 10 o'clock... Do you know where your bus is? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.3b3 createuser error
7.3b3 as postgres user createuser laurette Shall the new user be allowed to create databases? (y/n) y Shall the new user be allowed to create more new users? (y/n) y ERROR: 'autocommit' is not a valid option name createuser: creation of user "laurette" failed any ideas? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3b3 createuser error
Ugh. Path problem...sorry for jumping the gun. On Fri, 1 Nov 2002, Laurette Cisneros wrote: > 7.3b3 > > as postgres user > > createuser laurette > Shall the new user be allowed to create databases? (y/n) y > Shall the new user be allowed to create more new users? (y/n) y > ERROR: 'autocommit' is not a valid option name > createuser: creation of user "laurette" failed > > any ideas? > > Thanks, > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(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] disable a single trigger
What is the status of the tgenabled field in pg_trigger? It would be so nice to be able to disable just a single trigger on a table rather than having to disable all triggers. The docs say "not presently checked everywhere it should be, so disabling a trigger by setting this false does not work reliably". Will it ever be reliable? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] 7.3b5 contrib compile problem
I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in >seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3b5 contrib compile problem
bison --version GNU Bison version 1.28 Should I update it? This just started with 7.3b4. Thanks, L. On Wed, 6 Nov 2002, Bruce Momjian wrote: > > Wow, that is strange. I have bison 1.75 here and it compiles fine. > What version of bison do you have? > > bison --version > > --- > > Laurette Cisneros wrote: > > > > I saw this when compiling 7.3b4 as well and also with 7.3b5 > > > > cd contrib > > make > > ... > > make[1]: Leaving directory > > `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' > > make[1]: Entering directory > > `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' > > sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in >seg.sql > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. > > -I../../src/include -I/usr/local/include -c -o seg.o seg.c > > bison -y -d -p seg_yy segparse.y > > mv -f y.tab.c segparse.c > > mv -f y.tab.h segparse.h > > /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. > > -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c > > In file included from segscan.l:8, > > from segparse.y:182: > > segparse.h:2: redefinition of `struct BND' > > segparse.h:8: conflicting types for `YYSTYPE' > > segparse.y:48: previous declaration of `YYSTYPE' > > segparse.h:15: conflicting types for `seg_yylval' > > /usr/lib/bison.simple:138: previous declaration of `seg_yylval' > > make[1]: *** [segparse.o] Error 1 > > make[1]: Leaving directory >`/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' > > make: *** [all] Error 2 > > > > Any ideas? > > > > Thanks, > > > > -- > > Laurette Cisneros > > The Database Group > > (510) 420-3137 > > NextBus Information Systems, Inc. > > www.nextbus.com > > -- > > My other vehicle is my imagination. > > - bumper sticker > > > > > > ---(end of broadcast)--- > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(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] 7.3b5 contrib compile problem
FYI: I easily updated to 1.75 and all is well. Thanks for all the help, L. On Thu, 7 Nov 2002, Tom Lane wrote: > I said: > >> It's interesting that bison 1.28's output is sufficiently different to > >> cause a problem, but we are not going to worry about supporting use of > >> old bisons. > > Well, it turned out to be reasonably easy to fix this, so I did. It > seems that bison 1.28 generates a .h file that cannot be included into > the .c file it generates :-(. Experimentation shows this is fixed in > bison 1.35, possibly earlier; but it's easy enough to just not include > the .h file. > > regards, tom lane > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Fwd: Re: [PERFORM] Odd Sort/Limit/Max Problem
Thank you for a good workaround. Even BETTER would be to fix the aggregates so workarounds wouldn't have to be found. Thanks again, L. On Fri, 13 Dec 2002, Josh Berkus wrote: > > > -- Forwarded Message -- > > Subject: Re: [PERFORM] Odd Sort/Limit/Max Problem > Date: Fri, 13 Dec 2002 12:10:20 -0800 (PST) > From: Stephan Szabo <[EMAIL PROTECTED]> > To: Josh Berkus <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > > On Fri, 13 Dec 2002, Josh Berkus wrote: > > > First, as expected, a regular aggregate is slow: > > > So we use the workaround standard for PostgreSQL: > > > > ... which is fast, but returns NULL, since nulls sort to the bottom! So we > > add IS NOT NULL: > > > > jwnet=> explain analyze select date_resolved from case_clients where > > date_resolved is not null order by date_resolved desc limit 1; > > NOTICE: QUERY PLAN: > > > > Limit (cost=0.00..4.06 rows=1 width=4) (actual time=219.63..219.64 rows=1 > > loops=1) > > -> Index Scan Backward using idx_caseclients_resolved on case_clients > > (cost=0.00..163420.59 rows=40272 width=4) (actual time=219.62..219.62 rows=2 > > loops=1) > > Total runtime: 219.76 msec > > > > Aieee! Almost as slow as the aggregate! > > I'd suggest trying a partial index on date_resolved where date_resolve is > not null. In my simple tests on about 200,000 rows of ints where 50% are > null that sort of index cut the runtime on my machine from 407.66 msec to > 0.15 msec. > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > --- > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- There's more to life than just SQL. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] 7.3 pg_dump with -Fc option crashes
This works: pg_dump -h myhost -p 5432 -f mydb.cpgdmp mydb This does not: pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb Segmentation fault (core dumped) Nor does this: pg_dump -h myhost -p 5432 -Ft -f mydb.cpgdmp mydb (but I need the -Fc badly as my dbs backup up to large files) Here's a stack track (if needed): (adb) bt #0 0x080562a6 in WriteStr (AH=0x8074638, c=0x6c627570 ) at pg_backup_archiver.c:1519 #1 0x080569b2 in WriteToc (AH=0x8074638) at pg_backup_archiver.c:1851 #2 0x080594b2 in _CloseArchive (AH=0x8074638) at pg_backup_custom.c:802 #3 0x080545ef in CloseArchive (AHX=0x8074638) at pg_backup_archiver.c:113 #4 0x0804a846 in main (argc=9, argv=0xb4cc) at pg_dump.c:645 #5 0x401ef306 in __libc_start_main (main=0x8049db0 , argc=9, ubp_av=0xb4cc, init=0x8049634 <_init>, fini=0x8064720 <_fini>, rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xb4bc) at ../sysdeps/generic/libc-start.c:129 Thanks, -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. wwy.nextbus.com -- Life is an SQL old chum... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3 pg_dump with -Fc option crashes
Oh goodness it's even worse as pg_restore can't read the archive from the first pg_dump: pg_dump -h myhost -p 5432 -f mydb.pgdmp mydb pg_restore -l mydb.pgdmp pg_restore: [archiver] input file does not appear to be a valid archive Thanks, L. On Fri, 10 Jan 2003, Laurette Cisneros wrote: > > This works: > pg_dump -h myhost -p 5432 -f mydb.cpgdmp mydb > > This does not: > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb > Segmentation fault (core dumped) > > Nor does this: > pg_dump -h myhost -p 5432 -Ft -f mydb.cpgdmp mydb > (but I need the -Fc badly as my dbs backup up to large files) > > Here's a stack track (if needed): > (adb) bt > #0 0x080562a6 in WriteStr (AH=0x8074638, > c=0x6c627570 ) at > pg_backup_archiver.c:1519 > #1 0x080569b2 in WriteToc (AH=0x8074638) at pg_backup_archiver.c:1851 > #2 0x080594b2 in _CloseArchive (AH=0x8074638) at pg_backup_custom.c:802 > #3 0x080545ef in CloseArchive (AHX=0x8074638) at pg_backup_archiver.c:113 > #4 0x0804a846 in main (argc=9, argv=0xb4cc) at pg_dump.c:645 > #5 0x401ef306 in __libc_start_main (main=0x8049db0 , argc=9, > ubp_av=0xb4cc, init=0x8049634 <_init>, fini=0x8064720 <_fini>, > rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xb4bc) > at ../sysdeps/generic/libc-start.c:129 > > Thanks, > > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- Life is an SQL old chum... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.3 pg_dump with -Fc option crashes
Thanks. I've nulled all the "comment on view"s but still get it... On Fri, 10 Jan 2003, Tom Lane wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > This does not: > > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb > > Segmentation fault (core dumped) > > If you have any comments on views, this is probably an instance of a > known bug: > > 2002-12-27 12:10 tgl > > * src/bin/pg_dump/: pg_dump.c (REL7_3_STABLE), pg_dump.c: Remove > overenthusiastic free'ing of comment dependencies; could lead to > core dump in pg_dump when dumping views having comments. See bug > #855. > > This fix postdates 7.3.1, but you could get the patch from the CVS > server or the pgsql-bugs archives. > > regards, tom lane > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- Life is an SQL old chum... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3 pg_dump with -Fc option crashes
That did the trick...fixed pg_dump! And, pg_restore works on it too! Yay, I can go home now. Thanks very much for your help! On Fri, 10 Jan 2003, Tom Lane wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > This does not: > > pg_dump -h myhost -p 5432 -Fc -f mydb.cpgdmp mydb > > Segmentation fault (core dumped) > > If you have any comments on views, this is probably an instance of a > known bug: > > 2002-12-27 12:10 tgl > > * src/bin/pg_dump/: pg_dump.c (REL7_3_STABLE), pg_dump.c: Remove > overenthusiastic free'ing of comment dependencies; could lead to > core dump in pg_dump when dumping views having comments. See bug > #855. > > This fix postdates 7.3.1, but you could get the patch from the CVS > server or the pgsql-bugs archives. > > regards, tom lane > -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- Life is an SQL old chum... ---(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] [ANNOUNCE] PostgreSQL v7.3.2 Released
Well this isn't any good...the primary site is hugely busy and it is not on any of the mirrors. Perhaps it did not get copied over to the mirrors even though this announcent says it is there? Thanks, L. On Wed, 5 Feb 2003, Marc G. Fournier wrote: > > G'day ... > > This is just a quick announcement that v7.3.2 has been tag'd (REL7_3_2), > and released, to address several problems found with v7.3.1. This release > addresses several overrun and memory leak issues that were found in recent > weeks, so it is highly recommended that those running the v7.3.1 branch > upgrade at their earliest convience. > > > Major changes in this release are, as listed in the HISTORY file: > >Restore creation of OID column in CREATE TABLE AS / SELECT INTO >Fix pg_dump core dump when dumping views having comments >Dump DEFERRABLE/INITIALLY DEFERRED constraints properly >Fix UPDATE when child table's column numbering differs from parent >Increase default value of max_fsm_relations >Fix problem when fetching backwards in a cursor for a single-row query >Make backward fetch work properly with cursor on SELECT DISTINCT query >Fix problems with loading pg_dump files containing contrib/lo usage >Fix problem with all-numeric user names >Fix possible memory leak and core dump during disconnect in libpgtcl >Make plpython's spi_execute command handle nulls properly (Andrew Bosma) >Adjust plpython error reporting so that its regression test passes again >Work with bison 1.875 >Handle mixed-case names properly in plpgsql's %type (Neil) >Fix core dump in pltcl when executing a query rewritten by a rule >Repair array subscript overruns (per report from Yichen Xie) >Reduce MAX_TIME_PRECISION from 13 to 10 in floating-point case >Correctly case-fold variable names in per-database and per-user settings >Fix coredump in plpgsql's RETURN NEXT when SELECT into record returns > no rows >Fix outdated use of pg_type.typprtlen in python client interface >Correctly handle fractional seconds in timestamps in JDBC driver >Improve performance of getImportedKeys() in JDBC >Make shared-library symlinks work standardly on HPUX (Giles) >Repair inconsistent rounding behavior for timestamp, time, interval >SSL negotiation fixes (Nathan Mueller) >Make libpq's ~/.pgpass feature work when connecting with PQconnectDB >Update my2pg, ora2pg >Translation updates >Add casts between types lo and oid in contrib/lo >fastpath code now checks for privilege to call function > > This release is backwards compability to the previous v7.3.x releases, and > does not require a dump/restore to upgrade ... > > This release can be found on all mirrors, as well as the main site, under: > > /pub/source/v7.3.2 > > Please submit any bug reports for this release to > >[EMAIL PROTECTED] > > > > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Laurette Cisneros, L.D. The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- "No man is wise enough by himself" -- Titus Maccius Plautus (254 Bc - 184 BC), Miles Gloriosus ---(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] [ANNOUNCE] PostgreSQL v7.3.2 Released
I was trying from the postgresql.org download web page and following the mirror links there...and none of them that I was able to get to (some of them didn't work) showed 7.3.2. The second link you gave below works. Thanks, L. On Wed, 5 Feb 2003, Tom Lane wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > Well this isn't any good...the primary site is hugely busy and it is not on > > any of the mirrors. > > Sure it is. I tried two at random: > > ftp://ftp.us.postgresql.org/source/v7.3.2/ > ftp://ftp.dk.postgresql.org/mirrors/postgresql/source/v7.3.2/ > > The top-level symlink may not be there yet (I think Marc forgot to make > it on the master until today), but the tarball is there if you look > under source/. > > regards, tom lane > -- Laurette Cisneros, L.D. The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- "No man is wise enough by himself" -- Titus Maccius Plautus (254 Bc - 184 BC), Miles Gloriosus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] index corruption?
This is the second time I've seen this. 7.3.2 This particular table is empty. I'm trying to read it in a perl script. It doesn't duplicate regularly (I have a script that creates the database by copying table data from another databases). This is the error in the pgsql log: 2003-02-13 16:21:42 [8843] ERROR: Index external_signstops_pkey is not a btree 2003-02-13 16:21:42 [8843] ERROR: current transaction is aborted, queries ignored until end of transaction block Any ideas? -- Laurette Cisneros, L.D. The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- "No man is wise enough by himself" -- Titus Maccius Plautus (254 Bc - 184 BC), Miles Gloriosus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Timestamp, fractional seconds problem
Problem: the external representation of time and timestamp are less precise than the internal representation. We are using postgresql 7.1.3 The timestamp and time types support resolving microseconds (6 places beyond the decimal), however the output routines round the value to only 2 decimal places. This causes data degradation, if a table with timestamps is copied out and then copied back in, as the timestamps lose precision. We feel this is a data integrity issue. Copy out (ascii) does not maintain the consistency of the data it copies. In our application, we depend on millisecond resolution timestamps and often need to copy out/copy back tables. The current timestamp formating in postgresql 7.1.x breaks this badly. A work around for display might be to use to_char(). But for copy the only workaround we have found is to use binary copy. Alas, binary copy does not work for server to client copies. Unfortunately, we need to copy to the client machine. The client copy does not support binary copies so we lose precision. Our suggested fix to this problem is to change the encoding of the fractional seconds part of the datetime and time types in datetime.c (called by timestamp_out, time_out) to represent least 6 digits beyond the decimal (ie "%0.6f"). A configurable format would also work. If there is another way to force the encoding to be precise we'd love to hear about it. Otherwise this appears to be a silent data integrity bug with unacceptable workarounds. Thanks! Laurette Cisneros ([EMAIL PROTECTED]) Elein Mustain NextBus Information Systems ---(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] Timestamp, fractional seconds problem
Thanks Thomas...at least there will be a way to specify more than 2. we are looking forward to this release... L. On Thu, 4 Oct 2001, Thomas Lockhart wrote: > Laurette Cisneros wrote: > > > > Could I get some more specific information on how this is fixed. Keep in mind >that using tochar() is not an option for us in that we ned to use COPY to/from the >client. > > I'm finishing up implementing SQL99-style precision features in > timestamp et al, so there will no longer be an arbitrary rounding of > time to 2 decimal places when values are output. There will of course be > *other* issues for you to worry about, since the default precision > specified by SQL99 is zero decimal places... > > - Thomas > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Timestamp, fractional seconds problem
This is very good news. Thanks to all for the response. L. On Thu, 4 Oct 2001, Karel Zak wrote: > On Wed, Oct 03, 2001 at 05:02:59PM -0700, Laurette Cisneros wrote: > > > A work around for display might be to use to_char(). > > In 7.2 is possible use millisecond / microsecond format: > > # select to_char(now()+'2s 324 ms'::interval, 'HH:MM:SS MS'); >to_char > -- > 10:10:59 324 > (1 row) > > # select to_char(now()+'2s 324 ms 10 microsecon'::interval, 'HH:MM:SS US'); > to_char > - > 10:10:03 324010 > (1 row) > > Karel > > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(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] Timestamp, fractional seconds problem
Hi Thomas, Could I get some more specific information on how this is fixed. Keep in mind that using tochar() is not an option for us in that we ned to use COPY to/from the client. Thanks, L. On Thu, 4 Oct 2001, Thomas Lockhart wrote: > > Problem: the external representation of time and timestamp are > > less precise than the internal representation. > > Fixed (as of yesterday) in the upcoming release. > >- Thomas > -- Laurette Cisneros (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Passenger Information Everywhere ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Interval bug
Howdy hackers, Should I file a bug or is this known (or fixed)? Thanks! Laurette ([EMAIL PROTECTED]) Here's the psql ready test and description: -- -- BUG Description: -- A float with zeros on the right of the decimal -- fails conversion to an interval. -- interval ( int ) works -- interval ( float ) works -- interval ( float where 0 on the right of decimal ) fail. -- -- The first set of selects labelled "No Casting" show this -- problem. -- -- To further diagnose the problem, I tried each query -- with a cast to integer, float and float8. -- This diagnosis is shown in the section labelled "With Casting". -- Note that the float value cast to integer fails due to -- strtol called by pg_atoi(). (Stupid strtol). -- -- Possible solution: -- In postgresql-7.1.3:src/backend/utils/datetime.c, -- function ParseDateTime line 442: -- -- This if statement forces a string containing a decimal -- to be typed as a date. Although dates can contain decimal -- delimiters, it is more common for decimal delimiters to be -- assumed to be floats. Perhaps the algorithm could change -- so that 2 decimals in the string makes it a date and only -- one makes it a float and therefore time. The alternative -- is to force strings with decimals into floats only and therefore -- numeric and time only. -- \echo === \echo No casting \echo === \echo select interval(301); expect 00:05:01 select interval( 301 ); \echo \echo select interval( 301.01 ); expect 00:05:01.01 select interval( 301.01 ); \echo \echo select interval( 301.00 ); expect 00:05:01 get error on interval select interval( 301.00 ); \echo === \echo With casting \echo === \echo \echo select interval( 301::integer); expect 00:05:01 select interval( 301::integer ); \echo select interval( 301::float); expect 00:05:01 select interval( 301::float ); \echo select interval( 301::float8 ); expect 00:05:01 select interval( 301::float8 ); \echo \echo select interval( 301.01::integer); expect 00:05:01.01; pg_atoi message caused by strtol select interval( 301.01::integer ); \echo select interval( 301.01::float); expect 00:05:01.01 select interval( 301.01::float ); \echo select interval( 301.01::float8); expect 00:05:01.01 select interval( 301.01::float8 ); \echo \echo select interval( 301.00::integer); expect 00:05:01; pg_atoi message caused by strtol select interval( 301.00::integer ); \echo select interval( 301.00::float); expect 00:05:01 select interval( 301.00::float ); \echo select interval( 301.00::float8); expect 00:05:01 select interval( 301.00::float8); ---(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] pg_dump 2GB limit?
The archives search is not working on postgresql.org so I need to ask this question... We are using postgresql 7.2 and when dumping one of our larger databases, we get the following error: File size limit exceeded (core dumped) We suspect pg_dump. Is this true? Why would there be this limit in pg_dump? Is it scheduled to be fixed? Thanks, -- Laurette Cisneros Database Roadie (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Where's my bus? ---(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] pg_dump 2GB limit?
Hi, I'm on Red Hat. Here's the uname info: Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown What do I need to do to "turn on large file support" in the compile? Thanks, L. On 28 Mar 2002, Doug McNaught wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > > The archives search is not working on postgresql.org so I need to ask this > > question... > > > > We are using postgresql 7.2 and when dumping one of our larger databases, > > we get the following error: > > > > File size limit exceeded (core dumped) > > > > We suspect pg_dump. Is this true? Why would there be this limit in > > pg_dump? Is it scheduled to be fixed? > > This means one of two things: > > 1) Your ulimits are set too low, or > 2) Your pg_dump wasn't compiled against a C library with large file >support (greater than 2GB). > > Is this on Linux? > > -Doug > -- Laurette Cisneros Database Roadie (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Where's my bus? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump 2GB limit?
Oops sent the wrong uname, here's the one from the machine we compiled on: Linux lept 2.4.16 #6 SMP Fri Feb 8 13:31:46 PST 2002 i686 unknown and has: libc-2.2.2.so We use ./configure Still a problem? We do compress (-Fc) right now, but are working on a backup scheme that requires and uncompressed dump. Thanks for the help! L. On 28 Mar 2002, Doug McNaught wrote: > Laurette Cisneros <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I'm on Red Hat. Here's the uname info: > > Linux visor 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown > > That's an old and buggy kernel, BTW--you should install the errata > upgrades, > > > What do I need to do to "turn on large file support" in the compile? > > Make sure you are running the latest kernel and libs, and AFAIK > 'configure' should set it up for you automatically. > > -Doug > -- Laurette Cisneros Database Roadie (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com Where's my bus? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
