| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Олег Самойлов <splarv(at)ya(dot)ru> |
| Cc: | PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL lock file |
| Date: | 2019-08-09 14:31:56 |
| Message-ID: | 4820.1565361116@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
=?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv(at)ya(dot)ru> writes:
> I have a task to create HA PostgreSQL cross datacenter cluster. I created a test bed on VirtualBox and I simulate different failures and disastrous in loops. And got one of funny bug of the Postgresql (11.4). One of the clusters has two instances of PostgreSQL on port 5433 and 5434. After simulating unexpected power off of the node the lock files of PostgreSQL still exist in /tmp directory. And on recovery the first instance on port 5433 starts without problem, but the second instance sometimes not. The reason is that the PID in /tmp/.s.PGSQL.5434.lock sometimes point to the one of process of PostgereSQL on port 5433, for instance the logger.
Best practice for this sort of thing is considered to be to run the two
Postgres instances under different user IDs. That avoids them thinking
that the other one's lock files are relevant, and it provides an extra
layer of security against possible conflicts between the two instances.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2019-08-09 14:38:01 | Re: Generate test data inserts - 1GB |
| Previous Message | Tom Lane | 2019-08-09 14:15:23 | Re: PostgreSQL 8.4 Tablespace Inconsistency |