Re: [GENERAL] Dead rows not getting removed during vacuum

Thank you Tom. We will be upgrading soon. Regards, Granthana On Mon, Mar 24, 2014 at 7:28 PM, Tom Lane wrote: > Granthana Biswas writes: > > Version is PostgreSQL 9.1.4. > > You do realize you're missing almost two years' worth of bug fixes? > The current rele

Re: [GENERAL] Dead rows not getting removed during vacuum

8:51 PM, Sergey Konoplev wrote: > On Fri, Mar 21, 2014 at 2:46 AM, Granthana Biswas > wrote: > > We don't have two-phase commit prepared transactions. During vacuum, > along with this problem we are also facing streaming replication issue. > Hundreds of xlogs are in

Re: [GENERAL] Dead rows not getting removed during vacuum

lowly and replication lag keeps increasing. Regards, Granthana On Fri, Mar 21, 2014 at 3:36 AM, Sergey Konoplev wrote: > On Thu, Mar 20, 2014 at 5:27 AM, Granthana Biswas > wrote: > > Has anyone ever faced the issue of dead rows not getting removed during > > vacuum ev

Re: [GENERAL] Dead rows not getting removed during vacuum

Hi Venkata, No there are no other connections to the DB during vacuum. Regards, Granthana On Fri, Mar 21, 2014 at 3:12 AM, Venkata Balaji Nagothi wrote: > On Thu, Mar 20, 2014 at 5:27 AM, Granthana Biswas wrote: > > Hello All, >> >> Has anyone ever faced the issue of

[GENERAL] Dead rows not getting removed during vacuum

Hello All, Has anyone ever faced the issue of dead rows not getting removed during vacuum even if there are no open transactions/connections? We have been facing this during every scheduled vacuum which is done after closing all other database connections: 119278 dead row versions cannot be remo

Re: [GENERAL] Correct query to check streaming replication lag

Yes byte lag as well as it makes more sense. Regards, Granthana Regards, Granthana On Tue, Jan 21, 2014 at 11:03 AM, Sameer Kumar wrote: > >> >> We are already using the following query: >> >> SELECT CASE WHEN pg_last_xlog_receive_location( >> ) = pg_last_xlog_replay_location() THEN 0 ELSE EXT

Re: [GENERAL] Correct query to check streaming replication lag

Thanks a load Michael. This is really helpful. Regards, Granthana On Tue, Jan 21, 2014 at 12:19 PM, Michael Paquier wrote: > > > On Tue, Jan 21, 2014 at 2:33 PM, Sameer Kumar > wrote: > >> > >> > >> We are already using the following query: > >> > >> SELECT CASE WHEN pg_last_xlog_receive_loc

Re: [GENERAL] Correct query to check streaming replication lag

, Granthana On Fri, Jan 17, 2014 at 8:24 PM, Ray Stell wrote: > > On Jan 17, 2014, at 5:07 AM, Granthana Biswas wrote: > > Yes it's purely for monitoring purpose. > > > I use the pg_controldata cmd locally and via bash/ssh shared keys and > compare various values

Re: [GENERAL] Correct query to check streaming replication lag

Yes we already do that. Count the number of ready wal files. Regards, Granthana On Sat, Jan 18, 2014 at 9:39 PM, Sameer Kumar wrote: > Well in that case monitoring pending wal bytes would make more sense. > > Regards > Sameer > > PS: Sent from my Mobile device. Pls ignore typo n abb >

Re: [GENERAL] Correct query to check streaming replication lag

Yes it's purely for monitoring purpose. Regards, Granthana On Fri, Jan 17, 2014 at 3:29 PM, Sameer Kumar wrote: > > > On Fri, Jan 17, 2014 at 5:31 PM, Granthana Biswas wrote: > >> >> >> Thank you Sameer for your reply. Is there any other query that woul

Re: [GENERAL] Correct query to check streaming replication lag

Thank you Sameer for your reply. Is there any other query that would help get exact replication lag? Regards, Granthana Regards, Granthana On Fri, Jan 17, 2014 at 2:46 PM, Sameer Kumar wrote: > > On Tue, Jan 14, 2014 at 2:31 PM, Granthana Biswas wrote: > >> Can anyone please t

[GENERAL] Correct query to check streaming replication lag

Hello All, Can anyone please tell me which of the following is the correct replication lag query to find streaming replication lag in seconds? 1. SELECT extract(seconds from (now() - pg_last_xact_replay_timestamp())) AS time_lag; 2. SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog

[GENERAL] AccessShareLock on pg_authid

Hi, Processes are failing due to the following error on Postgresql 8.3.5: FATAL: lock AccessShareLock on object 0/1260/0 is already held 1260 oid belongs to pg_authid. This error is not coming for every transaction. I have found these two links related to the above error but not quite helpful:

Re: [GENERAL] Transaction control in shards through PLPROXY

Hi Sergey, Thank you for your reply. Have you implemented this while sharding your database? Did it cause any performance issues? Warm regards, GB On Mon, Jul 15, 2013 at 10:51 AM, Sergey Konoplev wrote: > On Wed, Jul 10, 2013 at 10:20 PM, Granthana Biswas > wrote: > > Inspite of

[GENERAL] Transaction control in shards through PLPROXY

Hi, Even though this mailing list is for postgresql users only, I am sending this query related to postgresql sharding in case anyone has already faced this problem while sharding their database. Inspite of being aware that PLPROXY does autocommit for DML functions called on shards, I was wond