[ADMIN] Problem with compiling postgresql-8.2.1
Hello, i've got a problem with compiling postgresql-8.2.1. My operating system distribution is ubuntu-6.10 with gnu make-3.81-2 and gcc-4.1.1. The last few output lines of gmake are: make -C makefiles all make[2]: Entering directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make -C test/regress all make: Entering an unknown directory make: *** test/regress: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src' make: *** [all] Error 2 What went wrong? Best regards and thanks for your help! Bernd Nicklas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Problem with compiling postgresql-8.2.1
Bernd Nicklas wrote: Hello, i've got a problem with compiling postgresql-8.2.1. My operating system distribution is ubuntu-6.10 with gnu make-3.81-2 and gcc-4.1.1. The last few output lines of gmake are: make -C makefiles all make[2]: Entering directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make -C test/regress all make: Entering an unknown directory make: *** test/regress: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src' make: *** [all] Error 2 What are you compiling? Sounds like you got the postgresql-base tarball or some such, which doesn't include the regression test files. Try downloading the full tarball (I don't know what is it named). I wonder if it isn't time to remove the split tarballs. Do they buy us anything? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] Problem with compiling postgresql-8.2.1
Thanks! You're right. I didn't know that i need some more tarballs for complete installation :-) Best regards, Bernd Nicklas Alvaro Herrera wrote: Bernd Nicklas wrote: Hello, i've got a problem with compiling postgresql-8.2.1. My operating system distribution is ubuntu-6.10 with gnu make-3.81-2 and gcc-4.1.1. The last few output lines of gmake are: make -C makefiles all make[2]: Entering directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make -C test/regress all make: Entering an unknown directory make: *** test/regress: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src' make: *** [all] Error 2 What are you compiling? Sounds like you got the postgresql-base tarball or some such, which doesn't include the regression test files. Try downloading the full tarball (I don't know what is it named). I wonder if it isn't time to remove the split tarballs. Do they buy us anything? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] Problem with compiling postgresql-8.2.1
Στις Τετάρτη 31 Ιανουάριος 2007 16:36, ο/η Bernd Nicklas έγραψε: Thanks! You're right. I didn't know that i need some more tarballs for complete installation :-) You dont need no extra tarballs. Just postgresql-8.2.1.tar.bz2 Best regards, Bernd Nicklas Alvaro Herrera wrote: Bernd Nicklas wrote: Hello, i've got a problem with compiling postgresql-8.2.1. My operating system distribution is ubuntu-6.10 with gnu make-3.81-2 and gcc-4.1.1. The last few output lines of gmake are: make -C makefiles all make[2]: Entering directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src/makefiles' make -C test/regress all make: Entering an unknown directory make: *** test/regress: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sue/Desktop/Setups/postgresql-8.2.1/src' make: *** [all] Error 2 What are you compiling? Sounds like you got the postgresql-base tarball or some such, which doesn't include the regression test files. Try downloading the full tarball (I don't know what is it named). I wonder if it isn't time to remove the split tarballs. Do they buy us anything? ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Achilleas Mantzios ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[ADMIN] Users and Roles
How can I create a role and some reestrictions on it? The case is that I have many databases and thousands of users, I need to create users and these users can only connect to only one database and no more. Please help me. _ Charla con tus amigos en línea mediante MSN Messenger: http://messenger.latam.msn.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Users and Roles
-Original Message- How can I create a role and some reestrictions on it? The case is that I have many databases and thousands of users, I need to create users and these users can only connect to only one database and no more. Please help me. Hello Sidar! Perhaps you should read these pages in the documentation: http://www.postgresql.org/docs/8.2/interactive/user-manag.html and following. Greetings, Matthias ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] Problem with compiling postgresql-8.2.1
Alvaro Herrera [EMAIL PROTECTED] writes: I wonder if it isn't time to remove the split tarballs. Do they buy us anything? Not much except confusion, AFAICS. Marc's still convinced they're helpful though ... regards, tom lane ---(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: [ADMIN] Postgres encyrption export
There were similar discussions for mozilla and linux. I don't know more than what's in the articles. Perhaps there are people in the know on this list. Hope this is not too irrelevant. http://hecker.org/mozilla/eccn http://www.linuxjournal.com/article/7311 http://www.bakernet.com/ecommerce/usencryption.doc On Tue, 30 Jan 2007, Tom Dong wrote: I am still searching for information on the internet about Postgres Export review by US Commerce department. I did see an early email posted on POstgres mailing list about ECCN number of Postgres and saw the response debating if Postgres should be considered a US product. But I did not see any conclusion to that question, namely if POstgres has an ECCN number and if Postgres is a US product. Thanks! tom -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 4:03 PM To: pgsql-admin@postgresql.org Cc: Tom Dong Subject: Re: [ADMIN] Postgres encyrption export Tom Dong wrote: We are wondering whether there has been US Commerce Department review of the Postgres application for export. The Debian project submits all software it distributes to said department, so one can be fairly assured that they have heard of PostgreSQL, but how that affects what you are distributing I'm not sure. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend Regards, Ben K. Developer http://benix.tamu.edu ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[ADMIN] Ordering problem with varchar (DESC) - from general ml.
Hi all, I don't want to double post, but I see nothing hapening in the general mailling list, so I post here in case any one has an idea about what is going on. We have a column (varchar) that has plain text time and it is indexed. When I do a query with the index, all the data is in the right order, but when I user ORDER BY .. DESC, the order is messed up. Example: By index 1: (date, time, data) SELECT * from t1; date (date type) time (varchar) data 2007-01-17 8h40 d1 2007-01-30 9h30 d2 2007-01-3012h00 d3 2007-01-3013h45 d4 2007-01-3017h20 d5 SELECT * from t1 ORDER BY date, time DESC; date (date type) time (varchar) data 2007-01-30 9h30 d2 2007-01-3017h20 d5 2007-01-3013h45 d4 2007-01-3012h00 d3 2007-01-17 8h40 d1 I don't know why, this is like if the 'time' varchar was trimmed then used for the ordering. How can I fix that so that the result is exactly like the first one but perfectly reversed in it's order? Best regards. -- Alexandre Leclerc ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] Ordering problem with varchar (DESC) - from general ml.
Alexandre Leclerc [EMAIL PROTECTED] writes: We have a column (varchar) that has plain text time and it is indexed. When I do a query with the index, all the data is in the right order, but when I user ORDER BY .. DESC, the order is messed up. Example: By index 1: (date, time, data) SELECT * from t1; What makes you think that query is using an index? It's probably just returning the data in physical order, which might look correctly ordered if you inserted all the data in time order to start with. SELECT * from t1 ORDER BY date, time DESC; Perhaps you mean ORDER BY date DESC, time DESC ? I don't actually see how a varchar field set up like that would sort in a sensible numeric order at all --- text comparisons are unlikely to do what you'd like with the optional leading one. Consider replacing the varchar with a field of type TIME. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[ADMIN] Role privileges
I create this connected to postgres database: create role prueba_role with nosuperuser nocreatedb nocreaterole nologin noinherit; revoke all on database prueba_roles from prueba_role cascade; revoke create on database prueba_roles from prueba_role cascade; create user sidar with password 'sidar' login in role prueba_role; Then connect to prueba_roles database with user sidar. I guess that with these configuration the user cannot create tables, but I can do it. How to reestrict users to one database access and how to allow only SELECT permited? _ MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[ADMIN] postmaster udp ports?
Does anyone know what postmaster is doing with these UDP ports? On a fresh installation these ports are opened and I cannot find any documentation on what they are for postmaste 5398 postgres3u IPv4 53988 TCP *:5432 (LISTEN) postmaste 5398 postgres5u IPv4 53994 UDP ucs:32774-ucs:32774 postmaste 5400 postgres5u IPv4 53994 UDP ucs:32774-ucs:32774 Thanks Andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] postmaster udp ports?
Andrew Zahn [EMAIL PROTECTED] writes: Does anyone know what postmaster is doing with these UDP ports? Statistics collection. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] pg_dumpall problems
On 1/30/07, Tom Lane [EMAIL PROTECTED] wrote: Peter Koczan [EMAIL PROTECTED] writes: So, is there any remedy to my problem (see below) short of granting superuser access? Is this a bug (which I would then report on the appropriate channels)? It's not a bug. As for Tom's suggestion, there's no way to specify the database in pg_dumpall, only the server, and the same bug occurs if I run as the user on the same server and cluster with the same major version. You still haven't responded to my query: did you try it in the same database that pg_dumpall is connecting to? My guess is that you have munged the permissions on pg_shadow or pg_authid without understanding that that will only take effect in the one database you do it in. pg_dumpall is connecting to either postgres or template1 depending on version; what's the permissions situation in that database? regards, tom lane I misunderstood your question. I apologize. Granting access on postgres worked like a charm. Thank you. Peter
[ADMIN] 8.1.3 Problem
I am starting to have some significant problems with one of my 8.1.3databases. I am getting more and more of these errors: wbd,20552,dholton,2007-01-31 15:32:27.137 EST,45c0fcb4.5048,16,2007-01-31 15:31:48 EST,342126177,UPDATE,ERROR: could not access status of transaction 253762136 wbd,20552,dholton,2007-01-31 15:32:27.137 EST,45c0fcb4.5048,17,2007-01-31 15:31:48 EST,342126177,UPDATE,DETAIL: could not open file pg_clog/00F2: No such file or directory This is happening more and more, and on seeming random databases. Any idea what is going on? I have already dumped and reloaded 2-3 of my databases and now have about 3 more suffering from this. Right now, I can't upgrade to 8.1.6 until around March (have to wait until the current release of our application is released). I have 7 databases running 8.1.3 (6 prod and 1 test/dev) and only the test/dev is exhibiting this problem Any help/ideas on what is going on and how to fix would be appreciated. Chris
[ADMIN] blobs
I'm got the enviable task of redesigning an MySQL based project from scratch. We need a proper rdbms for this project, and I want to use PG 8.2. The table I'm concerned with at the moment have (currently) 5 million rows, with a churn of about 300,000 rows a week. The table has about a million hits a day, which makes it the main potential bottleneck in this database. We need to store some large ( 0 - 100kB ) data with each row. Would you recommend adding it as columns in this table, given that blobs will be stored in the pg_largeobject table anyway, or would you recommend a daughter table for this? Any other suggestions on how to avoid performance problems with this table ( hardware is dual Xeon, 4GB mem, 2 hardware raid channels for storage + 1 for logs, all running debian 32 bit ). Cheers, Steve ---(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: [ADMIN] blobs
I don't know about your table question, but may I ask why you're running 32-bit when you have dual Xeon processors? I have dual Xeon's in my DWH, and I used to run 32-bit which I upgraded to 64-bit over Christmas. We run a nightly import to that database which used to take around 5 hours which now completes in less than 1 hour. Many of our large queries also run much faster - the only thing I did was reload the box with RedHat ES 4 64-bit instead of 32-bit. My 2.2 cents (Aust. GST inclusive!) Cheers, -p -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Holdoway Sent: Thursday, 1 February 2007 08:46 To: pgsql-admin@postgresql.org Subject: [ADMIN] blobs I'm got the enviable task of redesigning an MySQL based project from scratch. We need a proper rdbms for this project, and I want to use PG 8.2. The table I'm concerned with at the moment have (currently) 5 million rows, with a churn of about 300,000 rows a week. The table has about a million hits a day, which makes it the main potential bottleneck in this database. We need to store some large ( 0 - 100kB ) data with each row. Would you recommend adding it as columns in this table, given that blobs will be stored in the pg_largeobject table anyway, or would you recommend a daughter table for this? Any other suggestions on how to avoid performance problems with this table ( hardware is dual Xeon, 4GB mem, 2 hardware raid channels for storage + 1 for logs, all running debian 32 bit ). Cheers, Steve ---(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 ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[ADMIN] unsubscribe
IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.
Re: [ADMIN] unsubscribe
You might have more luck here: http://archives.postgresql.org/pgsql-admin/ GURON Rawender wrote: Before printing, please consider the environment. IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. !DSPAM:37,45c11c5f118218703124696! -- Andy Shellam NetServe Support Team the Mail Network an alternative in a standardised world p: +44 (0) 121 288 0832/0839 m: +44 (0) 7818 000834
Re: [ADMIN] blobs
Availability of hardware monitoring software, and my personally being sick of things falling over. I have to run Mysql 4.0 on this server at the moment, and wasn't prepared to take the risk (: Maybe by the time we implement, 64 bit will be reliable enough. Steve On Thu, 1 Feb 2007 09:25:08 +1100 Phillip Smith [EMAIL PROTECTED] wrote: I don't know about your table question, but may I ask why you're running 32-bit when you have dual Xeon processors? I have dual Xeon's in my DWH, and I used to run 32-bit which I upgraded to 64-bit over Christmas. We run a nightly import to that database which used to take around 5 hours which now completes in less than 1 hour. Many of our large queries also run much faster - the only thing I did was reload the box with RedHat ES 4 64-bit instead of 32-bit. My 2.2 cents (Aust. GST inclusive!) Cheers, -p -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Holdoway Sent: Thursday, 1 February 2007 08:46 To: pgsql-admin@postgresql.org Subject: [ADMIN] blobs I'm got the enviable task of redesigning an MySQL based project from scratch. We need a proper rdbms for this project, and I want to use PG 8.2. The table I'm concerned with at the moment have (currently) 5 million rows, with a churn of about 300,000 rows a week. The table has about a million hits a day, which makes it the main potential bottleneck in this database. We need to store some large ( 0 - 100kB ) data with each row. Would you recommend adding it as columns in this table, given that blobs will be stored in the pg_largeobject table anyway, or would you recommend a daughter table for this? Any other suggestions on how to avoid performance problems with this table ( hardware is dual Xeon, 4GB mem, 2 hardware raid channels for storage + 1 for logs, all running debian 32 bit ). Cheers, Steve ---(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 ***Confidentiality and Privilege Notice*** The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email. Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [ADMIN] 8.1.3 Problem
It looks like to be a data corruption case a few cases like this have been discussed in the past as well. The following link -- http://archives.postgresql.org/pgsql-general/2006-12/msg01546.php might help you resolve the problem. -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 2/1/07, Chris Hoover [EMAIL PROTECTED] wrote: I am starting to have some significant problems with one of my 8.1.3databases. I am getting more and more of these errors: wbd,20552,dholton,2007-01-31 15:32:27.137 EST,45c0fcb4.5048,16,2007-01-31 15:31:48 EST,342126177,UPDATE,ERROR: could not access status of transaction 253762136 wbd,20552,dholton,2007-01-31 15:32:27.137 EST,45c0fcb4.5048,17,2007-01-31 15:31:48 EST,342126177,UPDATE,DETAIL: could not open file pg_clog/00F2: No such file or directory This is happening more and more, and on seeming random databases. Any idea what is going on? I have already dumped and reloaded 2-3 of my databases and now have about 3 more suffering from this. Right now, I can't upgrade to 8.1.6 until around March (have to wait until the current release of our application is released). I have 7 databases running 8.1.3 (6 prod and 1 test/dev) and only the test/dev is exhibiting this problem Any help/ideas on what is going on and how to fix would be appreciated. Chris
