In case someone is facing the same problem again, solution is to add * in
.pgpass in place of ip address.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/pgpass-being-ignored-tp5760421p5815268.html
Sent from the PostgreSQL - general mailing list archive at Nabble.co
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
Sergey,
Version is PostgreSQL 9.1.4.
max_standby_archive_delay = 120s
max_standby_streaming_delay = 180s
Long running activity or idle in transactions are not there on either
master or slave as we stop all connections to both the DBs during vacuum.
Regards,
Granthana
On Fri, Mar 21, 2014 at
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
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
removed yet.
The number of dead rows varies with each table.
Regards,
Granthana
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_x
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 foll
,
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
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
>
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
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
() =
pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp()) END AS log_delay;
Regards,
Granthana
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:
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
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
16 matches
Mail list logo
