Re: [GENERAL] Linux Distribution Preferences?
On 2013-01-14 00:44, Gavin Flower wrote: On 14/01/13 07:27, Shaun Thomas wrote: Hey guys, I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ [1] for terms and conditions related to this email I would tend use Fedora for development, but would consider CentOS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. Cheers, Gavin Links: -- [1] http://www.peak6.com/email_disclaimer/ I use Slackware and for me it's the perfect one. Some words are rotating in my mind: There is no good or bad linux, exists only one that which you know and can work. Cheers, Hristo -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On Mon, Jan 14, 2013 at 2:46 PM, Scott Marlowe wrote: > Most importantly, if you've got LOTS of talent for one distro or > another, you're probably best off exploiting it. If 95% of all the > developers and ops crew run Ubuntu or Debian, stick to one of them. > If they favor Fedora / RHEL stick to that. If they work on windows, > find a new job if at all possible. +1. It's the little things that make the difference; I can casually switch across from any of our client boxes to any of our servers, because they ALL run Debian Squeeze. And my home boxes and my personal server are also all either Debian Squeeze or some flavour of Ubuntu. Keep things as similar as possible and you avoid wasting time over trivialities like whether you can run ifconfig without becoming root first, or which shells and scripting languages you have available (for me, Python, bash, and Pike cover all my normal needs). Downtime costs you, yes, but also, don't keep your developers waiting, child! Why, their time is worth a thousand pounds a minute (in 1871 currency). And +1 to the last comment, too :) ChrisA -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Bulk INSERT with individual failure
On 2013.01.13 5:58 PM, Robert James wrote: I need to INSERT a large number of records. For performance reasons, I'd rather send them to Postgres in one giant INSERT. However, if there's a problem in one record (eg one row doesn't meet a constraint), I'd still like the others saved. That is, I specifically DO NOT want atomic behavior. It's okay to silently drop bad data in this case - I don't even need to know about it. Is there any way to do this, or am I forced to but each record into its own INSERT? Here's the best way: 1. Create a temporary staging table and bulk-insert all your data into it. This table would resemble the actual destination and has slots to hold all the data, but it would have weaker constraints, eg no unique/pk or foreign keys, such that your raw data is guaranteed to be accepted. 2. Use all the nice data analysis tools that SQL gives you and perform an INSERT...SELECT... into the actual destination from the staging table, and have any filters or tests or cleanups or joins with other tables (such as the destination table) that you desire so to preemptively take care of anything that would have caused a constraint failure. Modify to taste. In fact, this is my generally recommended method for doing any kind of bulk data import, because its much easier to clean data using SQL than otherwise, and its all very efficient resource-wise. -- Darren Duncan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Backup/Restore bytea data
Hi, I am having an issue upgrading a really old 8.2 db up to 9.2.2. One of the tables contains a bytea field. When I backup & restore using pgadmin from my 9.2.2 install, it doesn't convert this field correctly. The original 8.2 database was created like: CREATE DATABASE test... ENCODING = 'SQL_ASCII' ...; I tried creating the new database as: CREATE DATABASE test WITH OWNER = steve ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'English_United States.1252' LC_CTYPE = 'English_United States.1252' CONNECTION LIMIT = -1; And I also tried creating it w/ENCODED back to 'SQL_ASCII', but it still give me bad data in the bytea field. I can confirm it is not the same data by executing: select encode(data, 'escape') from pic_data where key = 36 I see it starts w/special character when selecting it from the old database; in the new db, I see a string starting w/"\211PNG". I've googled around and found someone else converting the full back using iconv, so they can import into a UTF8 db, but that didn't work for me. Plus, I didn't think I would need to do anything for an SQL_ASCII->SQL_ASCII backup/restore. What am I missing here? Thanks. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Backup-Restore-bytea-data-tp5740005.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] INSERT... WHERE
On Mon, Jan 14, 2013 at 3:37 PM, Robert James wrote: > Thanks. But how do I do that where I have many literals? Something like: > > INSERT INTO seltest (id, a, b) SELECT (1,2,3),(4,5,6),(7,8,9) WHERE b > IN (SELECT ...) You can use WITH clauses in crazy ways with PostgreSQL. I haven't actually tried it, but you should be able to put your VALUES behind a WITH, then SELECT from that WHERE blah blah, and INSERT that SELECT. As they say, knock yourself out! :) ChrisA -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] INSERT... WHERE
On 1/13/13, Ian Lawrence Barwick wrote: > 2013/1/14 Robert James : >> I have a lot of VALUES I want to INSERT. But only a subset of them - >> only those that meet a JOIN criteria involving another table. >> >> I could INSERT them into a temp table, and then do a SELECT INTO. But >> do I need to do that? Is there any way to do a INSERT... VALUES ... >> WHERE... > > INSERT INTO ... SELECT is what you are looking for. > > Simple example: > > CREATE TABLE seltest (id INT); > INSERT INTO seltest (id) SELECT 1; Thanks. But how do I do that where I have many literals? Something like: INSERT INTO seltest (id, a, b) SELECT (1,2,3),(4,5,6),(7,8,9) WHERE b IN (SELECT ...) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On 14/01/13 16:46, Scott Marlowe wrote: On Sun, Jan 13, 2013 at 4:06 PM, SUNDAY A. OLUTAYO wrote: 4 reasons: 1. One place where I worked Ubuntu was standard, I tried it and found that it lacked at least a couple of desktop features in GNOME 2 that I found very useful into Fedora. Fortunately, I was allowed to revert back to Fedora. Prior to that, I was using Fedora mainly by default. 2. Twice I came across features that I liked and Ubuntu seemed to imply they had done them, later I found the projects been initiated and sponsored largely by Red Hat. Especially as Red Hat is in the top ten contributors to the kernel, and the contribution of Ubuntu is not significant. 3. Ubuntu distributions are now starting to be filled with crapware and ant-privacy features features. 4. Ubuntu seems very good at collecting fanbois. Not one of those is a good reason to avoid Ubuntu server for pgsql. There are reasons to not use it, but those are not them. I've run PostgreSQL servers on Redhat (before RHEL existed and there was JUST Redhat) 5.1, RHEL 4, 5 and 6, Debian Lenny and Squeeze, just one on an old version of Suse, and on Ubuntu server 8.04LTS and 10.04LTS and 12.04LTS. My preference personally is for debian based distros since they support the rather more elegant pg wrappers that allow you to run multiple versions and multiple clusters of those versions with very easy commands. RHEL is great for building a stable but not necessarily ultra faster server, and if you can afford their commercial support it IS top notch. Debian and Ubuntu feel much the same to me, from the command line, on a server. The reasons to NOT use ubuntu under PostgreSQL are primarily that 1: they often choose a pretty meh grade kernel with performance regressions for their initial LTS release. I.e. they'll choose a 3.4.0 kernel over a very stable 3.2.latest kernel, and then patch away til the LTS becomes stable. This is especially problematic the first 6 to 12 months after an LTS release. Ubuntu support is a pitiful thing compared to RHEL support. I've reported bugs for RHEL that were fixed within weeks, or at least a workaround came out pretty quick. I've reported LTS bugs that are now YEARS old and Canonical has done NOTHING to fix them. There's a bug in 10.04LTS workstation for instance that meant you couldn't have > 1 profile for a given WAP. Never fixed. Only recommendation was to upgrade. From an LTS. sigh. There are reasons TO use Ubuntu as well. Of if you are running very late model hardware you can't get good support from an older release, and using a more recent, possibly not LTS release is a good way to get best performance. I have often installed a late model release like 11.10, to get support for odd / new / interesting / high performance hardware, and then at a later date could update that platform to an LTS release for stability. Note that I often waited til a good 3 or 4 months after the next release before I even started testing it, let alone upgrading to it. Ubuntu often has fairly late model versions of many packages like pgsql or php or whatever that more RHEL like distros will not get due to their longer release cycles. It's easier to add a ppa: repo to debian or ubuntu than to add an RPM repo to RHEL and I've found they're usually better maintained and / or more up to date. Simple answer of course is that there is no simple answer. Frequently released / updated distros (fedora, ubuntu non-LTS, debian beta and so on) are GREAT for doing initial development on, as once the stable branch based on it comes out you'll be deploying against something with a long stable release branch. So the latest version of Ruby, Perl, PHP, Python and so on are on the server, as are the latest, or nearly so, versions of pgsql and slony and other packages. Long term distros (debian stable, Ubuntu LTS, RHEL) are all good for deploying things on you don't need the latest and greatest hardware support nor the absolute fastest performance but instead stability are paramount. When downtime costs you $10k a minute, using the latest code is not always the best idea. Most importantly, if you've got LOTS of talent for one distro or another, you're probably best off exploiting it. If 95% of all the developers and ops crew run Ubuntu or Debian, stick to one of them. If they favor Fedora / RHEL stick to that. If they work on windows, find a new job if at all possible. I have zero experience of setting up Linux as a _PRODUCTION_ server. If I had to support one myself, I would probably consider RHEL. Anyhow, I would do some serious research before making a final decision. Even if I had made such a decision a year ago, I would still need to reassess the situation if I had to do it again - things keep changing. I would be very reluctant to choose an Apple or Microsoft O/S for a production server. Cheers, Gavin
Re: [GENERAL] Linux Distribution Preferences?
Em 14/01/2013 01:46, Scott Marlowe escreveu: On Sun, Jan 13, 2013 at 4:06 PM, SUNDAY A. OLUTAYO wrote: 4 reasons: 1. One place where I worked Ubuntu was standard, I tried it and found that it lacked at least a couple of desktop features in GNOME 2 that I found very useful into Fedora. Fortunately, I was allowed to revert back to Fedora. Prior to that, I was using Fedora mainly by default. 2. Twice I came across features that I liked and Ubuntu seemed to imply they had done them, later I found the projects been initiated and sponsored largely by Red Hat. Especially as Red Hat is in the top ten contributors to the kernel, and the contribution of Ubuntu is not significant. 3. Ubuntu distributions are now starting to be filled with crapware and ant-privacy features features. 4. Ubuntu seems very good at collecting fanbois. Not one of those is a good reason to avoid Ubuntu server for pgsql. There are reasons to not use it, but those are not them. I've run PostgreSQL servers on Redhat (before RHEL existed and there was JUST Redhat) 5.1, RHEL 4, 5 and 6, Debian Lenny and Squeeze, just one on an old version of Suse, and on Ubuntu server 8.04LTS and 10.04LTS and 12.04LTS. My preference personally is for debian based distros since they support the rather more elegant pg wrappers that allow you to run multiple versions and multiple clusters of those versions with very easy commands. RHEL is great for building a stable but not necessarily ultra faster server, and if you can afford their commercial support it IS top notch. Debian and Ubuntu feel much the same to me, from the command line, on a server. Do you have any fact that support RHEL being slower than others? I would like to improve our servers if we can get some ideas - so far, we have tried Ubuntu LTS servers, and seems just as fast as RHEL for PostgreSQL (tests made by issuing heavy queries). Thanks, Edson The reasons to NOT use ubuntu under PostgreSQL are primarily that 1: they often choose a pretty meh grade kernel with performance regressions for their initial LTS release. I.e. they'll choose a 3.4.0 kernel over a very stable 3.2.latest kernel, and then patch away til the LTS becomes stable. This is especially problematic the first 6 to 12 months after an LTS release. Ubuntu support is a pitiful thing compared to RHEL support. I've reported bugs for RHEL that were fixed within weeks, or at least a workaround came out pretty quick. I've reported LTS bugs that are now YEARS old and Canonical has done NOTHING to fix them. There's a bug in 10.04LTS workstation for instance that meant you couldn't have > 1 profile for a given WAP. Never fixed. Only recommendation was to upgrade. From an LTS. sigh. There are reasons TO use Ubuntu as well. Of if you are running very late model hardware you can't get good support from an older release, and using a more recent, possibly not LTS release is a good way to get best performance. I have often installed a late model release like 11.10, to get support for odd / new / interesting / high performance hardware, and then at a later date could update that platform to an LTS release for stability. Note that I often waited til a good 3 or 4 months after the next release before I even started testing it, let alone upgrading to it. Ubuntu often has fairly late model versions of many packages like pgsql or php or whatever that more RHEL like distros will not get due to their longer release cycles. It's easier to add a ppa: repo to debian or ubuntu than to add an RPM repo to RHEL and I've found they're usually better maintained and / or more up to date. Simple answer of course is that there is no simple answer. Frequently released / updated distros (fedora, ubuntu non-LTS, debian beta and so on) are GREAT for doing initial development on, as once the stable branch based on it comes out you'll be deploying against something with a long stable release branch. So the latest version of Ruby, Perl, PHP, Python and so on are on the server, as are the latest, or nearly so, versions of pgsql and slony and other packages. Long term distros (debian stable, Ubuntu LTS, RHEL) are all good for deploying things on you don't need the latest and greatest hardware support nor the absolute fastest performance but instead stability are paramount. When downtime costs you $10k a minute, using the latest code is not always the best idea. Most importantly, if you've got LOTS of talent for one distro or another, you're probably best off exploiting it. If 95% of all the developers and ops crew run Ubuntu or Debian, stick to one of them. If they favor Fedora / RHEL stick to that. If they work on windows, find a new job if at all possible. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On Sun, Jan 13, 2013 at 4:06 PM, SUNDAY A. OLUTAYO wrote: > 4 reasons: > > 1. One place where I worked Ubuntu was standard, I tried it and found > that it lacked at least a couple of desktop features in GNOME 2 that > I found very useful into Fedora. Fortunately, I was allowed to > revert back to Fedora. Prior to that, I was using Fedora mainly by > default. > > 2. Twice I came across features that I liked and Ubuntu seemed to imply > they had done them, later I found the projects been initiated and > sponsored largely by Red Hat. Especially as Red Hat is in the top > ten contributors to the kernel, and the contribution of Ubuntu is > not significant. > > 3. Ubuntu distributions are now starting to be filled with crapware and > ant-privacy features features. > > 4. Ubuntu seems very good at collecting fanbois. Not one of those is a good reason to avoid Ubuntu server for pgsql. There are reasons to not use it, but those are not them. I've run PostgreSQL servers on Redhat (before RHEL existed and there was JUST Redhat) 5.1, RHEL 4, 5 and 6, Debian Lenny and Squeeze, just one on an old version of Suse, and on Ubuntu server 8.04LTS and 10.04LTS and 12.04LTS. My preference personally is for debian based distros since they support the rather more elegant pg wrappers that allow you to run multiple versions and multiple clusters of those versions with very easy commands. RHEL is great for building a stable but not necessarily ultra faster server, and if you can afford their commercial support it IS top notch. Debian and Ubuntu feel much the same to me, from the command line, on a server. The reasons to NOT use ubuntu under PostgreSQL are primarily that 1: they often choose a pretty meh grade kernel with performance regressions for their initial LTS release. I.e. they'll choose a 3.4.0 kernel over a very stable 3.2.latest kernel, and then patch away til the LTS becomes stable. This is especially problematic the first 6 to 12 months after an LTS release. Ubuntu support is a pitiful thing compared to RHEL support. I've reported bugs for RHEL that were fixed within weeks, or at least a workaround came out pretty quick. I've reported LTS bugs that are now YEARS old and Canonical has done NOTHING to fix them. There's a bug in 10.04LTS workstation for instance that meant you couldn't have > 1 profile for a given WAP. Never fixed. Only recommendation was to upgrade. From an LTS. sigh. There are reasons TO use Ubuntu as well. Of if you are running very late model hardware you can't get good support from an older release, and using a more recent, possibly not LTS release is a good way to get best performance. I have often installed a late model release like 11.10, to get support for odd / new / interesting / high performance hardware, and then at a later date could update that platform to an LTS release for stability. Note that I often waited til a good 3 or 4 months after the next release before I even started testing it, let alone upgrading to it. Ubuntu often has fairly late model versions of many packages like pgsql or php or whatever that more RHEL like distros will not get due to their longer release cycles. It's easier to add a ppa: repo to debian or ubuntu than to add an RPM repo to RHEL and I've found they're usually better maintained and / or more up to date. Simple answer of course is that there is no simple answer. Frequently released / updated distros (fedora, ubuntu non-LTS, debian beta and so on) are GREAT for doing initial development on, as once the stable branch based on it comes out you'll be deploying against something with a long stable release branch. So the latest version of Ruby, Perl, PHP, Python and so on are on the server, as are the latest, or nearly so, versions of pgsql and slony and other packages. Long term distros (debian stable, Ubuntu LTS, RHEL) are all good for deploying things on you don't need the latest and greatest hardware support nor the absolute fastest performance but instead stability are paramount. When downtime costs you $10k a minute, using the latest code is not always the best idea. Most importantly, if you've got LOTS of talent for one distro or another, you're probably best off exploiting it. If 95% of all the developers and ops crew run Ubuntu or Debian, stick to one of them. If they favor Fedora / RHEL stick to that. If they work on windows, find a new job if at all possible. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. We run CentOS (mixture of 5 and 6, but 6 in all newer installations). I've never used Ubuntu so can't comment on it. We get PG from the PGDG repository, after disabling the distribution's PG installation in order to maintain tight control over the build/version. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
Em 13/01/2013 16:27, Shaun Thomas escreveu: Hey guys, I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email I do use CentOS 5 and 6 for servers - they run without any glitches in decent servers. Don't use then on self made servers with strange/alternative SATA Raid controlers, it is the hell on earth. Use good hardware and you will be fine. Check the HCL of RedHat Enterprise. Edson -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] INSERT... WHERE
2013/1/14 Robert James : > I have a lot of VALUES I want to INSERT. But only a subset of them - > only those that meet a JOIN criteria involving another table. > > I could INSERT them into a temp table, and then do a SELECT INTO. But > do I need to do that? Is there any way to do a INSERT... VALUES ... > WHERE... INSERT INTO ... SELECT is what you are looking for. Simple example: CREATE TABLE seltest (id INT); INSERT INTO seltest (id) SELECT 1; HTH Ian Lawrence Barwick -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] INSERT... WHERE
On Sun, Jan 13, 2013 at 7:00 PM, Robert James wrote: > I have a lot of VALUES I want to INSERT. But only a subset of them - > only those that meet a JOIN criteria involving another table. > > I could INSERT them into a temp table, and then do a SELECT INTO. But > do I need to do that? Is there any way to do a INSERT... VALUES ... > WHERE... What you're probably looking for is an insert .. select statment like so: insert into tablea (col1, col2, col3) select colx, coly, colz from tableb where somecondition; -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] special procedure required when running pg_basebackup from a standby?
Greetings, I'm running postgres-9.2.2 in a Linux-x86_64 cluster with 1 master and several hot standby servers. Since upgrading to 9.2.2 from 9.1.x a few months ago, I switched from generating a base backup on the master, to generating it on a dedicated slave/standby (to reduce the load on the master). The command that I've always used to generate the base backup is: pg_basebackup -v -D /tmp/bb0 -x -Ft -U postgres However, I've noticed that whenever I use the base backup generated from the standby to create a new standby server, many of the indexes are corrupted. This was never the case when I was generating the basebackup directly from the master. Now, I see errors similar to the following when running queries against the tables that own the indexes: INDEX "debugger_2013_01_dacode_idx" contains unexpected zero page at block 12 HINT: Please REINDEX it. INDEX "smoke32on64tests_2013_01_suiteid_idx" contains unexpected zero page at block 111 HINT: Please REINDEX it. I've confirmed that the errors/corruption doesn't exist on the server that is generating the base backup (I can run the same SQL query which fails on the new standby, successfully). Also reindexing the index does fix the problem. So it seems that I'm potentially misunderstanding some part of the process. My setup process is to simply untar the basebackup in the $PGDATA directory, and copy over all the WAL logs into $PGDATA/pg_xlog. thanks for any pointers. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Bulk INSERT with individual failure
I need to INSERT a large number of records. For performance reasons, I'd rather send them to Postgres in one giant INSERT. However, if there's a problem in one record (eg one row doesn't meet a constraint), I'd still like the others saved. That is, I specifically DO NOT want atomic behavior. It's okay to silently drop bad data in this case - I don't even need to know about it. Is there any way to do this, or am I forced to but each record into its own INSERT? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On 01/13/2013 04:07 PM, Chris Ernst wrote: On 01/13/2013 03:44 PM, Gavin Flower wrote: I've seen the opinion of "avoid Ubuntu like the plague" expressed many times, but it is never followed up with any solid reasoning. Can you (or anyone else) give specific details on exactly why you believe Ubuntu should be avoided? My take is that you have to look at Ubuntu as two distinct lines of distributions, desktop and server. I got into it for the desktop and stayed for the server. The "avoid like a plague" tag tends to apply to the desktop line and to an extent is valid. Canonical seems to be leading a parade of one on a new graphical look for the desktop. So if you use the desktop version and follow the six month release cycle you are in for a ride. You can avoid that somewhat by using a LTS desktop, but the change will come and you will have to deal. The server line on the other hand avoids the graphical desktop issue, so it tends to be less 'interesting'. If you stick with the LTS releases then it becomes even more stable. The nice part is that with PPAs you can backport newer releases of software to older LTS releases. For example and to get back on topic the Postgres PPA maintained by Martin Pitt: https://launchpad.net/~pitti/+archive/postgresql - Chris -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
Please don't top post, add your comments at the end as per the norm for this group. On 14/01/13 12:06, SUNDAY A. OLUTAYO wrote: Ubuntu did the marketing for linux and many more. Some people are just haters. Can you tell us about upstart? Sent from my LG Mobile Gavin Flower wrote: On 14/01/13 13:07, Chris Ernst wrote: On 01/13/2013 03:44 PM, Gavin Flower wrote: I would tend use Fedora for development, but would consider CentOS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. I happen to be doing my own research on this matter. I tend to lean more toward RHEL or CentOS for production servers just because there seem to be more people using it in that capacity and it seem to be easier to get solid support or advice for those. But I prefer Ubuntu for my laptop mainly because of the size of the community, available PPAs, ease of administration, etc... Ultimately, it seem to come down to what you are most familiar/comfortable managing. I don't see much practical difference between the distributions other than the versions of various software that they ship with by default. But that is usually rather easy to change according to your needs anyway. I've seen the opinion of "avoid Ubuntu like the plague" expressed many times, but it is never followed up with any solid reasoning. Can you (or anyone else) give specific details on exactly why you believe Ubuntu should be avoided? - Chris 4 reasons: 1. One place where I worked Ubuntu was standard, I tried it and found that it lacked at least a couple of desktop features in GNOME 2 that I found very useful into Fedora. Fortunately, I was allowed to revert back to Fedora. Prior to that, I was using Fedora mainly by default. 2. Twice I came across features that I liked and Ubuntu seemed to imply they had done them, later I found the projects been initiated and sponsored largely by Red Hat. Especially as Red Hat is in the top ten contributors to the kernel, and the contribution of Ubuntu is not significant. 3. Ubuntu distributions are now starting to be filled with crapware and ant-privacy features features. 4. Ubuntu seems very good at collecting fanbois. If I were to change from Fedora, I would probably go back to Debian. Cheers, Gavin I don't know much about 'upstart' - Fedora uses systemd: http://www.freedesktop.org/wiki/Software/systemd Cheers, Gavin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
Ubuntu did the marketing for linux and many more. Some people are just haters. Can you tell us about upstart? Sent from my LG Mobile Gavin Flower wrote: On 14/01/13 13:07, Chris Ernst wrote: > On 01/13/2013 03:44 PM, Gavin Flower wrote: >> I would tend use Fedora for development, but would consider CentOS (or >> RHEL, if we had the budget) for production - I avoid Ubuntu like the >> plague. > > I happen to be doing my own research on this matter. I tend to lean > more toward RHEL or CentOS for production servers just because there > seem to be more people using it in that capacity and it seem to be > easier to get solid support or advice for those. But I prefer Ubuntu > for my laptop mainly because of the size of the community, available > PPAs, ease of administration, etc... > > Ultimately, it seem to come down to what you are most > familiar/comfortable managing. I don't see much practical difference > between the distributions other than the versions of various software > that they ship with by default. But that is usually rather easy to > change according to your needs anyway. > > I've seen the opinion of "avoid Ubuntu like the plague" expressed many > times, but it is never followed up with any solid reasoning. Can you > (or anyone else) give specific details on exactly why you believe > Ubuntu should be avoided? > > - Chris > > > 4 reasons: 1. One place where I worked Ubuntu was standard, I tried it and found that it lacked at least a couple of desktop features in GNOME 2 that I found very useful into Fedora. Fortunately, I was allowed to revert back to Fedora. Prior to that, I was using Fedora mainly by default. 2. Twice I came across features that I liked and Ubuntu seemed to imply they had done them, later I found the projects been initiated and sponsored largely by Red Hat. Especially as Red Hat is in the top ten contributors to the kernel, and the contribution of Ubuntu is not significant. 3. Ubuntu distributions are now starting to be filled with crapware and ant-privacy features features. 4. Ubuntu seems very good at collecting fanbois. If I were to change from Fedora, I would probably go back to Debian. Cheers, Gavin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On 14/01/13 13:07, Chris Ernst wrote: On 01/13/2013 03:44 PM, Gavin Flower wrote: I would tend use Fedora for development, but would consider CentOS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. I happen to be doing my own research on this matter. I tend to lean more toward RHEL or CentOS for production servers just because there seem to be more people using it in that capacity and it seem to be easier to get solid support or advice for those. But I prefer Ubuntu for my laptop mainly because of the size of the community, available PPAs, ease of administration, etc... Ultimately, it seem to come down to what you are most familiar/comfortable managing. I don't see much practical difference between the distributions other than the versions of various software that they ship with by default. But that is usually rather easy to change according to your needs anyway. I've seen the opinion of "avoid Ubuntu like the plague" expressed many times, but it is never followed up with any solid reasoning. Can you (or anyone else) give specific details on exactly why you believe Ubuntu should be avoided? - Chris 4 reasons: 1. One place where I worked Ubuntu was standard, I tried it and found that it lacked at least a couple of desktop features in GNOME 2 that I found very useful into Fedora. Fortunately, I was allowed to revert back to Fedora. Prior to that, I was using Fedora mainly by default. 2. Twice I came across features that I liked and Ubuntu seemed to imply they had done them, later I found the projects been initiated and sponsored largely by Red Hat. Especially as Red Hat is in the top ten contributors to the kernel, and the contribution of Ubuntu is not significant. 3. Ubuntu distributions are now starting to be filled with crapware and ant-privacy features features. 4. Ubuntu seems very good at collecting fanbois. If I were to change from Fedora, I would probably go back to Debian. Cheers, Gavin
Re: [GENERAL] Linux Distribution Preferences?
On Jan 13, 2013, at 10:27 AM, Shaun Thomas wrote: > Hey guys, > > I'm not sure the last time I saw this discussion, but I was somewhat curious: > what would be your ideal Linux distribution for a nice solid PostgreSQL > installation? We've kinda bounced back and forth between RHEL, CentOS, and > Ubuntu LTS, so I was wondering what everyone else thought. Either would be fine. RHEL is a bit more Enterprisey - which is either good or bad, depending on your use case. They're more conservative with updates than Ubuntu - which is good for service stability, but can be painful when you're stuck between using ancient versions of some app or stepping into the minefield of third party repos. (CentOS is pretty much just RHEL without support and without some of the management tools). Ubuntu LTS is solid, and has good support for running multiple Postgresql clusters simultaneously, which is very handy if you're supporting multiple apps against the same database server, and they require different releases. I've been told that they occasionally make incompatible changes across minor releases, which is Bad, but it's never happened anywhere I've noticed - I've no idea if it's an actual issue or "Well, back in the 2004 release, they…" folklore. I run both in production, both on VMs and real metal. I tend to use Ubuntu LTS for new installations just because I'm marginally more comfortable in the Ubuntu CLI environment, but there's really not much to choose between them. Cheers, Steve -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On Mon, Jan 14, 2013 at 11:07 AM, Chris Ernst wrote: > I've seen the opinion of "avoid Ubuntu like the plague" expressed many > times, but it is never followed up with any solid reasoning. Can you (or > anyone else) give specific details on exactly why you believe Ubuntu should > be avoided? I switched from Ubuntu to Debian a while ago, mainly on account of the desktop environment, but moving servers as well for consistency. Ubuntu has its advantages. At the moment, I'm half way through patching a Debian system to the latest kernel and a recent Upstart (rather than sysvinit), but Ubuntu already comes with a fairly recent kernel and Upstart is the default. So far, I haven't seen any particular reason to detest Ubuntu or Debian. Both of them quite happily run everything I want, although once it's been a year or two since the OS release, there's a strong tendency to build stuff from source rather than rely on the aptitude repositories - the repos lag a bit. But I'm okay with that. Maybe it's an issue for other situations, though, in which case it's a recommendation for Ubuntu probably. In terms of PostgreSQL, I've always been using the OpenSCG package, and have had no problems whatsoever (9.1). ChrisA -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] VALUES() evaluation order
On Jan 13, 2013, at 2:36 PM, Tom Lane wrote:
> Steve Atkins writes:
>> Is the order in which the expressions in a VALUES() clause defined?
>> I'm doing this: INSERT INTO foo (a, b) VALUES (nextval('bar'),
>> currval('bar'))
>
>> It works fine, but I'm wondering whether it's guaranteed to work or whether
>> I'm relying on an artifact of the implementation.
>
> I'd say it's an artifact. It probably does work reliably at the moment,
> but if we had a reason to change it we'd not feel much compunction about
> doing so. (The most obvious potential reason to change it is parallel
> evaluation of expressions, which is a long way off, so you probably
> don't have any near-term reason to worry. But ...)
>
> Consider sticking the nextval() into a WITH.
Thanks. WITH it is, then.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
On 01/13/2013 03:44 PM, Gavin Flower wrote: I would tend use Fedora for development, but would consider CentOS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. I happen to be doing my own research on this matter. I tend to lean more toward RHEL or CentOS for production servers just because there seem to be more people using it in that capacity and it seem to be easier to get solid support or advice for those. But I prefer Ubuntu for my laptop mainly because of the size of the community, available PPAs, ease of administration, etc... Ultimately, it seem to come down to what you are most familiar/comfortable managing. I don't see much practical difference between the distributions other than the versions of various software that they ship with by default. But that is usually rather easy to change according to your needs anyway. I've seen the opinion of "avoid Ubuntu like the plague" expressed many times, but it is never followed up with any solid reasoning. Can you (or anyone else) give specific details on exactly why you believe Ubuntu should be avoided? - Chris -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Linux Distribution Preferences?
I use Ubuntu for development and production, it is rock solid. Thanks, Sunday Olutayo - Original Message - From: "Gavin Flower" To: "Shaun Thomas" Cc: "pgsql-general@postgresql.org" Sent: Sunday, January 13, 2013 11:44:42 PM Subject: Re: [GENERAL] Linux Distribution Preferences? On 14/01/13 07:27, Shaun Thomas wrote: Hey guys, I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email I would tend use Fedora for development, but would consider Cent OS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. Cheers, Gavin
Re: [GENERAL] Linux Distribution Preferences?
On 14/01/13 07:27, Shaun Thomas wrote: Hey guys, I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email I would tend use Fedora for development, but would consider CentOS (or RHEL, if we had the budget) for production - I avoid Ubuntu like the plague. Cheers, Gavin
Re: [GENERAL] VALUES() evaluation order
Steve Atkins writes:
> Is the order in which the expressions in a VALUES() clause defined?
> I'm doing this: INSERT INTO foo (a, b) VALUES (nextval('bar'), currval('bar'))
> It works fine, but I'm wondering whether it's guaranteed to work or whether
> I'm relying on an artifact of the implementation.
I'd say it's an artifact. It probably does work reliably at the moment,
but if we had a reason to change it we'd not feel much compunction about
doing so. (The most obvious potential reason to change it is parallel
evaluation of expressions, which is a long way off, so you probably
don't have any near-term reason to worry. But ...)
Consider sticking the nextval() into a WITH.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] VALUES() evaluation order
Is the order in which the expressions in a VALUES() clause defined?
I'm doing this: INSERT INTO foo (a, b) VALUES (nextval('bar'), currval('bar'))
It works fine, but I'm wondering whether it's guaranteed to work or whether I'm
relying on an artifact of the implementation.
Cheers,
Steve
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 9.2 upgrade glitch with search_path
On Jan 13, 2013, at 2:51 PM, Tom Lane wrote: > That's a hole in the particular dump methodology you selected: > >> pg_dumpall -g -f roles.dump >> pg_dump -F c -Z 0 -v pedcard > db.dump > > pg_dump does not dump/restore database properties, only database > contents. Properties are the responsibility of pg_dumpall, which > you bypassed (for databases anyway). > > There's been some discussion of refactoring these responsibilities, > but no consensus. Ah, this is my first upgrade using that methodology, in order to get concurrent restore functionality. Prior to this I've always used pg_dumpall. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 9.2 upgrade glitch with search_path
Scott Ribe writes: > Built & installed 9.2.3. Dumped 9.1 db (using 9.2 pg_dump IIRC). Restored. > Database search path was not restored. Had to execute alter database ... set > search_path to... That's a hole in the particular dump methodology you selected: > pg_dumpall -g -f roles.dump > pg_dump -F c -Z 0 -v pedcard > db.dump pg_dump does not dump/restore database properties, only database contents. Properties are the responsibility of pg_dumpall, which you bypassed (for databases anyway). There's been some discussion of refactoring these responsibilities, but no consensus. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_upgrade failed for 9.0 to 9.2
On Sun, Jan 13, 2013 at 02:17:34PM -0500, Vibhor Kumar wrote:
>
> On Jan 13, 2013, at 1:36 PM, AI Rumman wrote:
>
> > CREATE VIEW stats_slowest_queries AS
> >SELECT pg_stat_activity.procpid, (('now'::text)::timestamp(6) with time
> > zone - pg_stat_activity.query_start) AS execution_time,
> > pg_stat_activity.current_query FROM pg_stat_activity WHERE
> > (pg_stat_activity.current_query !~~ ' > (('now'::text)::timestamp(6) with time zone - pg_stat_activity.query_start)
> > DESC;
> > psql:pg_upgrade_dump_db.sql:498897: ERROR: column pg_stat_activity.procpid
> > does not exist
> > LINE 2: SELECT pg_stat_activity.procpid, (('now'::text)::timesta...
> > ^
> > It failed.
>
>
> Reason is: From postgreSQL 9.2 onwards, pg_stat_activity.procpid is renamed
> as pg_stat_activity.pid.
> http://www.postgresql.org/docs/9.2/interactive/release-9-2.html
Yes. Pg_upgrade doesn't know about renamed system columns, so if you
had a view that referenced a renamed column, pg_upgrade wouldn't know
about that until it tried to restore the view and it failed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] 9.2 upgrade glitch with search_path
Built & installed 9.2.3. Dumped 9.1 db (using 9.2 pg_dump IIRC). Restored. Database search path was not restored. Had to execute alter database ... set search_path to... Dump commands: pg_dumpall -g -f roles.dump pg_dump -F c -Z 0 -v pedcard > db.dump Restore commands: psql -f roles.dump postgres pg_restore -j 4 -veC -d postgres db.dump -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] pg_upgrade failed for 9.0 to 9.2
On Jan 13, 2013, at 1:36 PM, AI Rumman wrote:
> CREATE VIEW stats_slowest_queries AS
>SELECT pg_stat_activity.procpid, (('now'::text)::timestamp(6) with time
> zone - pg_stat_activity.query_start) AS execution_time,
> pg_stat_activity.current_query FROM pg_stat_activity WHERE
> (pg_stat_activity.current_query !~~ ' (('now'::text)::timestamp(6) with time zone - pg_stat_activity.query_start)
> DESC;
> psql:pg_upgrade_dump_db.sql:498897: ERROR: column pg_stat_activity.procpid
> does not exist
> LINE 2: SELECT pg_stat_activity.procpid, (('now'::text)::timesta...
> ^
> It failed.
Reason is: From postgreSQL 9.2 onwards, pg_stat_activity.procpid is renamed as
pg_stat_activity.pid.
http://www.postgresql.org/docs/9.2/interactive/release-9-2.html
Thanks & Regards,
Vibhor Kumar
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Blog:http://vibhork.blogspot.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Bug in PgAdmin 1.16.1
On Sun, 2013-01-13 at 01:49 -0200, Edson Richter wrote: > Don't know if pgAdmin maintainer keep an eye in this list, but here I go: > > - Using pgAdmin 1.16.1 in Windows 7 x64 downloaded today > > 1) You alter a role, adding any information you want: when the > properties page is open, pgAdmin automatically defines a expiration date > on 1969/12/31. > Yeah, this is a bug we need to fix. > 2) You want to remove "superuser" option from a role: when you uncheck > "superuser" box, pgAdmin alerts that removing the superuser from a role > could cause unexpected behavior, and as you to confirm the action. Once > you confirm, the "superuser" option is marked again, and nothing else > happens. > This was fixed the 24th of december. FYI, you should better send this kind of mails to the pgadmin-support list (http://www.postgresql.org/list/pgadmin-support/). -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] pg_upgrade failed for 9.0 to 9.2
Hi,
When I was upgrading database from 9.0 to 9.2 using pg_upgrade, I got the
error:
CREATE VIEW stats_slowest_queries AS
SELECT pg_stat_activity.procpid, (('now'::text)::timestamp(6) with time
zone - pg_stat_activity.query_start) AS execution_time,
pg_stat_activity.current_query FROM pg_stat_activity WHERE
(pg_stat_activity.current_query !~~ '
[GENERAL] Linux Distribution Preferences?
Hey guys, I'm not sure the last time I saw this discussion, but I was somewhat curious: what would be your ideal Linux distribution for a nice solid PostgreSQL installation? We've kinda bounced back and forth between RHEL, CentOS, and Ubuntu LTS, so I was wondering what everyone else thought. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604 312-676-8870 stho...@optionshouse.com __ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql 9.2 build error
On Sun, Jan 13, 2013 at 11:36:11AM -0500, AI Rumman wrote: > Its already installed. > I am runninf Postgresql 9.0 with uuid successfully in this server. Most likely you installed just part of the library. Not sure what OS/distribution you're using, but on debian, for example - there is distinction between library package needed for running programs, and headers for library needed for program compilation. headers are usually in package named "package-dev" or "package-devel". depesz -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] postgresql 9.2 build error
On Sun, Jan 13, 2013 at 10:18:50AM -0500, AI Rumman wrote: > I am trying to build Postgresql 9.2 > > ./configure --prefix=/usr/pgsql-9.2 --with-ossp-uuid --with-libxml > > Got the error at config.log: > > configure:9747: result: no > configure:9752: checking for uuid_export in -luuid > configure:9787: gcc -o conftest -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-stri > ct-aliasing -fwrapv -I/usr/local/include -D_GNU_SOURCE > -I/usr/include/libxml2 -L/usr/lib64 conftest.c -luuid -lxml2 -lz > -lreadline -ltermcap -lcrypt -ldl -lm >&5 > /usr/bin/ld: cannot find -luuid > collect2: ld returned 1 exit status > configure:9794: $? = 1 > > What should I do? Install uuid library. Depending on your system/distribution, the method might be different, but generally you do it using yum/pacman/apt-get - something like this. Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] postgresql 9.2 build error
I am trying to build Postgresql 9.2 ./configure --prefix=/usr/pgsql-9.2 --with-ossp-uuid --with-libxml Got the error at config.log: configure:9747: result: no configure:9752: checking for uuid_export in -luuid configure:9787: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-stri ct-aliasing -fwrapv -I/usr/local/include -D_GNU_SOURCE -I/usr/include/libxml2 -L/usr/lib64 conftest.c -luuid -lxml2 -lz -lreadline -ltermcap -lcrypt -ldl -lm >&5 /usr/bin/ld: cannot find -luuid collect2: ld returned 1 exit status configure:9794: $? = 1 What should I do?
