Re: Query running for 12 hours

2018-05-30 Thread Yavuz Selim Sertoğlu
Major upgrade would be very painful because there are many application running on different servers but same database server. Their tests would take too much time. So I will try to go with minor upgrade. Thanks for your help, have a good day. >> > Remaining suggestions/questions: > > 1) If it

Re: Query running for 12 hours

2018-05-30 Thread Yavuz Selim Sertoğlu
2018-05-30 17:02 GMT+03:00 Adrian Klaver : > On 05/30/2018 06:54 AM, Yavuz Selim Sertoğlu wrote: > >> I am just a regular dba so I dont know what's sent from application >> exactly but I assume now()-1 week. >> In the log file, there are two more same queries. And the

Re: Query running for 12 hours

2018-05-30 Thread Yavuz Selim Sertoğlu
I am just a regular dba so I dont know what's sent from application exactly but I assume now()-1 week. In the log file, there are two more same queries. And their value is *2018-05-23 02:00:00* *Here are todays log lines for that query.* tarih=2018-05-30 02:12:19 +03,session_number=1,db=mydb,use

Query running for 12 hours

2018-05-30 Thread Yavuz Selim Sertoğlu
(1 row) I could not figure out what the problem is. I would be happy if someone could help me to solve this situation. -- Saygılarımla *Yavuz Selim Sertoğlu* Veritabanı Uzmanı T 0 312 220 1 220 F 0 312 286 00 10 M 0 542 728 08 02 *yavuzselim.serto...@bisoft.com.tr *

Re: Resync second slave to new master

2018-03-07 Thread Yavuz Selim Sertoğlu
If not set, could you add recovery.conf file recovery_target_timeline='latest' parameter? https://www.postgresql.org/docs/devel/static/recovery-target-settings.html 2018-03-08 10:41 GMT+03:00 Dylan Luong : > Hi Michael, > > I tested the failover today and the slave 2 failed to resync with the ne