Re: Performance Issue after upgrade from 9 to 11

j On Wed, Jan 29, 2020 at 2:33 PM Peter J. Holzer wrote: > On 2020-01-29 09:39:03 -0800, Perumal Raj wrote: > > We have recently upgraded postgres from 9.2 to 11.6 and started seeing > > performance issue immediately and able to fix the performance issue > after > > d

Re: Performance Issue after upgrade from 9 to 11

autovacuum . On Wed, Jan 29, 2020 at 10:22 AM Tom Lane wrote: > Perumal Raj writes: > > We have recently upgraded postgres from 9.2 to 11.6 and started seeing > > performance issue immediately and able to fix the performance issue > after > > disabling parameter: enab

Performance Issue after upgrade from 9 to 11

Hi All, We have recently upgraded postgres from 9.2 to 11.6 and started seeing performance issue immediately and able to fix the performance issue after disabling parameter: enable_seqscan. Question : Should i keep the above parameter always disabled ? If not why the behavior changed in Higher v

Re: pg_upgrade : 9.X to 11.X issue CentoOS 7.6

Sorry i missed to refer link. https://dba.stackexchange.com/questions/50135/pg-upgrade-unrecognized-configuration-parameter-unix-socket-directory On Tue, Jul 23, 2019 at 9:20 AM Tom Lane wrote: > Perumal Raj writes: > > Finally upgrade completed successfully after implementing the

Re: pg_upgrade : 9.X to 11.X issue CentoOS 7.6

g_ctl chmod +x /usr/bin/pg_ctl *Special thanks to ''Ziggy Crueltyfree Zeitgeister '* On Tue, Jul 23, 2019 at 7:51 AM Perumal Raj wrote: > Hi All, > > Yes, , bin file correct only as it came up with CentOS 7.6 . > > Anyhow , thanks for the pointers which helped me to

Re: pg_upgrade : 9.X to 11.X issue CentoOS 7.6

ver writes: > > On 7/23/19 7:17 AM, Perumal Raj wrote: > >> command: "/usr/pgsql-9.2/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D > >> "/data/db/data" -o "-p 5432 -b -c listen_addresses='' -c > >> unix_socket_permissions=070

Re: pg_upgrade : 9.X to 11.X issue CentoOS 7.6

n_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_upgrade : 9.X to 11.X issue CentoOS 7.6

Hi Team, Please give me some pointers to resolve this issue. -bash-4.2$ export OLDCLUSTER=/usr/pgsql-9.2 -bash-4.2$ export NEWCLUSTER=/usr/pgsql-11 -bash-4.2$ /usr/pgsql-11/bin/pg_upgrade --old-bindir=$OLDCLUSTER/bin --new-bindir=$NEWCLUSTER/bin --old-datadir=/data/db/data --new-datadir=/pgdata/

Resolved: Looking for Postgres upgrade Metrix

Ok, thanks for the clarification. On Wed, Jul 17, 2019 at 11:46 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Jul 17, 2019 at 11:39 AM Perumal Raj wrote: > >> Thanks Adrian, David, >> >> Basically , i want to upgrade few 9.X/8.X version DBs

Re: Looking for Postgres upgrade Metrix

wrote: > On 7/17/19 11:15 AM, Perumal Raj wrote: > > Hi Team, > > > > Do we have any reference link which explain various upgrade path ( > > Direct / indirect) by using pg_upgrade or latest utility. > > https://www.postgresql.org/docs/11/backup.html >

Looking for Postgres upgrade Metrix

Hi Team, Do we have any reference link which explain various upgrade path ( Direct / indirect) by using pg_upgrade or latest utility. I hope pg_dump can be used from any lower version to Higher version. Please correct me if I am wrong. Thanks, Raj

Re: Flood Warning message : user=[unknown],db=[unknown],host= WARNING: pg_getnameinfo_all() failed: Temporary failure in name resolution

alidate ldap_user password using ldapsearch ? Or is there any specific format in pg_hba.conf to configure LDAP. Regards, Raj On Wed, Jun 5, 2019 at 4:56 PM Perumal Raj wrote: > Thanks Steve for the response, Yes we had DNS server change. > But conf file updated with right DNS server and i

Re: Flood Warning message : user=[unknown],db=[unknown],host= WARNING: pg_getnameinfo_all() failed: Temporary failure in name resolution

bute=uid Version :9..2 Regards, Raju On Wed, Jun 5, 2019 at 11:08 AM Steve Crawford < scrawf...@pinpointresearch.com> wrote: > On Wed, Jun 5, 2019 at 10:13 AM Perumal Raj wrote: > >> Hi All, >> >> We have recently noticed in our development environment pg_log

Flood Warning message : user=[unknown],db=[unknown],host= WARNING: pg_getnameinfo_all() failed: Temporary failure in name resolution

Hi All, We have recently noticed in our development environment pg_log with flooded message. [64459]: [1-1] user=[unknown],db=[unknown],host= WARNING: pg_getnameinfo_all() failed: Temporary failure in name resolution [64463]: [1-1] user=[unknown],db=[unknown],host= WARNING: pg_getnameinfo_all()

Re: Centos : Load Average :OS Process Name : migration/1, migration/2 , migration/n

Thanks for the update Ron, Hopefully i will get some lead further on this issue, Will keep u posted. On Wed, May 22, 2019 at 6:07 PM Ron wrote: > On 5/22/19 4:18 PM, Perumal Raj wrote: > > Hi All, > > We have recently migrated postgres DB to out of of server ( Centos 6.9 ) . &g

Re: Centos : Load Average :OS Process Name : migration/1, migration/2 , migration/n

On Thu, May 23, 2019 at 9:18 AM Perumal Raj wrote: > > We have recently migrated postgres DB to out of of server ( Centos 6.9 ) > . > > Both Source and Target versions of OS/DB are same . Also Configuration > is Apple-Apple. > > > > But We started seeing lot of proces

Centos : Load Average :OS Process Name : migration/1, migration/2 , migration/n

Hi All, We have recently migrated postgres DB to out of of server ( Centos 6.9 ) . Both Source and Target versions of OS/DB are same . Also Configuration is Apple-Apple. But We started seeing lot of process name 'migration' at OS Level in new server which is triggering Load average most of the ti

Re: Recommendation to run vacuum FULL in parallel

activity with full apps down time. Going forward i am going to run vacuum daily basis to maintain the DB size. Also Table/DB Age came down drastically. Thanks Raj On Thu, Apr 4, 2019 at 12:53 PM Kevin Brannen wrote: > *From:* Perumal Raj > > So conclude the requirement here , The on

Re: Recommendation to run vacuum FULL in parallel

, then there may be something > else going on. > > Which PG version is that? > > > — Stephen > On Apr 3, 2019, 10:02 AM -0700, Perumal Raj , wrote: > > Hi All > > Thanks for all your valuable inputs, > > Here is some more data, > > Though we have 150 GB

Re: Recommendation to run vacuum FULL in parallel

Hi All Thanks for all your valuable inputs, Here is some more data, Though we have 150 GB free space spread across 500 Tables , Every alternative day DB is growing with 1 GB rate. Also,We have manual vacuum job scheduled to run weekly basis, So seems to be space is not reusing all the time ? S

Recommendation to run vacuum FULL in parallel

Hi ALL We are planning to reclaim unused space from 9.2 Version postgres Cluster, Method : VACUUM FULL DB Size : 500 GB Expected space to reclaim 150 GB work_mem : 250 MB maintenance_work_mem : 20 GB *Question :* 1. vacuumdb --j option (Parallel) not available for version 9.2. How to run vac

Re: software or hardware RAID?

Hi All Just would like to know conclusion here , What is best RAID method (Software Or Hardware) for Postgres DB and what level ? Thanks, Raj On Sat, Mar 23, 2019 at 3:12 PM Kenneth Marshall wrote: > On Sat, Mar 23, 2019 at 12:09:11PM +, Rory Campbell-Lange wrote: > > On 17/03/19, Rory

Re: Autovacuum Transaction Wraparound

ings value with respect to Autovacuum ? Regards, On Mon, Mar 11, 2019 at 12:45 PM Adrian Klaver wrote: > On 3/11/19 12:16 PM, Perumal Raj wrote: > > Hi Adrian/Joshua > > > > Sorry to mention in the previous thread, > > > > Auto-vacuum is already enabled in the

Re: Autovacuum Transaction Wraparound

| 50| log_autovacuum_min_duration |-1 . | Regards, On Mon, Mar 11, 2019 at 12:07 PM Adrian Klaver wrote: > On 3/11/19 11:51 AM, Perumal Raj wrote: > > Hi Experts > > > > I have noticed in my Database that, there is no regular Vacuum > > maintenance happening >

Autovacuum Transaction Wraparound

Hi Experts I have noticed in my Database that, there is no regular Vacuum maintenance happening So i started Weekly Job across cluster. But still i am seeing gradual growth on transacation ID. DB is still using default autovacuum_freeze_min_age & autovacuum_freeze_table_age. Question : Since i a

Resolved: Question about pg_upgrade from 9.2 to X.X

Thanks again. Perumal Raju On Thu, Mar 7, 2019, 2:32 AM Justin Pryzby wrote: > On Wed, Mar 06, 2019 at 09:44:16PM -0800, Perumal Raj wrote: > > Any pointers for pg_repack schema creation ? > > With recent postgres, you should use just: "CREATE EXTENSION pg_repack", &g

Re: Question about pg_upgrade from 9.2 to X.X

at 08:09:12AM -0800, Perumal Raj wrote: > > Thanks Sergei/Justin for the continues update. > > > > So reorg Schema might be created as part of some scripts prior to 9.2 > > Version ? > > I'm guessing they were probably created in 9.2. > > > These are the f

Re: Question about pg_upgrade from 9.2 to X.X

Thanks Sergei/Justin for the continues update. So reorg Schema might be created as part of some scripts prior to 9.2 Version ? These are the functions in DB not the Extension. However these functions will not run as the associated libraries are not exists in System now (9.2) and I hope no impact t

Re: Question about pg_upgrade from 9.2 to X.X

On Mon, Mar 04, 2019 at 01:37:30PM -0800, Perumal Raj wrote: > > I could see bunch of functions under reorg schema. > > Those functions are the ones preventing you from upgrading. > You should drop schema pg_reorg cascade. > You can run it in a transaction first to see what it w

Re: Question about pg_upgrade from 9.2 to X.X

;reorg_drop'; AS '$libdir/pg_reorg', 'reorg_indexdef'; AS '$libdir/pg_reorg', 'reorg_swap'; AS '$libdir/pg_reorg', 'reorg_trigger'; AS '$libdir/pg_reorg', 'reorg_version'; I am not sure about the impact of these f

Re: Question about pg_upgrade from 9.2 to X.X

ng and crash reports). > > On Thu, Feb 28, 2019 at 10:13:58AM -0800, Perumal Raj wrote: > > could not load library "$libdir/pg_reorg": > > ERROR: could not access file "$libdir/pg_reorg": No such file or > directory > > As Sergei said, you can run pg_d