-1 | xx |
(9 rows)
2016-05-25 23:22 GMT+02:00 Andrej Vanek <andrej.vanek...@gmail.com>:
> 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 se
ing 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 <andrej.vanek...@gmail.com>:
> Streaming replicat
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
iting 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 <adrian.kla...@aklaver.com>:
> On 04/17/2016 12:13 PM, Andrej Vanek wrote:
>
>> Hello Adrian,
>>
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
ine 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 <gsiever...@comcast.net>:
> Andrej Vanek <andrej.vanek...@gmail.com> writes:
>
> > Hello,
> >
> > I tried to run pg_bas
Regards, Andrej
2016-04-16 1:17 GMT+02:00 Adrian Klaver <adrian.kla...@aklaver.com>:
> 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 s
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
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
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).
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?
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
know whether there is such cluster agent already available?
Best Regards, Andrej
2014-05-27 16:09 GMT+02:00 Alvaro Herrera alvhe...@2ndquadrant.com:
Andrej Vanek wrote:
Hello,
solved.
This is not a postgres issue.
The system was used in HA-cluster with streaming replications
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
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
15 matches
Mail list logo
