Re: WIP: long transactions on hot standby feedback replica / proof of concept

On Tue, Oct 24, 2017 at 10:56 AM, Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru
> wrote:

> Hello. I made some bugfixes and rewrite the patch.
>
> Simon Riggs писал 2017-09-05 14:44:
>
>> As Alexander says, simply skipping truncation if standby is busy isn't
>> a great plan.
>>
>> If we defer an action on standby replay, when and who will we apply
>> it? What happens if the standby is shutdown or crashes while an action
>> is pending.
>>
>
> After crash standby server will go to the nearest checkout and will replay
> all his wal`s to reach consistent state and then open for read-only load.
> (all collected wal`s will be replayed in right way, I meant wal`s that
> truncates table and wal`s that make table grow)

--- a/src/backend/storage/lmgr/lock.c
> +++ b/src/backend/storage/lmgr/lock.c
> @@ -49,6 +49,8 @@
> #include "utils/ps_status.h"
> #include "utils/resowner_private.h"
>
> +#include <execinfo.h>
> +#include <dlfcn.h>
>
> /* This configuration variable is used to set the lock table size */
> int max_locks_per_xact; /* set by guc.c */

Why do you need these includes?

+ FreeFakeRelcacheEntry(rel);
> + } else
> + {
> + XLogFlush(lsn);
> + }

This code violates our coding style. According to it, "else" shouldn't
share its line with braces.

Also, patch definitely needs some general comment explaining what's going
on.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company