Re: [PATCHES] Small documentation patch
+ SELECT 'epoch'::timestamp + '1070430858 seconds'::interval; + Result: 2003-12-03 05:54:18 You could also go: SELECT '1070430858'::abstime; But your way is probably a bit more stable...dunno... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] Small documentation patch
Kind people, This patch shows how to change UNIX timestamps into PostgreSQL timestamps, and clarifies how PERFORM works in PL/PgSQL. :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100cell: +1 415 235 3778 Index: func.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving revision 1.180 diff -2 -c -r1.180 func.sgml *** func.sgml 29 Nov 2003 19:51:37 - 1.180 --- func.sgml 3 Dec 2003 06:17:20 - *** *** 5006,5009 --- 5006,5018 SELECT EXTRACT(EPOCH FROM INTERVAL '5 days 3 hours'); Result: 442800 + + + To convert a UNIX timestamp (number of seconds since + 1970-01-01 00:00:00-00) into a timestamp, you can + write: + + + SELECT 'epoch'::timestamp + '1070430858 seconds'::interval; + Result: 2003-12-03 05:54:18 Index: plpgsql.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.32 diff -2 -c -r1.32 plpgsql.sgml *** plpgsql.sgml30 Nov 2003 05:45:22 - 1.32 --- plpgsql.sgml3 Dec 2003 06:17:22 - *** *** 1033,1036 --- 1033,1050 + + + Another example, which returns true if user foo is in group bar: + + PERFORM * + FROM + pg_catalog.pg_user u + , pg_catalog.pg_group g + WHERE u.usesysid = ANY(g.grolist) + AND u.usename='foo' + AND g.groname='bar'; + + + ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] introduce "default_use_oids"
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I'm sure there are other ways to phase out OIDs in dumps. Okay, fair enough -- I'll submit a patch to change this. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] introduce "default_use_oids"
If I want to develop a portable application or I want to port an application, then I am of course only going to use portable constructs, that is, tables and views, and possibly sequences. I'm not talking theory here -- I've actually done it and made several changes to pg_dump along the way to make the output portable. This is an actual feature that is being destroyed. OK. I'm sure there are other ways to phase out OIDs in dumps. For example, we could set the default mode at the top (easily deleted, much safer than running a global search and replace) and then add WITH/WITHOUT OIDS only to those tables that deviate from the default. Ok, more thought is required then. Chris ---(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: [PATCHES] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
Kurt Roeckx <[EMAIL PROTECTED]> writes: > If that really was the error you got, your patch couldn't have > fixed it since it didn't change anything that has something to do > with it. I entirely concur with Kurt's observation. My bet is you got the "no space left on device" failure because you were already running a postmaster that was eating all the available semaphores. When it worked, it was because you'd stopped the other postmaster, and not because of any code changes. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
creating template1 database in /export/home/tbaden/posttemp/postgresql-7.4/src/test/regress/./tmp_check/data/b+ase/1... FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(1, 17, 03600). HINT: This error does *not* mean that you have run out of disk space. It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 10). semget() is about semaphores, not shared memory. If that really was the error you got, your patch couldn't have fixed it since it didn't change anything that has something to do with it. Did you read the documentation on how to raise those limits, and raise them? (Not sure if it's needed for 2.8) Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] 7.4 shared memory error on 64-bit SPARC/Solaris 5.8
--- Tom Lane <[EMAIL PROTECTED]> wrote: > Kurt Roeckx <[EMAIL PROTECTED]> writes: > > He seems to have changed this too: > > - typedef uint32 IpcMemoryKey; > > + typedef size_t IpcMemoryKey; > > That really should be a key_t. > > Yeah, I made it key_t in CVS tip. I'm just > wondering what this could > avoid other than possibly a compile warning. > > regards, tom lane Greetings. Sorry for the late reply. I just re-extracted and compiled the 7.4 release, and recreated the error. $ ls -ld postgresql-7.4.tar.bz2 -rw--- 1 tbaden prd 669 Nov 18 12:22 postgresql-7.4.tar.bz2 $ md5 postgresql-7.4.tar.bz2 MD5(postgresql-7.4.tar.bz2)= 9db7432c431d1570b1f605727daf27bc $ ./configure --with-python --with-openssl --without-readline Pertinent environment variables: CC='cc -xtarget=ultra -xarch=v9 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__' CXX='CC -xtarget=ultra -xarch=v9 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__' After compilation, make check fails as follows: make[3]: Leaving directory `/export/home/tbaden/posttemp/postgresql-7.4/contrib/spi' /bin/sh ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte=SQL_ASCII == creating temporary installation == == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. I have attached initdb.log for your perusal. I just went digging through the system include files, and sure enough they do refer to key_t instead of size_t. I don't recall why I used size_t, except that it must have been referenced in either a different .h file or man page. Cheers, -Thomas __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree initdb.log Description: initdb.log ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] introduce "default_use_oids"
Bruce Momjian <[EMAIL PROTECTED]> writes: > Also, I think we have to have a SET before every CREATE TABLE. No, only when the value changes from last time. This is not rocket science, it's the way pg_dump handles SETs already. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] introduce "default_use_oids"
Peter Eisentraut wrote: > Neil Conway writes: > > > I'm really not sure we do: the SQL produced by pg_dump was totally > > non-portable before, > > Significant effort has been invested to make pg_dump output portable, and > I've not had any problems with it last time I tried it. Please explain > why you think it's "totally" non-portable. Also, I think we have to have a SET before every CREATE TABLE. If we don't how does it work if we restore a single table from the dump? We must handle this type of thing with SET SESSION AUTHORIZATION to make sure we are the proper owner, so it seems we could do the same with oids. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] YA Cygwin DLLIMPORT patch
Applied ot 7.4.1 now. Thanks. --- Christopher Kings-Lynne wrote: > Did you commit to 7.4.1 too Bruce? > > Chris > > Bruce Momjian wrote: > > > Patch applied. Thanks. > > > > --- > > > > > > Jason Tishler wrote: > > > >>The attached patch enables contrib/cube to build cleanly under Cygwin > >>(again). Please consider this patch for the 7.4.1 branch (if there will > >>be one) too. > >> > >>Thanks, > >>Jason > >> > >>-- > >>PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers > >>Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 > > > > > > [ Attachment, skipping... ] > > > > > >>---(end of broadcast)--- > >>TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] introduce "default_use_oids"
Peter Eisentraut wrote: > If I want to develop a portable application or I want to port an > application, then I am of course only going to use portable constructs, > that is, tables and views, and possibly sequences. I'm not talking theory > here -- I've actually done it and made several changes to pg_dump along > the way to make the output portable. This is an actual feature that is > being destroyed. > > I'm sure there are other ways to phase out OIDs in dumps. For example, we > could set the default mode at the top (easily deleted, much safer than > running a global search and replace) and then add WITH/WITHOUT OIDS only > to those tables that deviate from the default. Agreed. By using SET, you could still pipe the file through another database --- the SETs would fail, but the CREATE TABLE commands would work. With WITH/WITHOUT OIDS, the CREATE TABLEs would fail. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] introduce "default_use_oids"
Christopher Kings-Lynne writes: > > Significant effort has been invested to make pg_dump output portable, and > > I've not had any problems with it last time I tried it. Please explain > > why you think it's "totally" non-portable. > > Functions, indexes, operators, types, aggregates, users, groups, > databases, inheritance, clustering, col stats, col storage, ... > > What IS compatible? Very basic table definitions? If I want to develop a portable application or I want to port an application, then I am of course only going to use portable constructs, that is, tables and views, and possibly sequences. I'm not talking theory here -- I've actually done it and made several changes to pg_dump along the way to make the output portable. This is an actual feature that is being destroyed. I'm sure there are other ways to phase out OIDs in dumps. For example, we could set the default mode at the top (easily deleted, much safer than running a global search and replace) and then add WITH/WITHOUT OIDS only to those tables that deviate from the default. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Index creation takes for ever
On Mon, 01 Dec 2003 13:32:10 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >Manfred Koizar <[EMAIL PROTECTED]> writes: >> comparetup_index() compares two IndexTuples. The structure >> IndexTupleData consists basically of not much more than an ItemPointer, >> and the patch is not much more than adding a comparison of two >> ItemPointers. So how does the patch introduce a new low level >> implementation dependency? > >Because it sorts on tuple position, which is certainly about as low >level as you can get. The patch affects only the sort during index creation. Mapping key values to tuple positions is the sole purpose of an index. The notion that an index should not care for tuple positions looks a bit strange to me. > More to the point, though, no evidence has been >provided that this is a good idea. The test script I posted with the patch shows that the patch produces more efficient b-tree indices when there are lots of duplicates. Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
