[GENERAL] plpython3 package absent in 9.5 repository
I don't know the policy of package inclusion in the repositories. The plpython3 package exists in the Fedora repository: http://mirror.globo.com/fedora/linux/updates/22/x86_64/p/ But it does not exist in the Postgresql repository: https://download.postgresql.org/pub/repos/yum/9.5/fedora/fedora-22-x86_64/ Or as source: https://download.postgresql.org/pub/repos/yum/srpms/9.5/fedora/fedora-22-x86_64/ Where to get the plpython3 packages for 9.5? Regards, Clodoaldo
[GENERAL] Not signed yum repository packages
Trying to upgrade 9.4 and 9.5 in Fedora 22: # dnf upgrade ... Error: Package postgresql94-9.4.7-1PGDG.f22.x86_64.rpm is not signed Regards, Clodoaldo
[GENERAL] Pass a URI as a pgAdmin parameter
I can connect to Heroku with psql passing a URI as generated by http://api.postgression.com: $ psql postgres://hcnkrxukvhqiww:lryfxzcmlboytgtxpsvla8h...@ec2-107-21-93-97.compute-1.amazonaws.com:5432/dearu2qcqcmi7t I want to do the same with pgAdmin: $ pgadmin3 -qc postgres://hcnkrxukvhqiww:lryfxzcmlboytgtxpsvla8h...@ec2-107-21-93-97.compute-1.amazonaws.com:5432/dearu2qcqcmi7t but I get the error message: Unknown token in connection string: Is it possible to pass a URI as parameter to pgAdmin? Fedora 21, pgadmin3_94.x86_64 1.20.0-2.f21 from pgdg-94-fedora.repo Regards, Clodoaldo
[GENERAL] Changing the function used in an index.
How does the planner know that the function used in an index has changed? If the function's body is changed keeping the argument and return types the planner will not use it anymore: create table t (i integer); insert into t (i) select generate_series(1, 10); analyze t; A simple function to return the opposite integer: create or replace function f(i integer) returns integer as $$ select i * -1; $$ immutable language sql; And the index on it: create index t_i_index on t(f(i)); The index is used: explain select * from t order by f(i); QUERY PLAN --- Index Scan using t_i_index on t (cost=0.00..3300.26 rows=10 width=4) Now the function is changed to return the integer itself: create or replace function f(i integer) returns integer as $$ select i; $$ immutable language sql; And the index is not used anymore: explain select * from t order by f(i); QUERY PLAN --- Sort (cost=6.32..11366.32 rows=10 width=4) Sort Key: i -> Seq Scan on t (cost=0.00..1443.00 rows=10 width=4) If the index is rebuilt reindex index t_i_index; It is used again: explain select * from t order by f(i); QUERY PLAN --- Index Scan using t_i_index on t (cost=0.00..4376.26 rows=10 width=4) Regards, Clodoaldo
[GENERAL] Failed dependencies for Pgadmin4 Web in Centos 7
Trying to install Pgadmin4 Web in Centos7: # yum list installed pgadmin4\* Loaded plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * base: mirror.linuxfix.com * epel: mirror.sjc02.svwh.net * extras: centos.mirror.ndchost.com * updates: centos.mirror.ndchost.com 34 packages excluded due to repository priority protections Installed Packages pgadmin4-python-beautifulsoup4.noarch 4.5.1-2.rhel7 @pgdg96 pgadmin4-python-fixtures.noarch 3.0.0-4.rhel7 @pgdg96 pgadmin4-python-flask-principal.noarch 0.4.0-13.rhel7 @pgdg96 pgadmin4-python-itsdangerous.noarch 0.24-9.rhel7 @pgdg96 # yum install pgadmin4-v1-web ... --> Finished Dependency Resolution Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-beautifulsoup4 >= 4.4.1 Available: python-beautifulsoup4-4.3.2-1.el7.noarch (epel) python-beautifulsoup4 = 4.3.2-1.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-flask-principal >= 0.4.0 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-dateutil >= 2.5.0 Available: python-dateutil-1.5-7.el7.noarch (base) python-dateutil = 1.5-7.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-fixtures >= 2.0.0 Available: python-fixtures-0.3.14-3.el7.noarch (epel) python-fixtures = 0.3.14-3.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-mimeparse >= 1.5.1 Available: python-mimeparse-0.1.4-2.el7.noarch (epel) python-mimeparse = 0.1.4-2.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-itsdangerous >= 0.24 Installing: python-itsdangerous-0.23-2.el7.noarch (extras) python-itsdangerous = 0.23-2.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-flask-security >= 1.7.5 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-itsdangerous >= 0.24 Available: python-itsdangerous-0.23-2.el7.noarch (extras) python-itsdangerous = 0.23-2.el7 Error: Package: pgadmin4-v1-web-1.4-1.rhel7.noarch (pgdg96) Requires: python-flask-wtf >= 0.12 Available: python-flask-wtf-0.8-3.el7.noarch (epel) python-flask-wtf = 0.8-3.el7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Regards, Clodoaldo
Re: [GENERAL] Failed dependencies for Pgadmin4 Web in Centos 7
On Mon, Apr 24, 2017 at 11:15 AM, Adrian Klaver wrote: > On 04/24/2017 05:06 AM, Clodoaldo Neto wrote: > Please reply to list also > Ccing list > > On Sun, Apr 23, 2017 at 4:58 PM, Adrian Klaver >> mailto:adrian.kla...@aklaver.com>> wrote: >> > > >> I disabled the priorities plugin and got no excluded packages but still >> the same failed dependencies. >> >> >> Installed Packages >> pgadmin4-python-beautifulsoup4.noarch >> 4.5.1-2.rhel7 @pgdg96 >> pgadmin4-python-fixtures.noarch >> 3.0.0-4.rhel7 @pgdg96 >> pgadmin4-python-flask-principal.noarch >> 0.4.0-13.rhel7 @pgdg96 >> pgadmin4-python-itsdangerous.noarch >> 0.24-9.rhel7 @pgdg96 >> >> # yum install pgadmin4-v1-web >> >> >> Do you have the PGDG repos installed on your machine?: >> >> https://www.postgresql.org/download/linux/redhat/ >> <https://www.postgresql.org/download/linux/redhat/> >> >> Or did you install the pgadmin4* packages above directly? >> >> >> I have the pgdg-96 repo installed. >> >> The first problem is that the four packages above have the "pgadmin4" >> string prefixed to their names whereas the spec file aks for the name >> without the prefix like in "pgadmin4-python-fixtures" vs >> "python-fixtures". >> > > To be clear I am not a Yum/RPM expert. > > Where is the spec file coming from? > > >From the pgadmin4-v1-web package: https://yum.postgresql.org/srpms/9.6/redhat/rhel-7-x86_64/pgadmin4-v1-1.4-1.rhel7.src.rpm > >> The second problem is that the other packages do not exist in pgdg-96 in >> either form. >> > > Looks to me they do: > > https://yum.postgresql.org/9.6/redhat/rhel-7-x86_64/ > > Missing packages: python-dateutil, python-mimeparse, python-flask-security, python-flask-wtf Clodoaldo > >> IMHO prefixing the package names with "pgadmin4" just adds confusion as >> there will be different packages installing the same file names in the >> same places. The different repo sources can be managed with priorities >> if necessary. >> >> Clodoaldo >> >> > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
[GENERAL] Failed DNF dependency in Fedora
While installing Psycopg2 for Python2 in Fedora 26 having Postgresql 9.6: # dnf install python-psycopg2 Last metadata expiration check: 0:01:52 ago on Sat 15 Jul 2017 08:30:26 AM -03. Error: Problem: conflicting requests - nothing provides postgresql94-libs needed by python-psycopg2-2.7.1-1.f26.x86_64 Psycopg2 for Python3 installs cleanly. Regards, Clodoaldo Pinto Neto
Re: [GENERAL] Failed DNF dependency in Fedora
It is fixed now. Thanks! Clodoaldo On Sun, Jul 16, 2017 at 8:39 AM, Devrim Gündüz wrote: > > Hi Clodoaldo, > > On Sat, 2017-07-15 at 08:38 -0300, Clodoaldo Neto wrote: > > While installing Psycopg2 for Python2 in Fedora 26 having Postgresql 9.6: > > > > # dnf install python-psycopg2 > > Last metadata expiration check: 0:01:52 ago on Sat 15 Jul 2017 08:30:26 > AM > > -03. > > Error: > > Problem: conflicting requests > > - nothing provides postgresql94-libs needed by > > python-psycopg2-2.7.1-1.f26.x86_64 > > > > Psycopg2 for Python3 installs cleanly. > > Ouch. I just replaced the packages in the repo. They will sync in next 45 > mins. > Can you please try again, after cleaning the metadata? > > dnf clean metadata > dnf install python-psycopg2 > > Thanks! > > Regards, > > -- > Devrim Gündüz > EnterpriseDB: https://www.enterprisedb.com > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > Twitter: @DevrimGunduz , @DevrimGunduzTR >
[GENERAL] Fedora 25 packages not signed
When upgrading from https://download.postgresql.org/pub/repos/yum/10/fedora/ # dnf upgrade ... Error: Package postgresql10-10.1-1PGDG.f25.x86_64.rpm is not signed Regards, Clodoaldo
[GENERAL] Missing 8.2.14 source rpms
Sorry if it is already known but just to be sure the 8.2.14 source rpms are missing from the yum repository. Regards, Clodoaldo -- 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] Missing 8.2.14 source rpms
2009/9/12 Devrim GÜNDÜZ : > On Sat, 2009-09-12 at 12:22 -0300, Clodoaldo Neto wrote: > >> Sorry if it is already known but just to be sure the 8.2.14 source >> rpms are missing from the yum repository. > > Because of bandwith issues on the master RPM build server, srpms are > uploaded a few days after the binary packages are uploaded. > > Nowadays I am still working on the repository -- pushing new packages > while the servers are hot. So, you will probably find SRPMs on Monday. That is good for me. Thanks. Clodoaldo. > > OTOH, anyone can build SRPMs on their machines. Here is a quick quide: > > svn co https://projects.commandprompt.com/public/pgcore/repo/ > cd rpm/redhat/$PG_VERSION/$PACKAGE_NAME/$DISTROVER > make srpm > > (or make build for srpm+rpm) > > You can edit .spec file and build your custom package with this way) > > -HTH. > > Regards, > -- > Devrim GÜNDÜZ, RHCE > Command Prompt - http://www.CommandPrompt.com > devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org > -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] MD5 sum mismatch in source rpm
I can't install the 8.2.14 or 8.4.1 source rpms: # rpm -Uhv postgresql-8.2.14-1PGDG.f11.src.rpm warning: postgresql-8.2.14-1PGDG.f11.src.rpm: Header V4 DSA signature: NOKEY, key ID 442df0f8 1:postgresql warning: user devrim does not exist - using root warning: group devrim does not exist - using root ### [100%] error: unpacking of archive failed on file /root/rpmbuild/SOURCES/Makefile.regress;4ab40ac6: cpio: MD5 sum mismatch Tried from three mirrors. I know from a previous email that I should build the source rpms myself but just in case it matters. Regards, Clodoaldo -- 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] MD5 sum mismatch in source rpm
2009/9/18 Devrim GÜNDÜZ : > Hi Clodoaldo, > > On Fri, 2009-09-18 at 19:42 -0300, Clodoaldo Neto wrote: >> >> # rpm -Uhv postgresql-8.2.14-1PGDG.f11.src.rpm >> warning: postgresql-8.2.14-1PGDG.f11.src.rpm: Header V4 DSA signature: >> NOKEY, key ID 442df0f8 >>1:postgresql warning: user devrim does not exist - >> using root >> warning: group devrim does not exist - using root >> ### [100%] >> error: unpacking of archive failed on file >> /root/rpmbuild/SOURCES/Makefile.regress;4ab40ac6: cpio: MD5 sum >> mismatch >> >> Tried from three mirrors. I know from a previous email that I should >> build the source rpms myself but just in case it matters. > > Could you please download this one and re-test? > > http://yum.pgsqlrpms.org/srpms/8.2/fedora/fedora-11-i386/postgresql-8.2.14-1PGDG.f11.src.rpm > > I tested that SRPM on my local server, and : > > $ rpm -Uvh postgresql-8.2.14-1PGDG.f11.src.rpm > 1:postgresql ### [100%] > > If the SRPM above works for you, I will re-upload srpms to PostgreSQL > FTP directory. Also, you can verify the package with the following sum: > > $ sha1sum postgresql-8.2.14-1PGDG.f11.src.rpm > b5b48eca92da041abcbb879225badb8de1b85edf postgresql-8.2.14-1PGDG.f11.src.rpm > Although I have already built some srpms I was just following recipes and I never really tried to understand what I was doing so it is probably my mistake. This time I was trying to install the f11 srpm (the only one I found in the mirrors) in f8 and got the above error. Installing the f11 srpm in f10 works as also works installing the f8 srpm in f8. So the srpm in the mirrors is not corrupted. Sorry for the noise. Clodoaldo > Regards, > -- > Devrim GÜNDÜZ, RHCE > Command Prompt - http://www.CommandPrompt.com > devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org > -- 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 unrecognized configuration parameter “unix_socket_directory”
I'm trying to upgrade Postgresql from 9.2 to 9.3 in Fedora 18 using this command as the postgres user $ pg_upgrade -b /bin -B /usr/pgsql-9.3/bin -d /var/lib/pgsql/data -D /var/lib/pgsql/9.3/data/ -j 2 -u postgres The error in the log: command: "/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_server.log" 2>&1 waiting for server to startFATAL: unrecognized configuration parameter "unix_socket_directory" stopped waiting pg_ctl: could not start server That parameter was replaced by unix_socket_directories (plural) in 9.3. But the server version being started is 9.2: $ /bin/pg_ctl --version pg_ctl (PostgreSQL) 9.2.4 What am I missing? Regards, Clodoaldo
[GENERAL] Re: pg_upgrade unrecognized configuration parameter “unix_socket_directory”
Someone claims to have fixed it patching pg_upgrade: http://dba.stackexchange.com/a/50714/6978 Quoting: *"My solution is to rebuild the pg_upgrade from sources, with update to file contrib/pg_upgrade/server.c:199 where pg_upgrade checks for server version:* * * *199: (GET_MAJOR_VERSION(cluster->major_version) < 903) ?* *, in my case i change it to:* *199: (GET_MAJOR_VERSION(cluster->major_version) < 900) **?*" Clodoaldo 2013/9/18 Clodoaldo Neto > I'm trying to upgrade Postgresql from 9.2 to 9.3 in Fedora 18 using this > command as the postgres user > > $ pg_upgrade -b /bin -B /usr/pgsql-9.3/bin -d /var/lib/pgsql/data -D > /var/lib/pgsql/9.3/data/ -j 2 -u postgres > > The error in the log: > > command: "/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D > "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c > unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" > start >> "pg_upgrade_server.log" 2>&1 > waiting for server to startFATAL: unrecognized configuration > parameter "unix_socket_directory" > stopped waiting > pg_ctl: could not start server > > That parameter was replaced by unix_socket_directories (plural) in 9.3. > But the server version being started is 9.2: > > $ /bin/pg_ctl --version > pg_ctl (PostgreSQL) 9.2.4 > > What am I missing? > > Regards, Clodoaldo >
[GENERAL] Error: operator does not exist: integer = integer
postgresql.x86_64 8.3.14-1PGDG.rhel5 postgresql-server.x86_64 8.3.14-1PGDG.rhel5 ERROR: operator does not exist: integer = integer LINE 3:inner join vendedor as v on a.vendedor_id = v.id ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. Any ideas? Regards, Clodoaldo
Re: [GENERAL] Error: operator does not exist: integer = integer
2011/8/1 Clodoaldo Neto > postgresql.x86_64 8.3.14-1PGDG.rhel5 > postgresql-server.x86_64 8.3.14-1PGDG.rhel5 > > ERROR: operator does not exist: integer = integer > LINE 3:inner join vendedor as v on a.vendedor_id = v.id > ^ > HINT: No operator matches the given name and argument type(s). You might > need to add explicit type casts. > > Restarting the server fixes the error. Clodoaldo > Any ideas? > > Regards, Clodoaldo > >
[GENERAL] dblink.sql not found
I have postgresql91-contrib installed in Centos 6: # yum list installed postgresql91-contrib ... Installed Packages postgresql91-contrib.x86_64 9.1.4-1PGDG.rhel6 @pgdg91 But when I try to use it I get the error: ERROR: function dblink(text, text) does not exist LINE 2: from dblink( ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. Also I can't find dblink.sql: # find / -name dblink.sql What am I missing? Regards, Clodoaldo
Re: [GENERAL] dblink.sql not found
2012/6/11 Vibhor Kumar > > On Jun 11, 2012, at 11:17 AM, Clodoaldo Neto wrote: > > > I have postgresql91-contrib installed in Centos 6: > > > > # yum list installed postgresql91-contrib > > ... > > Installed Packages > > postgresql91-contrib.x86_64 9.1.4-1PGDG.rhel6 @pgdg91 > > > > But when I try to use it I get the error: > > > > ERROR: function dblink(text, text) does not exist > > LINE 2: from dblink( > > ^ > > HINT: No function matches the given name and argument types. You might > need to add explicit type casts. > > > > Also I can't find dblink.sql: > > > > # find / -name dblink.sql > > > > What am I missing? > > > > Regards, Clodoaldo > > After installing the contrib module you have to execute following command > in Database: > CREATE EXTENSION dblink; > > That worked! Thank You, Clodoaldo > Thanks & Regards, > Vibhor Kumar > EnterpriseDB Corporation > The Enterprise PostgreSQL Company > Blog: http://vibhork.blogspot.com > >
[GENERAL] Disk file effects of delete and vacuum
I have a very frequently updated table with 240 million rows (and growing). Every three hours 1.5 million rows are inserted and 1.5 million are deleted. When I moved the cluster to a SSD this bulk insert (using copy) time was cut from 22 minutes to 2.3 minutes. The deletion time was also improved. I plan to make this bulk update every two hours or every hour. Although the performance now (after SSD) is compatible with a more frequent update I have read some horror stories about SSD death due to limited NAND endurance combined with write amplification. As SSDs are expensive I would like to push its death as far into the future as possible. Hence my question: What really happens to the disk file in a delete and subsequent vacuum? I guess there are two disk writes, one to mark the row as deleted and the other when vacuuming to mark it as available to overwrite. If instead of deleting and vacuuming I partition the table creating and dropping tables at each bulk insert/delete would I be minimizing the SSD wearing? Regards, Clodoaldo
Re: [GENERAL] Constant value for a partitioned table query inside a plpgsql function
Em 26 de fevereiro de 2012 12:45, Clodoaldo Neto < clodoaldo.pinto.n...@gmail.com> escreveu: > When I explain a query using a partitioned table the result is the > expected. That is, only the corrected partition is scanned. But when the > query is inside a plpgsql function it takes forever to complete suggesting > it is scanning all partitions. > > create table p (c integer); > create table p1 (like p); > alter table p1 add constraint p1c check (c = 1); > create table p2 (like p); > alter table p2 add constraint p2c check (c = 2); > insert into p1 values (1); > insert into p2 values (2); > alter table p1 inherit p; > alter table p2 inherit p; > > The explain shows the expected plan and the select is also very fast: > (obviously the real query and table are more complex) > > explain select c from p where c = 1; > > A function like this takes very long to complete: > > create or replace function pf() returns integer as > $body$ > declare > v constant integer := 1; > begin > return (select c from p where c = v); > end > $body$ > language plpgsql stable > cost 100; > > Isn't the "constant" option to a variable declaration enough to the > planner? Or else what is the limitation here? Is there some way to see the > plan for a plpgsql function? > > It seems that the only solution is to make the query dynamic: create or replace function pf() returns integer as $body$ declare v constant integer := 1; r integer; begin execute 'select c from p where c = $1' into r using v; return r; end $body$ language plpgsql stable cost 100; Using the dynamic solution the actual function executes very fast. Clodoaldo
[GENERAL] psql: invalid connection option "client_encoding"
I have both 9.0 and 9.1 installed in Centos 6: postgresql90.x86_64 9.0.7-1PGDG.rhel6 @pgdg90 postgresql90-docs.x86_64 9.0.7-1PGDG.rhel6 @pgdg90 postgresql90-libs.x86_64 9.0.7-1PGDG.rhel6 @pgdg90 postgresql90-odbc.x86_64 09.00.0310-1PGDG.rhel6 @pgdg90 postgresql90-plpython.x86_64 9.0.7-1PGDG.rhel6 @pgdg90 postgresql90-server.x86_649.0.7-1PGDG.rhel6 @pgdg90 postgresql91.x86_64 9.1.3-1PGDG.rhel6 @pgdg91 postgresql91-libs.x86_64 9.1.3-1PGDG.rhel6 @pgdg91 postgresql91-plpython.x86_64 9.1.3-1PGDG.rhel6 @pgdg91 postgresql91-server.x86_649.1.3-1PGDG.rhel6 @pgdg91 There is this thread: http://archives.postgresql.org/pgsql-admin/2011-09/msg00101.php My ldconfig output is a bit different: $ ldconfig -p | grep pq libpqwalreceiver.so (libc6,x86-64) => /usr/pgsql-9.0/lib/libpqwalreceiver.so libpqwalreceiver.so (libc6,x86-64) => /usr/pgsql-9.1/lib/libpqwalreceiver.so libpq.so.5 (libc6,x86-64) => /usr/pgsql-9.0/lib/libpq.so.5 libpq.so.5 (libc6,x86-64) => /usr/pgsql-9.1/lib/libpq.so.5 libipq.so.0 (libc6,x86-64) => /lib64/libipq.so.0 Is there a clean solution to have both versions working? Regards, Clodoaldo
[GENERAL] Error installing plpythonu in 9.1
template1=# create extension plpythonu; ERROR: could not open extension control file "/usr/pgsql-9.1/share/extension/plpythonu.control": No such file or directory The package is installed: postgresql91-plpython.x86_64 9.1.3-1PGDG.rhel6@pgdg91 # ll /usr/pgsql-9.1/share/extension/ total 12 -rw-r--r--. 1 root root 332 Feb 25 00:15 plpgsql--1.0.sql -rw-r--r--. 1 root root 179 Feb 25 00:15 plpgsql.control -rw-r--r--. 1 root root 381 Feb 25 00:15 plpgsql--unpackaged--1.0.sql Regards, Clodoaldo
Re: [GENERAL] Error installing plpythonu in 9.1
Em 28 de fevereiro de 2012 17:48, Devrim GÜNDÜZ escreveu: > > Hi, > > On Tue, 2012-02-28 at 17:39 -0300, Clodoaldo Neto wrote: > > template1=# create extension plpythonu; > > ERROR: could not open extension control file > > "/usr/pgsql-9.1/share/extension/plpythonu.control": No such file or > > directory > > This is a packaging bug :-( > > That file is installed with -contrib subpackage. Please install -contrib > package until I push the new set of RPMs. > > Very easy. Thanks. Clodoaldo > Created http://wiki.pgrpms.org/ticket/76 if you want to keep track of > the bug. > > Regards, > -- > Devrim GÜNDÜZ > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz >
Re: [GENERAL] Error installing postgresq91-python package
Em 28 de fevereiro de 2012 17:54, Devrim GÜNDÜZ escreveu: > > Hi, > > On Tue, 2012-02-28 at 10:33 -0300, Clodoaldo Neto wrote: > > > > > Transaction Check Error: > > file /usr/lib64/python2.6/site-packages/_pg.so from install of > > postgresql91-python-0:4.0-2PGDG.rhel6.x86_64 conflicts with file from > > package PyGreSQL-3.8.1-2.el6.x86_64 > > > What is unusual here? I'd probably add a Conflicts: line, so that the > error would appear before the installation. Is that what you want? > > Not sure. It was just in case you had already done something like that and didn't know it was not working. Clodoaldo > Regards, > -- > Devrim GÜNDÜZ > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz >
[GENERAL] Client encoding not the same as the db encoding
In 9.1.3 the client encoding is not defaulting to the db encoding: postgresql.conf: #client_encoding = sql_ascii => show server_encoding; server_encoding - SQL_ASCII => show client_encoding; client_encoding - UTF8 In 9.0 the client encoding defaults to the db encoding: postgresql.conf: #client_encoding = sql_ascii => show client_encoding; client_encoding - SQL_ASCII => show server_encoding; server_encoding - SQL_ASCII What am i missing? Regards, Clodoaldo
[GENERAL] Non inheritable check constraint
I have gone through the issue of making a parent table not writable. After discussing it (1) I adopted the trigger solution. But I think that a trigger is just an invisible layer over the database model and so I'm naively proposing a new syntax to postgresql. It would inform that the check constraint is not inheritable: create table t (c integer check NOT INHERITABLE (false)); I found a model visible solution but it only prevents non null values from being inserted. Or only prevents all inserts if that column is not null: create table tfk (c integer unique check(false)); create table t (c integer, foreign key (c) references tfk(c)); Regards, Clodoaldo (1) http://stackoverflow.com/questions/9545783/how-to-prevent-inserts-in-a-table
Re: [GENERAL] [Pgbouncer-general] PGBouncer help (how to get it working)
Em 12 de abril de 2012 14:12, Phoenix Kiula escreveu: > I had pgbouncer working somehow, but we have switched servers recently > and now I cannot for the life of me figure out again how to set it up. > > Online guides say things like "create a user ID". Well, where? Inside > PG the database? Or in my CentOS system? > > Here's my "/etc/pgbouncer.ini": > >[databases] >* = port = 5432 > >[pgbouncer] >listen_port = 6543 >listen_addr = 127.0.0.1 >auth_type = trust >auth_file = /var/lib/pgsql/pgbouncer.txt >logfile = pgbouncer.log >pidfile = pgbouncer.pid >admin_users = postgres,MYSITE_pgbouncer >pool_mode = transaction >server_reset_query = DISCARD ALL; >server_check_query = select 1 >server_check_delay = 10 >max_client_conn = 1000 >default_pool_size = 20 >log_connections = 0 >log_disconnections = 0 >log_pooler_errors = 1 > > > And here's my authfile, "/var/lib/pgsql/pgbouncer.txt" -- > >"MYSITE_pgbouncer" "" > > Is there something else I need to do? What steps am I missing? When I > start pgbouncer at the command line, I see this error: > > WARNING: password file "/root/.pgpass" has group or world access; > permissions should be u=rw (0600) or less > psql: ERROR: No such user: MYSITE_pgbouncer > > I had this error in the pgbouncer log file after updating to the last version, 1.5, in Centos 6. For me the fix was to set the ownership of the auth_file to pgbouncer. In the previous version, 1.4, it was working with postgres as the owner of that file. Regards, Clodoaldo > Thanks for any tips! > ___ > Pgbouncer-general mailing list > pgbouncer-gene...@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/pgbouncer-general >
Re: [GENERAL] [Pgbouncer-general] PGBouncer help (how to get it working)
Em 14 de abril de 2012 09:39, raghu ram escreveu: > > > On Sat, Apr 14, 2012 at 4:31 PM, Clodoaldo Neto < > clodoaldo.pinto.n...@gmail.com> wrote: > >> Em 12 de abril de 2012 14:12, Phoenix Kiula >> escreveu: >> >>> I had pgbouncer working somehow, but we have switched servers recently >>> and now I cannot for the life of me figure out again how to set it up. >>> >>> Online guides say things like "create a user ID". Well, where? Inside >>> PG the database? Or in my CentOS system? >>> >>> Here's my "/etc/pgbouncer.ini": >>> >>>[databases] >>>* = port = 5432 >>> >>>[pgbouncer] >>>listen_port = 6543 >>>listen_addr = 127.0.0.1 >>>auth_type = trust >>>auth_file = /var/lib/pgsql/pgbouncer.txt >>>logfile = pgbouncer.log >>>pidfile = pgbouncer.pid >>>admin_users = postgres,MYSITE_pgbouncer >>>pool_mode = transaction >>>server_reset_query = DISCARD ALL; >>>server_check_query = select 1 >>>server_check_delay = 10 >>>max_client_conn = 1000 >>>default_pool_size = 20 >>>log_connections = 0 >>>log_disconnections = 0 >>>log_pooler_errors = 1 >>> >>> >>> And here's my authfile, "/var/lib/pgsql/pgbouncer.txt" -- >>> >>>"MYSITE_pgbouncer" "" >>> >>> Is there something else I need to do? What steps am I missing? When I >>> start pgbouncer at the command line, I see this error: >>> >>> WARNING: password file "/root/.pgpass" has group or world access; >>> permissions should be u=rw (0600) or less >>> psql: ERROR: No such user: MYSITE_pgbouncer >>> >>> >> I had this error in the pgbouncer log file after updating to the last >> version, 1.5, in Centos 6. For me the fix was to set the ownership of the >> auth_file to pgbouncer. In the previous version, 1.4, it was working with >> postgres as the owner of that file. >> >> Regards, Clodoaldo >> > > Could you please share stats_users information in pgbouncer.ini file ? > > That is the default: stats_users = stats, root Clodoaldo > -- > > Thanks & Regards, > > Raghu Ram > > EnterpriseDB: http://www.enterprisedb.com > >
Re: [GENERAL] Non inheritable check constraint
2012/3/5 Clodoaldo Neto > I have gone through the issue of making a parent table not writable. After > discussing it (1) I adopted the trigger solution. But I think that a > trigger is just an invisible layer over the database model and so I'm > naively proposing a new syntax to postgresql. It would inform that the > check constraint is not inheritable: > > create table t (c integer check NOT INHERITABLE (false)); > > It will be in 9.2: - Allow CHECK constraints to be declared NO INHERIT (Nikhil Sontakke, Alex Hunsaker) This makes them enforceable only on the parent table, not on child tables. I don't know if it was already there when I asked but ! Thank You ! Clodoaldo I found a model visible solution but it only prevents non null values from > being inserted. Or only prevents all inserts if that column is not null: > > create table tfk (c integer unique check(false)); > create table t (c integer, foreign key (c) references tfk(c)); > > Regards, Clodoaldo > > (1) > http://stackoverflow.com/questions/9545783/how-to-prevent-inserts-in-a-table >
