Re: pg_upgrade help
Hello Akshay, Try starting both servers individually. If you can then,it may be port conflict Below is the part of document- Obviously, no one should be accessing the clusters during the upgrade. pg_upgrade defaults to running servers on port 50432 to avoid unintended client connections. You can use the same port number for both clusters when doing an upgrade because the old and new clusters will not be running at the same time. *However, when checking an old running server, the old and new port numbers must be different. * Thanks Rajni On Thu, Apr 19, 2018 at 12:02 AM, Adrian Klaver wrote: > On 04/18/2018 05:02 AM, Akshay Ballarpure wrote: > >> Hi Fabio, >> sorry to bother you again, its still failing with stopping both server >> (8.4 and 9.4) >> > > Actually according to the command show at bottom of post it is failing > trying to start the 8.4 server. In your previous post that was because it > was already running: > > -bash-4.2$ ps -eaf | grep postgres > postgres 9778 1 0 09:17 ?00:00:00 /usr/bin/postgres -p 50432 > -D /var/ericsson/esm-data/postgresql-data/ > > FATAL: lock file "postmaster.pid" already exists > HINT: Is another postmaster (PID 9778) running in data directory > "/var/ericsson/esm-data/postgresql-data"? > pg_ctl: could not start server > > > Make sure both servers are stopped before running pg_upgrade. Per a > previous suggestion follow the check list here: > > https://www.postgresql.org/docs/10/static/pgupgrade.html > " > Usage > > These are the steps to perform an upgrade with pg_upgrade: > > ... > > > " > > >> -bash-4.2$ /opt/rh/rh-postgresql94/root/usr/bin/pg_upgrade >> --old-bindir=/usr/bin --new-bindir=/opt/rh/rh-postgresql94/root/usr/bin >> --old-datadir=$OLDCLUSTER --new-datadir=$NEWCLUSTER >> >> connection to database failed: could not connect to server: No such file >> or directory >> Is the server running locally and accepting >> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL. >> 50432"? >> >> >> could not connect to old postmaster started with the command: >> "/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D >> "/var/ericsson/esm-data/postgresql-data" -o "-p 50432 -c autovacuum=off >> -c autovacuum_freeze_max_age=20 -c listen_addresses='' -c >> unix_socket_permissions=0700" start >> Failure, exiting >> >> >> With Best Regards >> Akshay >> > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com > > -- Thank you Sincere Regards Rajni 0410 472 086
Re: pg_controldata: could not read file "/opt/postgres/9.2/data//global/pg_control": Success
Hi Raghvendra, Free up some space before restarting. Old archive/backup/logs could be the candidate for clean up. You do not need much space to restart instance. Once started, login to db and execute checkpoint. Thanks Rajni On Mon, 8 Oct 2018 at 4:40 pm Raghavendra Rao J S V < raghavendra...@gmail.com> wrote: > *Hi All,* > > *archive_mode *is turned *on *unfortunately in my Postgres 9.2 database. > > Due to that disk space is full 100%. We are facing below problem when we > try to start the database. > > *PANIC: could not read from control file:Success* > > Please help me how to handle this situation. > > > > *Log files contians the infomration as below:-* > > 2018-10-08 05:27:44.262 UTC,,,27688,,5bbaead0.6c28,1,,2018-10-08 05:27:44 > UTC,,0,LOG,0,"database system was interrupted while in recovery at > 2018-10-03 15:01:03 UTC",,"This probably means that some data is corrupted > and you will have to use the last backup for recovery.",,,"" > 2018-10-08 05:27:44.262 UTC,,,27688,,5bbaead0.6c28,2,,2018-10-08 05:27:44 > UTC,,0,LOG,0,"database system was not properly shut down; automatic > recovery in progress","" > 2018-10-08 05:27:44.265 UTC,,,27688,,5bbaead0.6c28,3,,2018-10-08 05:27:44 > UTC,,0,LOG,0,"redo starts at 93/775816B0","" > 2018-10-08 05:27:44.514 UTC,,,27688,,5bbaead0.6c28,4,,2018-10-08 05:27:44 > UTC,,0,FATAL,53100,"could not extend file ""base/77017/160045"": wrote only > 4096 of 8192 bytes at block 278",,"Check free disk space.",,,"xlog redo > insert(init): rel 1663/77017/160045; tid 278/1""" > 2018-10-08 05:27:44.517 UTC,,,27686,,5bbaead0.6c26,1,,2018-10-08 05:27:44 > UTC,,0,LOG,0,"startup process (PID 27688) exited with exit code > 1","" > 2018-10-08 05:27:44.517 UTC,,,27686,,5bbaead0.6c26,2,,2018-10-08 05:27:44 > UTC,,0,LOG,0,"aborting startup due to startup process > failure","" > > -- > Regards, > Raghavendra Rao J S V > Mobile- 8861161425 > -- Thanks Regards, Rajni 0410472086
Re: Help with configuring pgAudit
Hello Dave, What I can see is you missed to include pgAudit extension in shared_preload_libraries parameter (*shared_preload_libraries='pgaudit'*). Thanks Rajni On Wed, Nov 20, 2019 at 7:39 AM Dave Hughes wrote: > Hello, > I'm using PostgreSQL 10.5 on Linux (RHEL). I recently installed pgAudit > and was trying to configure it to capture DLL statements. > > 1) The first thing I tried was to edit the postgresql.conf file directly. > I didn't see any commented out default entries to edit, so near where I > have the entries: > log_destination = 'csvlog' > log_collector = on > I entered my own entry of: > pgaudit.log = 'ddl' > Then I restarted the database. After doing this I created and dropped a > table, but no entry of that in the log file > postgresql-2019-11-19-141901.csv. > > 2) So then tried to create the entry using the ALTER command: > ALTER SYSTEM SET pgaudit.log TO 'ddl'; > SELECT pg_reload_conf(); > After doing this, I noticed a second file was created > (postgresql.auto.conf). That file had the entry pgaudit.log = 'ddl'. From > what I read, this file get read after the main postgresql.conf file. > However after creating and dropping a table, still no entry in the log > file. I did notice though when I run the command: show pgaudit.log; It > came back with 'Role' (and not ddl). > > 3) So the final thing I tried was to enter the command: set pgaudit.log = > 'ddl'; Now when I run the command show pgaudit.log; it returned 'ddl'. > This time I tried to drop a table again. After the table was dropped , my > psql client displayed: > NOTICE: AUDIT: SESSION, 1,1,DDL, DROP TABLE, TABLEblah,blah logged>. This looks like a pgaudit entry but was on my screen and not in > the log file. At this point I restarted the database again and now when I > run the command: show pgaudit.log; it defaulted back to 'Role' (vs. ddl). > > Can someone please help me see what it is i'm doing incorrectly? > > Thanks in advance, > Dave Hughes > >
