| From: | Ted EH <ted(dot)elhourani(at)gmail(dot)com> |
|---|---|
| To: | Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com> |
| Cc: | pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: WAL segment not replicated |
| Date: | 2018-03-01 22:24:35 |
| Message-ID: | CA+G4h2A+n==bHb4s0tW5=5gQp=qaV+9oOU-WL8HPLj4o4dKmMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
My reason for killing the process is to test behavior in the event of an
unclean shutdown.
In the test, I made sure the former primary is being demoted to standby.
To keep things simple, I have repeated the test without restarting the
former primary, and without pormoting the stby.
Before killing the main pg server process, both primary and stby have 00065
as the latest segment, under pg_wal
This time all I did is "sudo pkill postmaster", after which under pg_wal
On the stby the latest segment is still 00064, while on the primary it is
now 00065
Which means a process continues to run on the primary and creates the next
WAL segment (...65). Is this expected? and why?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Kirkwood | 2018-03-01 22:40:51 | Re: Reliable WAL file shipping over unreliable network |
| Previous Message | girish R G peetle | 2018-03-01 22:07:49 | pg_dump to fifo file on Linux |