Re: [GENERAL] empty pg_stat_replication when replication works fine?

| -1 | xx | (9 rows) 2016-05-25 23:22 GMT+02:00 Andrej Vanek : > Streaming replication set-up, > > one master, 3 slaves connecting to it. > I expected ps -ef gets all wal-sender processes and SAME information I'll > get via select * from pg_sta

[GENERAL] pg_basebackup: return value 1: reason?

Hello, I tried to run pg_basebackup. Return value is 1. How to find out its reason? (I suspect that some wal after backup is missing- but how to find out the real reason? How to fix it?) thanks, Andrej --details: environment: CentOS 6.7, postgres 9.5.1 ( PostgreSQL 9.5.1 on x86_64-pc

Re: [GENERAL] pg_basebackup: return value 1: reason?

Best Regards, Andrej 2016-04-16 1:17 GMT+02:00 Adrian Klaver : > On 04/15/2016 03:28 PM, Andrej Vanek wrote: > >> Hello, >> >> I tried to run pg_basebackup. Return value is 1. >> >> How to find out its reason? >> (I suspect that some wal after backup is missi

Re: [GENERAL] pg_basebackup: return value 1: reason?

it works. It fails just when launched from a script fired by crm_mon -d -E my-script Regards, Andrej 2016-04-16 1:18 GMT+02:00 Jerry Sievers : > Andrej Vanek writes: > > > Hello, > > > > I tried to run pg_basebackup. Return value is 1. > > > > How to find o

Re: [GENERAL] pg_basebackup: return value 1: reason?

Hello Adrian, I tried to use -U without "su"- launched directly by root: same behaviour. Finally I reverted my script to use standard backup (pg_start_backup; rsync; pg_stop_backup)- this works- the only downside is possible collisions with on-line backup/synchronizaiton of other two nodes on mast

Re: [GENERAL] pg_basebackup: return value 1: reason?

CF8 pg_basebackup: waiting for background process to finish streaming ... pg_basebackup: could not wait for child process: No child processes RETVAL=1 2016-04-18 16:12 GMT+02:00 Adrian Klaver : > On 04/17/2016 12:13 PM, Andrej Vanek wrote: > >> Hello Adrian, >&g

[GENERAL] empty pg_stat_replication when replication works fine?

Streaming replication set-up, one master, 3 slaves connecting to it. I expected ps -ef gets all wal-sender processes and SAME information I'll get via select * from pg_stat_replication. Instead I observed: - pg_stat_replication is empty - 3 wal-sender processes up and running - each slave has wal-

Re: [GENERAL] empty pg_stat_replication when replication works fine?

as described, do not reflect ps -ef list of postgres processes and running SQL client/replication information) What may be additionally useful information before restarting the master? Regards, Andrej 2016-05-25 23:22 GMT+02:00 Andrej Vanek : > Streaming replication set-up, > > one mast

[GENERAL] hidden junk files in ...data/base/oid/

Hello, I ran upgrade from 9.1 to 9.3 on CentOS using pg_upgrade and database cluster size dropped from 77GB to 4.3GB. I wonder how this could happen. No data lost. This means I had about 70GB junk files in my database... I checked top 10 biggest database tables: nearly same size on old/new cluste

Re: [GENERAL] hidden junk files in ...data/base/oid/

Hello, solved. This is not a postgres issue. The system was used in HA-cluster with streaming replications. The hidden files I asked for were created probably by broken (killed) rsync. It uses such file-format for temporary files used during copying. This rsync is used by master to slave databas

Re: [GENERAL] hidden junk files in ...data/base/oid/

ta loss. Do you know whether there is such cluster agent already available? Best Regards, Andrej 2014-05-27 16:09 GMT+02:00 Alvaro Herrera : > Andrej Vanek wrote: > > Hello, > > > > solved. > > This is not a postgres issue. > > > > The system was used in

[GENERAL] deadlock of lock-waits (on transaction and on tuple) using same update statement

Hi, My application runs many concurrent sessions with the same transaction code starting with an update statement. I would expect locking and serialization of those transactions. But I get unexpected deadlocks. As opposed to *http://momjian.us/main/writings/pgsql/locking.pdf

Re: [GENERAL] deadlock of lock-waits (on transaction and on tuple) using same update statement

Hi Bill, thanks for your answer. > most often caused by something earlier in the transactions > need all of the statements in each transaction It would be great if we could reveal an application error. Whole transactions I've already posted (in postgres log: log_min_duration_statement=0). Not

Re: [GENERAL] deadlock of lock-waits (on transaction and on tuple) using same update statement

Hi, now I've checked release-notes of 9.3.5 (my version 9.3.4)- found a fix which probably could lead to my deadlocks: > Fix race condition when updating a tuple concurrently locked by another process (Andres Freund,Álvaro Herrera) How can I make sure I've run into this bug?

Re: [GENERAL] deadlock of lock-waits (on transaction and on tuple) using same update statement

Hi, retested: yes, this is still an issue in 9.3.5, same deadlock errors occured. Do you need to extract some simplified reproducible testcase? Best Regards, Andrej