Re: [GENERAL] Confused about max_standby_streaming_delay
| От | Jeff Janes |
|---|---|
| Тема | Re: [GENERAL] Confused about max_standby_streaming_delay |
| Дата | |
| Msg-id | CAMkU=1x-dPdeAucqHASxLM8z2WouRar-P8GDJ95mUKP+swu9nQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Confused about max_standby_streaming_delay (Robert Inder <robert@interactive.co.uk>) |
| Список | pgsql-general |
On Thu, Sep 7, 2017 at 1:16 AM, Robert Inder <robert@interactive.co.uk> wrote:
On 6 September 2017 at 20:47, Jeff Janes <jeff.janes@gmail.com> wrote:Have I misunderstood something? Or is Postgres not actually configured the way I think it is?The standby will wait for ten minutes to obtain the lock it wishes to obtain. In 9.4, if something other than dump of database b was already blocking it for 8 minutes before the dump starts, then the dump of database b will only have 2 minutes, not 10, before it gets cancelled.Hmmmm...You're saying that the time for dumping database b may be spent 8 minutes waiting on a lock then 2 minutes actually dumping.
No, I'm saying that maybe the replay process was already waiting for something else for 8 minutes before the pg_dump of database b even attempted to start. So it would be cancelled after 2 minutes.
Are these database a, database b, etc. different databases in the same postgres instance (CREATE DATABASE A) or are they entirely different postgres instances (initdb -D /opt/database_a)? Your original description of different unix users with different installations made me think the 2nd case is the one, but just want to make sure.
Cheers,
Jeff
В списке pgsql-general по дате отправления: