Re: [GENERAL] Because PostgreSQL is compiling in old versions of OS?
Oh!! Jose Maria TJ wrote > You're wrong, that are gcc versions, not OS versions. > > For example in my CentOS 6 Box > > cat /etc/redhat-release > CentOS release 6.9 (Final) > > gcc -v > [...trimmed...] > gcc versión 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) You're right!. Is the GGC version, not the OS version Great! I think that I compiling in a GGC 4.X version is good for most SO distribution right? Thanks! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Because PostgreSQL is compiling in old versions of OS?
Hi everyone! I want to develop a installer for many purposes, but i have a question, when I review the currently PostgreSQL versions, I see Ubuntu 5 or RHEL 4 , when currently we have Ubuntu 16 or RHEL 7. for example: /PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit PostgreSQL 9.6.5 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit/ This is a standard, convention or is for compatibility? Which the best OS version to complining with the goal to build binaries "standard" o "more compatible"? Thanks for your help! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html -- 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] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
You're right I have forgotten to say, the OS is RHEL 7. Actually I'm reading about. Thanks! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923p5969564.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] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
> Do you control the app? Nop Just I know how it's developed. > The app has a pooling component and you still are having problems, have > you looked at what the pooler is actually doing? As far as I know, the wildfly's jdbc pool. No really I don't know what are doing. I suspect that problem is that in DAO's not are closing the sessions or not beginning transactions properly. I going to ask them send me the logfile or I'll could verify the pool behavior. > Not sure what the above means. Are you saying the application you refer > to above has a history of not correctly closing connections or are you > talking in general terms about applications interacting with databases. Sorry, it's not like that, just was a comment, The problem I have is with a specific application. > I've attached two files that may be helpful to you. Melvin , Thanks for the scripts! I owe one! I have another question, I've was reading about the lock_timeout, Somehow this parameter will help or could affect all the behaviour? Thanks! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923p5969552.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] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
To expand information, the application are written in Grails on wildfly with pool connections. I didn't have time to check pg_locks with detail, I'll configure the connections logs to monitoring those. I can't close connections on the application side. How I close connections on the database side? With pg_terminate_backend, pg_cancel_backend or exists other function? I didn't want terminate backends because all connections state was active. I refer only to "idle" because almost in every database that I've saw the application doesn't close correctly the connections. If are "idle in transaction" is not normal. Your right Adrian, I need to know why the connections are not closing properly. I can't apply idle_in_transation_session_timeout because the version of PostgreSQL is 9.4.4 and the paramater not yet i'ts included. But sounds good the upgrade. Thanks for your help! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923p5969262.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] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
Yep, the real problem was all connections are used up. A ps command showed this: postgres 1172 23340 1 13:00 ?00:01:23 postgres: dbsomething dbsomething 8.8.8.1[34024] PARSE waiting postgres 1527 23340 3 13:07 ?00:02:47 postgres: dbsomething dbsomething 8.8.8.2[49193] PARSE waiting postgres 1869 23340 1 13:13 ?00:01:05 postgres: dbsomething dbsomething 8.8.8.1[34209] PARSE waiting postgres 1963 23340 0 13:15 ?00:00:23 postgres: dbsomething dbsomething 8.8.8.1[34244] PARSE waiting postgres 2408 23340 2 13:23 ?00:01:31 postgres: dbsomething dbsomething 8.8.8.3[38324] PARSE waiting postgres 2442 23340 3 13:23 ?00:02:19 postgres: dbsomething dbsomething 8.8.8.3[38359] PARSE waiting postgres 2526 23340 2 13:25 ?00:01:39 postgres: dbsomething dbsomething 8.8.8.2[49994] PARSE waiting postgres 2533 23340 2 13:25 ?00:02:00 postgres: dbsomething dbsomething 8.8.8.4[58916] PARSE waiting postgres 2616 23340 2 13:26 ?00:01:28 postgres: dbsomething dbsomething 8.8.8.3[38496] PARSE waiting postgres 2632 23340 3 13:27 ?00:02:09 postgres: dbsomething dbsomething 8.8.8.2[50088] idle in transaction postgres 2644 23340 0 13:27 ?00:00:25 postgres: dbsomething dbsomething 8.8.8.4[58999] PARSE waiting postgres 2787 23340 0 13:30 ?00:00:16 postgres: dbsomething dbsomething 8.8.8.5[57944] PARSE waiting postgres 2815 23340 1 13:31 ?00:00:52 postgres: dbsomething dbsomething 8.8.8.2[50263] PARSE waiting postgres 2822 23340 0 13:31 ?00:00:29 postgres: dbsomething dbsomething 8.8.8.4[59158] PARSE waiting postgres 2825 23340 1 13:31 ?00:00:47 postgres: dbsomething dbsomething 8.8.8.4[59161] PARSE waiting postgres 2826 23340 0 13:31 ?00:00:11 postgres: dbsomething dbsomething 8.8.8.4[59163] PARSE waiting postgres 2876 23340 0 13:32 ?00:00:26 postgres: dbsomething dbsomething 8.8.8.1[34469] PARSE waiting postgres 2888 23340 0 13:32 ?00:00:36 postgres: dbsomething dbsomething 8.8.8.3[38729] PARSE waiting postgres 2911 23340 0 13:33 ?00:00:11 postgres: dbsomething dbsomething 8.8.8.2[50352] PARSE waiting postgres 2912 23340 0 13:33 ?00:00:36 postgres: dbsomething dbsomething 8.8.8.2[50353] PARSE waiting postgres 2916 23340 0 13:33 ?00:00:30 postgres: dbsomething dbsomething 8.8.8.3[38750] PARSE waiting postgres 2922 23340 0 13:33 ?00:00:33 postgres: dbsomething dbsomething 8.8.8.4[59238] PARSE waiting postgres 2927 23340 1 13:33 ?00:00:38 postgres: dbsomething dbsomething 8.8.8.4[59242] PARSE waiting postgres 3012 23340 0 13:35 ?00:00:03 postgres: dbsomething dbsomething 8.8.8.2[50439] PARSE waiting postgres 3017 23340 0 13:35 ?00:00:01 postgres: dbsomething dbsomething 8.8.8.3[38833] PARSE waiting postgres 3018 23340 0 13:35 ?00:00:27 postgres: dbsomething dbsomething 8.8.8.3[38834] PARSE waiting postgres 3020 23340 0 13:35 ?00:00:24 postgres: dbsomething dbsomething 8.8.8.4[59318] PARSE waiting postgres 3026 23340 0 13:35 ?00:00:04 postgres: dbsomething dbsomething 8.8.8.4[59323] PARSE waiting postgres 3033 23340 0 13:35 ?00:00:15 postgres: dbsomething dbsomething 8.8.8.4[59328] PARSE waiting When I ran *SELECT * FROM pg_stat_activity*, the state in all queries was active and most were SELECTs, then the server did not open new connections. I canceled many queries (only SELECTs) and server back to normal. I understand that the principal problem probably are the application, of that I'm sure, but in the process debug. The best way to avoid or "fix" this are with connections pool like pgbouncer? How is the most secure way to return connections without restart service? I never had this problem, the idle connections is the normal in almost every database I managed, but this is new for me. Thanks for your help! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923p5968960.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
[GENERAL] postgres: dbname dbuser 9.9.9.9[2222] PARSE waiting
Hi folks. Today I had a problem with production's database PostgreSQL version 9.4.4.9. The server have max_connections set to 200, but today I reviewed pg_stat_activity and saw 199 active connections, obviously the server rejected any new connection and the production stopped. I saw another posts with a similar problems, but this was because the pg_xlog was full or disk does'nt write, but the directory and disk had no problems. I just canceled some SELECTs querys and the server returned to normality. Now a monitoring activity of server and I can see some backends like this: postgres 9737 23340 2 14:55 ?00:00:15 postgres: dbname user 8.8.8.8[37082] idle in transaction postgres 9741 23340 9 14:55 ?00:00:47 postgres: dbname user 8.8.8.8[54286] idle in transaction Any suggestions? - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/postgres-dbname-dbuser-9-9-9-9--PARSE-waiting-tp5968923.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
[GENERAL] With the password stored a another database, how to securely connecting to server
Hi folks I've a questions about the secure conections. I'm designed a local app with a micro database with h2 (is the java app), this app connect to PostgreSQL with many users. I want store password encrypted with md5 in the microdb. But my question, with this encrypted password. How to securely connecting to server? or How you recommend this? I Write from app a .pgpass with users data? Or whats the best practice for this? Thanks for your help! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/With-the-password-stored-a-another-database-how-to-securely-connecting-to-server-tp5956994.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] The same query is too slow in some time of execution
You're right, I'm sorry. At the moment, we review the schema for tables and indexes and decided redesigned. I detected a loop in the join, because we only have a integer sequencial like PK and no composite keys in the tables. I think that is the mainly problem. Thanks! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/The-same-query-is-too-slow-in-some-time-of-execution-tp5951060p5951841.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
[GENERAL] The same query is too slow in some time of execution
Hi folks! I've a query with a join of two tables. One table have a 5 millions rows and child table have a 17 millions rows. The query is executed many times in application, every 20 seconds aproximately. The query normally execute in 2-3 seconds but in some time without apparent pattern the query is hang to 4-6 minutes is too slow to normally performance. I've configured 2 things: 1. Each table have indexes. First table have 11 index and second table have 7 2. I configured the VACUUM and ANALYZE run after 20,000 rows inserted. But apparantly the problem continues Best Regards! DRakoROd - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://www.postgresql-archive.org/The-same-query-is-too-slow-in-some-time-of-execution-tp5951060.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
[GENERAL] Re: could not load library "$libdir/sslutils": in pg_upgrade process
Adrian, Tom Finally I did upgrade version but I've removed database pem (Postgres Enterprise Manager) I guess that this database has some link in some function to sslutils, because pg_upgrade showed the above errors while upgraded this database. /pg_restore: creating FUNCTION "public.sslutils_version()" pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 608; 1255 71731 FUNCTION sslutils_version() *pem* pg_restore: [archiver (db)] could not execute query: ERROR: could not find function "sslutils_version" in file "/opt/PostgreSQL/9.6/lib/postgresql/sslutils.so" Command was: CREATE FUNCTION "sslutils_version"() RETURNS "text" LANGUAGE "c" IMMUTABLE AS '$libdir/sslutils', 'sslutils_version'... / But when I removed pem database the process pg_upgrade finished correctly. Thanks for your help!! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/could-not-load-library-libdir-sslutils-in-pg-upgrade-process-tp5937304p5937545.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
[GENERAL] Re: could not load library "$libdir/sslutils": in pg_upgrade process
Teorycally, I removed the sslutils from old cluster when review the $libdir appear this: /[postgres@server ~]$ /opt/PostgreSQL/9.3/bin/pg_config --pkglibdir /opt/PostgreSQL/9.3/lib/postgresql [postgres@server ~]$ /opt/PostgreSQL/9.3/bin/pg_config --libs -lpgport -lpgcommon -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -ledit -lcrypt -ldl -lm / With ls command in /opt/PostgreSQL/9.3/lib/ and /opt/PostgreSQL/9.3/lib/postgresql not appear sslutils library. In fact, after uninstall ssutils I moved the contrib directory that contain sslutils directory (with make and uninstall scripts) to test whether that was, but the same error (tested with and without contrib directory). Thanks for your help! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/could-not-load-library-libdir-sslutils-in-pg-upgrade-process-tp5937304p5937468.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
[GENERAL] Re: could not load library "$libdir/sslutils": in pg_upgrade process
Yes I installed Postgres Enterprise Manager Agent time ago in this server to test agent, but now I don't use it. Amm if you refer the EDB install with binaries PostgreSQL one-click yes, but is not a EDB Advanced Server , is a normal Cluster installed by EDB binaries. - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/could-not-load-library-libdir-sslutils-in-pg-upgrade-process-tp5937304p5937324.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
[GENERAL] could not load library "$libdir/sslutils": in pg_upgrade process
Hi folks!
I'm try to upgrade version from 9.3.5 to 9.6.1, but in the 9.3.5 I installed
the sslutils to monitoring server with a agent, but now when I want upgrade
show this error pg_upgrade:
/Checking for presence of required libraries fatal
Your installation references loadable libraries that are missing from the
new installation. You can add these libraries to the new installation,
or remove the functions using them from the old installation. A list of
problem libraries is in the file:
loadable_libraries.txt/
with a cat in loadable_libraries.txt show this:
/could not load library "$libdir/sslutils":
ERROR: could not access file "$libdir/sslutils": No such file or directory
/
I installed in the new version 9.6.1 the same sslutil's version and process
that 9.3.5 and show this error:
/Consult the last few lines of "pg_upgrade_dump_68706.log" for
the probable cause of the failure.
Failure, exiting
"/opt/PostgreSQL/9.6/bin/pg_ctl" -w -D "/opt/PostgreSQL/9.6/data" -o "" -m
fast stop >> "pg_upgrade_server.log" 2>&1
[postgres@server ~]$ tailf pg_upgrade_dump_68706.log
pg_restore: creating COMMENT "public.FUNCTION
"openssl_rsa_generate_key"(integer)"
pg_restore: creating FUNCTION "public.openssl_rsa_key_to_csr("text", "text",
"text", "text", "text", "text", "text")"
pg_restore: creating COMMENT "public.FUNCTION
"openssl_rsa_key_to_csr"("text", "text", "text", "text", "text", "text",
"text")"
pg_restore: creating FUNCTION "public.sslutils_version()"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 608; 1255 71731 FUNCTION
sslutils_version() pem
pg_restore: [archiver (db)] could not execute query: ERROR: could not find
function "sslutils_version" in file
"/opt/PostgreSQL/9.6/lib/postgresql/sslutils.so"
Command was: CREATE FUNCTION "sslutils_version"() RETURNS "text"
LANGUAGE "c" IMMUTABLE
AS '$libdir/sslutils', 'sslutils_version'...
/
Then, I try uninstall the sslutils in the old cluster and recreate new
cluster clean of 9.6.1, but show the same error:
/could not load library "$libdir/sslutils":
ERROR: could not access file "$libdir/sslutils": No such file or directory
/
I restarted SO, unseted enviroment variables, but the same error.
Any Suggestions?
Best Regards.
DrakoRod
-
Dame un poco de fe, eso me bastará.
Rozvo Ware Solutions
--
View this message in context:
http://postgresql.nabble.com/could-not-load-library-libdir-sslutils-in-pg-upgrade-process-tp5937304.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] FATAL: semctl(999999, 6, SETVAL, 0) failed: Invalid argument
Hi Tom! Thanks for your quick response, in fact, it is not a problem with NAS storage. It is the systemd configuration. I had detected that the semaphores were removed every 20-30 minutes. After that configuration (the links that you share), I monitored during 1 hour and everything is going well. https://wiki.postgresql.org/wiki/Systemd https://www.postgresql.org/message-id/cak7teys9-o4bterbs3xuk2bffnnd55u2sm9j5r2fi7v6bhj...@mail.gmail.com Thanks! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/FATAL-semctl-99-6-SETVAL-0-failed-Invalid-argument-tp5933635p5933649.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
[GENERAL] FATAL: semctl(999999, 6, SETVAL, 0) failed: Invalid argument
Hi everybody I have a problem with to Postgres 9.5 with the semaphores, mainly in the Standby node, but in the mater node has been happening too. The implementation are in RedHat 7.2 with the NAS Storage, the data directory of PostgreSQL is in the NAS storage. I was read that PostgreSQL doesn't have problem with this type storage but now I have this problem and I'm not source that the problem are the storage. The error is following: 2016-12-05 03:02:31 CST FATAL: connection to client lost 2016-12-05 03:04:10 CST FATAL: semctl(5832710, 6, SETVAL, 0) failed: Invalid argument 2016-12-05 03:04:10 CST LOG: server process (PID 4852) exited with exit code 1 2016-12-05 03:04:10 CST LOG: terminating any other active server processes 2016-12-05 03:04:10 CST WARNING: terminating connection because of crash of another server process 2016-12-05 03:04:10 CST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2016-12-05 03:04:10 CST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2016-12-05 03:04:10 CST LOG: archiver process (PID 15360) exited with exit code 1 2016-12-05 03:04:10 CST WARNING: terminating connection because of crash of another server process 2016-12-05 03:04:10 CST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2016-12-05 03:04:10 CST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2016-12-05 03:04:10 CST WARNING: terminating connection because of crash of another server process 2016-12-05 03:04:10 CST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2016-12-05 03:04:10 CST HINT: In a moment you should be able to reconnect to the database and repeat your command. 2016-12-05 03:04:11 CST LOG: all server processes terminated; reinitializing 2016-12-05 03:04:11 CST LOG: could not remove shared memory segment "/PostgreSQL.1804289383": No such file or directory 2016-12-05 03:04:11 CST LOG: semctl(5636096, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5668865, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5701634, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5734403, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5767172, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5799941, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5832710, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: semctl(5865479, 0, IPC_RMID, ...) failed: Invalid argument 2016-12-05 03:04:11 CST LOG: database system was interrupted; last known up at 2016-12-05 03:03:26 CST 2016-12-05 03:04:12 CST LOG: database system was not properly shut down; automatic recovery in progress 2016-12-05 03:04:12 CST LOG: redo starts at 6/984DDFD0 2016-12-05 03:04:12 CST LOG: invalid record length at 6/984DE100 2016-12-05 03:04:12 CST LOG: redo done at 6/984DE0C8 2016-12-05 03:04:12 CST LOG: MultiXact member wraparound protections are now enabled 2016-12-05 03:04:12 CST LOG: database system is ready to accept connections I read this in web and forums: http://serverfault.com/questions/723636/connecting-to-postgresql-fails-with-semctl-invalid-argument http://postgresql.nabble.com/GENERAL-postgreslog-semctl-7438339-4-SETVAL-0-failed-td1860547.html https://groups.google.com/forum/#!topic/pgbarman/Hx4U9F24vnw I found this maybe some bug or something? http://stackoverflow.com/questions/36077235/all-auxiliary-procs-are-in-use-at-streaming-replication-server-in-postgresql-9-5 I have calculated and modificated kernel resources with the information this link: https://www.postgresql.org/docs/9.5/static/kernel-resources.html But the problem does not fix. I have the same implmentation but with SAN storage that is the production enviroment. I'm really worried that this not fix it. It is a virtual machine in VMWare. I have read many post talk about freeBSD jails, but I do not understand why freeBSD jails. What do you have to do with this? Any suggestion? Best Regards. - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/FATAL-semctl-99-6-SETVAL-0-failed-Invalid-argument-tp5933635.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] I can't see wal receiver process in one node
Hi Sameer Yesterday I reviewed the configuration in both servers. Configured each with the restore_command and archive_cleanup_command (to clean wal archives). But I saw in the Node B (only this node) have active the parameter named recovery_target_timeline = 'latest', this was because the one production node failed and the node B had that resync up the replication with another production node. My question. This parameter if not disabled affect the replication? Best Regards! DrakoRod - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/I-can-t-see-wal-receiver-process-in-one-node-tp5896950p5897234.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
[GENERAL] I can't see wal receiver process in one node
Hi everybody I have a question about the replication process, I have a cluster with three nodes A,B and C in PostgreSQL 9.3 with streaming replication in cascade mode MASTER->SLAVE-SLAVE. The question is a single process that I can't see in Node B but yes I can see it in the Node C. This process is this: Node B: * postgres: startup process recovering 00xxx * Node C: * postgres: startup process recovering 00xxx postgres: wal receiver process streaming /XX* The wal 00xxx is the same in both. Is a problem or is the case in the process of cascade replication? Best regards DrakoRod - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/I-can-t-see-wal-receiver-process-in-one-node-tp5896950.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
[GENERAL] FATAL: unable to read data from DB node 0
Hi everybody I've the next architecture with pgpool (streaming replication mode): 4 nodes 1 Master Node 2 Standbys Node 1 pgpool Node I've disabled the load balancing, because some clients report me problems with the load balancer, they told me the load balancer some times send querys to standby nodes, which has not yet recovered data and the querys fail, but this topic is for another thread. When I try run a stress test with hammerdb I see next errors in the pgpool Node 2015-11-27 16:48:21: pid 20190: FATAL: unable to read data from DB node 0 2015-11-27 16:48:21: pid 20190: DETAIL: EOF encountered with backend 2015-11-27 16:48:21: pid 19182: LOG: child process with pid: 20190 exits with status 256 2015-11-27 16:48:21: pid 19182: LOG: fork a new child process with pid: 20298 2015-11-27 16:48:21: pid 20163: FATAL: unable to read data from DB node 0 2015-11-27 16:48:21: pid 20163: DETAIL: EOF encountered with backend 2015-11-27 16:48:21: pid 19182: LOG: child process with pid: 20163 exits with status 256 2015-11-27 16:48:21: pid 19182: LOG: fork a new child process with pid: 20299 In all Child, therefore the hammerdb stop the test because all connections it lots. Any suggestions? Best regards! DrakoRod - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.nabble.com/FATAL-unable-to-read-data-from-DB-node-0-tp5875389.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] password in recovery.conf
Hi! Have you tried escape the Single or Double quote? Maybe this information can help you: http://stackoverflow.com/questions/12316953/insert-varchar-with-single-quotes-in-postgresql http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html Best Regards! - Dame un poco de fe, eso me bastará. Rozvo Ware Solutions -- View this message in context: http://postgresql.1045698.n5.nabble.com/password-in-recovery-conf-tp5820725p5820737.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] Server continuously enters to recovery mode.
Hi everybody Thank you for your help! I upgrade the version of 9.0.15 to 9.0.17. But after that constantly show this error, in all sessions: *WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. * The problem was in the database template0, this had a problem with the index, I saw in the log when server started, this error: *PANIC: could not open critical system index 2662 * So, I tried REINDEX but this crash. But I saw when I tried connect to the database template0, showed this error: *PANIC: could not open critical system index 2662 * So decided drop database. * DROP DATABASE template0; * But I saw this error: *ERROR: cannot drop a template database * Then run this query and after that DROP DATABASE: *UPDATE pg_database SET datistemplate='false' WHERE datname='template0'; * After that I delete the database template0 and resolved it!! Thanks for all!! :) -- View this message in context: http://postgresql.1045698.n5.nabble.com/Server-continuously-enters-to-recovery-mode-tp5802321p5802394.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
[GENERAL] Server continuously enters to recovery mode.
Hi everybody! I have a problem (really huge problem), I have one server of production, but yesterday in the night I saw this error: *ERROR: could not access status of transaction 2410303155 DETAIL: Could not open file "pg_clog/08FA": No such file or directory* Solution: * dd if=/dev/zero/ of=data/pg_clog/08FA bs=256K count=1* So I ran this solutions, no problem so far, but then (after 1 or 2 hours approximately), the server crash, I think somebody did something but did not tell me, no one did nothing! cool!! ¬¬. I started the server and this began in recovery mode, he started. But after some time (without apparent pattern), the server came into the recovery mode again. After that, the server continuously entering recovery mode, like I said without apparent pattern, between 3, 5 or 10 minutes run normally but then enter in the recovery mode again. I restart the server (began in recovery mode again), started, but after sometime he enter in recovery mode again. Try to recover the server with the PITR and nothing. The server version is 9.0.x in a Linux SUSE. The database size is the 336 GB. Please give me any help to recover the server! Thanks! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Server-continuously-enters-to-recovery-mode-tp5802321.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
