Re: Storing a time interval

[Pankaj Jangid]

Steve Baldwin  writes:
> I agree with Michael. Another consideration is how the composite type is
> going to be handled in the DB layer of your processing code (e.g. node,
> python, ...).  In the scenario you described it seems unlikely you will be
> either having multiple columns of that type on your PO table, or using that
> composite type on a different table, so apart from the 'interest' factor,
> I'm not seeing any practical benefit.  Composite types are also slightly
> painful in the change they bring to the way you reference them. For example
> typically you need to surround the outer column in brackets - e.g.
> (dates).discount_last_date. If you are using an ORM library, does it know
> how to deal with that?
>

I faced a similar issue when using Enums with with rust lang. The Diesel
ORM didn't support it directly. Had to struggle with custom code in the
Model layer.

-- 
Pankaj Jangid

Merge sort/postgis performance tweaking?

[Israel Brewster]

I have the following query:

SELECT
read_date,
to_char(read_date,'-MM-DD') as text_date,
CASE WHEN lat_2>lat_1 THEN
ns_dist*-1
ELSE
ns_dist
END as ns_dist,
CASE WHEN lon_2>lon_1 THEN
ew_dist*-1
ELSE
ew_dist
END as ew_dist,
CASE WHEN alt_2>alt_1 THEN
(ud_dist*-1)::float
ELSE
ud_dist::float
END as ud_dist,
lat_e/10::float as lat_e,
lon_e/10::float as lon_e,
alt_e/10::float as alt_e,
CASE WHEN rapid THEN
1
ELSE
0
END as rapid
FROM
(SELECT
g1.read_date as read_date,
g1.rapid as rapid,
g1.lat as lat_1,
g1.lon as lon_1,
g1.alt as alt_1,
g2.lat as lat_2,
g2.lon as lon_2,
g2.alt as alt_2,
ST_Distance(ST_SetSRID( ST_Point( g1.lon, g1.lat), 
4326)::geography,
ST_SetSRID( ST_Point( g1.lon, g2.lat), 
4326)::geography)/1000 as ns_dist,
ST_Distance(ST_SetSRID( ST_Point( g1.lon, g1.lat), 
4326)::geography,
ST_SetSRID( ST_Point( g2.lon, g1.lat), 
4326)::geography)/1000 as ew_dist,
g1.alt-g2.alt ud_dist,
sqrt(g1.lat_e^2+g2.lat_e^2) as lat_e,
sqrt(g1.lon_e^2+g2.lon_e^2) as lon_e,
sqrt(g1.alt_e^2+g2.alt_e^2) as alt_e
FROM gps_data g1
INNER JOIN gps_data g2 ON g2.read_date=g1.read_date
WHERE g1.station=%s AND g2.station=%s
) g3
ORDER BY read_date;

Which, when executed on my system for a particular par of g1.station and 
g2.station takes about 190ms to run (explain output here: 
https://explain.depesz.com/s/8Nf9  ). This 
is not horrible, but when running this query for a dozen stations, it becomes 
noticeable. As such, I was wondering if I could do better. Looking at that 
explain output, I noticed that the largest time sink was the Merge Join at 
114ms. Some research into that gave me the command "set enable_mergejoin=off” 
which I tried just for fun to see what would happen. 

Somewhat to my surprise, this actually shaved a good 80ms off the total run 
time (see https://explain.depesz.com/s/kpncZ 
). Looking at that, I see it does a 
Parallel Hash Join, which looks like it should be slower, but I guess since it 
can do it in parallel, it winds up faster? Not sure on that, but the overall 
time is definitely significantly faster. Which leaves me with a couple of 
questions:

1) Since not using a merge join is, in this case apparently better, is there 
some way I can tweak the query/settings such that it knows this without having 
to force the merge join off?

2) If not, are there any side effects/gotchas I should be aware of if I simply 
call that set command before each query (or, presumably before the series of 
queries)?

3) Is there anything else I can do to optimize the query? I have tried using a 
pre-calculated point column rather than calculating ST_Point( g1.lon, g1.lat), 
as well as providing “false” as the last argument to ST_Distance, but while 
these did speed things up some, it was only about 10ms or so, so not terribly 
significant.

If it helps, the goal behind the somewhat odd arguments to ST_Distance is to 
find the component North/South and East/West distances, rather than the actual 
total “point a to point b” distance. Perhaps there is a better way of obtaining 
that goal?

---
Israel Brewster
Software Engineer
Alaska Volcano Observatory 
Geophysical Institute - UAF 
2156 Koyukuk Drive 
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145

Re: Storing a time interval

[Steve Baldwin]

I agree with Michael. Another consideration is how the composite type is
going to be handled in the DB layer of your processing code (e.g. node,
python, ...).  In the scenario you described it seems unlikely you will be
either having multiple columns of that type on your PO table, or using that
composite type on a different table, so apart from the 'interest' factor,
I'm not seeing any practical benefit.  Composite types are also slightly
painful in the change they bring to the way you reference them. For example
typically you need to surround the outer column in brackets - e.g.
(dates).discount_last_date. If you are using an ORM library, does it know
how to deal with that?

Steve

On Sat, Nov 9, 2019 at 8:11 AM Michael Lewis  wrote:

> CREATE TYPE po_dates AS (
>> po_isssued_datetimestamptz,
>> discount_last_date timestamptz,
>> net_date   timestamptz
>> );
>>
>
> What advantage does combining these three values into a custom composite
> type give you rather than just storing directly? Are you going to reuse
> this po_dates type on many tables?
>

Re: Storing a time interval

[Michael Lewis]

> CREATE TYPE po_dates AS (
> po_isssued_datetimestamptz,
> discount_last_date timestamptz,
> net_date   timestamptz
> );
>

What advantage does combining these three values into a custom composite
type give you rather than just storing directly? Are you going to reuse
this po_dates type on many tables?

Re: firewall trouble on Windows

[Adrian Klaver]

On 11/8/19 12:41 PM, Boylan, Ross wrote:

I have a physical machine H (host) running a virtual machine V.  Both are Win 
10 64 bit; vmware provides the virtualization.
Symantec EndPoint Protection (SEP) on H is blocking attempts to connect to my 
postgres 12 server  running on V.  I am trying to get it to permit the 
necessary traffic.

I'm pretty sure the installation of postgres takes care of this automatically:
1) SEP is running on V, but does not block the traffic (after disabling SEP on 
H)
2) H allowed the traffic a week ago and only started blocking after I 
uninstalled PG 11 from H.

So my guess is there is some fairly generic way of requesting access.  But I 
don't know what it is.  Any ideas, or pointers to the Windows installation code 
that's doing this?

There are instructions on the net for allowing access via Windows Firewall.  
But that is disabled on H, and all the configuration options take me to SEP.  
SEP allows exceptions, but I haven't found anything that looks like a firewall 
exception (as opposed to a virus or file exception).  Our admins have also not 
found out how to pull this off.


?:

https://support.symantec.com/us/en/article.howto80775.html


Thanks.
Ross Boylan




--
Adrian Klaver
adrian.kla...@aklaver.com

firewall trouble on Windows

[Boylan, Ross]

I have a physical machine H (host) running a virtual machine V.  Both are Win 
10 64 bit; vmware provides the virtualization.
Symantec EndPoint Protection (SEP) on H is blocking attempts to connect to my 
postgres 12 server  running on V.  I am trying to get it to permit the 
necessary traffic.

I'm pretty sure the installation of postgres takes care of this automatically:
1) SEP is running on V, but does not block the traffic (after disabling SEP on 
H)
2) H allowed the traffic a week ago and only started blocking after I 
uninstalled PG 11 from H.

So my guess is there is some fairly generic way of requesting access.  But I 
don't know what it is.  Any ideas, or pointers to the Windows installation code 
that's doing this?

There are instructions on the net for allowing access via Windows Firewall.  
But that is disabled on H, and all the configuration options take me to SEP.  
SEP allows exceptions, but I haven't found anything that looks like a firewall 
exception (as opposed to a virus or file exception).  Our admins have also not 
found out how to pull this off.

Thanks.
Ross Boylan

Re: Storing a time interval

[stan]

On Fri, Nov 08, 2019 at 12:12:59PM -0800, Adrian Klaver wrote:
> On 11/8/19 11:57 AM, Michael Lewis wrote:
> > You certainly could choose to store as??tstzrange, but why not use two
> > fields?
> > 
> > https://www.postgresql.org/docs/current/rangetypes.html
> 
> I would lean more to a composite type:
> 
> https://www.postgresql.org/docs/11/rowtypes.html
> 
> Range types are built around looking for values within the range, whereas
> the OP is looking for two discrete values. The two field method you suggest
> above also encapsulates that.
> 
Thanks folks. 

After thinking over both your sugestions, I beleive teh optimum way to do this
may look like:


CREATE TYPE po_dates AS (
po_isssued_datetimestamptz,
discount_last_date timestamptz,
net_date   timestamptz
);

-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin

Re: Storing a time interval

[Adrian Klaver]

On 11/8/19 11:57 AM, Michael Lewis wrote:
You certainly could choose to store as tstzrange, but why not use two 
fields?


https://www.postgresql.org/docs/current/rangetypes.html


I would lean more to a composite type:

https://www.postgresql.org/docs/11/rowtypes.html

Range types are built around looking for values within the range, 
whereas the OP is looking for two discrete values. The two field method 
you suggest above also encapsulates that.





--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Storing a time interval

[Michael Lewis]

You certainly could choose to store as tstzrange, but why not use two
fields?

https://www.postgresql.org/docs/current/rangetypes.html

pg_logical for RHEL 8

[Olivier Gautherot]

Hi folks,

We are installing a server with RHEL 8, installing PG 11 was a child's play
but pg_logical is apparently not available. We followed the instructions
in  https://dl.2ndquadrant.com/default/release/site/ but yum does not find
the packages.

Following this documentation, I eventually found a link to the repository:
https://dl.2ndquadrant.com/default/release/browse/rpm/

and realised that RHEL 8 is not there yet.

As a workaround, we installed the release for RHEL 7, which seems to work.

Does someone have a date for the official release of the support for RHEL8?


Thanks in advance
--
Olivier Gautherot
https://www.linkedin.com/in/ogautherot/

Storing a time interval

[stan]

I need to create a table to store terms and conditions for purchase
orders.

Some of the attributes of a PO include payment terms. Quite often these will
be 2 periods associated with these, the first is a period on which if you
pay, you receive a discount, and the 2nd is when payment is due with no
discount. I am thinking of storing these two attributes as time internals.

What is the wisdom as to how to declare the type of these columns?


-- 
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin

Re: AW: AW: AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Brad Nicholson]

"Zwettler Markus (OIZ)"  wrote on 2019/11/08
11:54:14 AM:

> > (please don't top post, makes the replies hard to follow)
>
> > patronictl switchover 
>
> > follow the prompts
>
> > there is also a /switchover API endpoint you can use.
>
> > Brad
>
> I wondered about your "patronictl switchover + systemd" hint. How
> would you do ("gate") this combination?


Change whatever process you are using today to shut things down to call the
patroni switchover first, check error codes, etc.

AW: AW: AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Zwettler Markus (OIZ)]

?  "Zwettler Markus (OIZ)" 
mailto:markus.zwett...@zuerich.ch>> wrote on 
2019/11/08 11:27:00 AM:

>> From: "Zwettler Markus (OIZ)" 
>> mailto:markus.zwett...@zuerich.ch>>
>> To: Brad Nicholson mailto:br...@ca.ibm.com>>
>> Cc: Adrian Klaver 
>> mailto:adrian.kla...@aklaver.com>>, "pgsql-
>> gene...@lists.postgresql.org" 
>> mailto:pgsql-general@lists.postgresql.org>>
>> Date: 2019/11/08 11:27 AM
>>> Subject: [EXTERNAL] AW:  AW:  AW:  AW: AW: AW: broken backup trail
>> in case of quickly patroni switchback and forth
>>
>> How exactly? Please clarify.

> (please don't top post, makes the replies hard to follow)

> patronictl switchover 

> follow the prompts

> there is also a /switchover API endpoint you can use.

> Brad



I wondered about your "patronictl switchover + systemd" hint. How would you do 
("gate") this combination?

Markus

Re: AW: AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Brad Nicholson]

"Zwettler Markus (OIZ)"  wrote on 2019/11/08
11:27:00 AM:

> From: "Zwettler Markus (OIZ)" 
> To: Brad Nicholson 
> Cc: Adrian Klaver , "pgsql-
> gene...@lists.postgresql.org" 
> Date: 2019/11/08 11:27 AM
> Subject: [EXTERNAL] AW:  AW:  AW:  AW: AW: AW: broken backup trail
> in case of quickly patroni switchback and forth
>
> How exactly? Please clarify.

(please don't top post, makes the replies hard to follow)

patronictl switchover 

follow the prompts

there is also a /switchover API endpoint you can use.

Brad

AW: AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Zwettler Markus (OIZ)]

How exactly? Please clarify.



"Zwettler Markus (OIZ)" 
mailto:markus.zwett...@zuerich.ch>> wrote on 
2019/11/08 11:02:49 AM:

> From: "Zwettler Markus (OIZ)" 
> mailto:markus.zwett...@zuerich.ch>>
> To: Brad Nicholson mailto:br...@ca.ibm.com>>
> Cc: Adrian Klaver 
> mailto:adrian.kla...@aklaver.com>>, "pgsql-
> gene...@lists.postgresql.org" 
> mailto:pgsql-general@lists.postgresql.org>>
> Date: 2019/11/08 11:02 AM
> Subject: [EXTERNAL] AW:  AW:  AW: AW: AW: broken backup trail in
> case of quickly patroni switchback and forth
>
> Let me clarify: "But, it might start killing processes after a
> certain period if a _fast_ shutdown after SIGTERM didn't happen".
>
> I am talking about stopping the Patroni master process with a systemd scipt.


Use the switchover functionality in Patroni first, and gate youur shutdown via 
systemd on the success of that operation.

Brad.

Re: AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Brad Nicholson]

"Zwettler Markus (OIZ)"  wrote on 2019/11/08
11:02:49 AM:

> From: "Zwettler Markus (OIZ)" 
> To: Brad Nicholson 
> Cc: Adrian Klaver , "pgsql-
> gene...@lists.postgresql.org" 
> Date: 2019/11/08 11:02 AM
> Subject: [EXTERNAL] AW:  AW:  AW: AW: AW: broken backup trail in
> case of quickly patroni switchback and forth
>
> Let me clarify: "But, it might start killing processes after a
> certain period if a _fast_ shutdown after SIGTERM didn't happen".
>
> I am talking about stopping the Patroni master process with a systemd
scipt.


Use the switchover functionality in Patroni first, and gate youur shutdown
via systemd on the success of that operation.

Brad.

AW: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Zwettler Markus (OIZ)]

Let me clarify: "But, it might start killing processes after a certain period 
if a _fast_ shutdown after SIGTERM didn't happen".

I am talking about stopping the Patroni master process with a systemd scipt.



Von: Brad Nicholson 
Gesendet: Freitag, 8. November 2019 15:58
An: Zwettler Markus (OIZ) 
Cc: Adrian Klaver ; 
pgsql-general@lists.postgresql.org
Betreff: Re: AW: AW: AW: AW: broken backup trail in case of quickly patroni 
switchback and forth


"Zwettler Markus (OIZ)" 
mailto:markus.zwett...@zuerich.ch>> wrote on 
2019/11/08 07:51:33 AM:

> From: "Zwettler Markus (OIZ)" 
> mailto:markus.zwett...@zuerich.ch>>
> To: Brad Nicholson mailto:br...@ca.ibm.com>>
> Cc: Adrian Klaver 
> mailto:adrian.kla...@aklaver.com>>, "pgsql-
> gene...@lists.postgresql.org" 
> mailto:pgsql-general@lists.postgresql.org>>
> Date: 2019/11/08 07:51 AM
> Subject: [EXTERNAL] AW:  AW: AW: AW: broken backup trail in case of
> quickly patroni switchback and forth
>
> It depends. It is a switchover if Patroni could to a clean shutdown.
> But, it might start killing processes after a certain period if a
> normal shutdown after SIGTERM didn't happen. This would not be a
> switchover anymore. In other words there is no guarantee for a
> "clean" switchover. This might be the reason why the Patroni guys
> are always talking about failover only.


If it can't do a clean shutdown, that points to something wrong with Postgres 
itself.  Why doesn't a fast shutdown work for you in those cases?

> It's not a Patroni issue but it's triggered by Patroni as it will do
> "some kind of switchover" on a regular shutdown.

Sure, but you should be looking at why Postgres can't cleanly shutdown.

How are you telling Patroni to switchover? Are you using the Patroni switchover 
command via patronictl or the API, or sending a signal to the Patroni process?  
I think the explicit switchover
command will not behave this way.  It will return you a 503 if it can't 
switchover and not change the primary (that is something you can confirm with 
the Patroni developers).

Brad.

Re: INOUT PARAMETERS WITH RETURN TABLES IN FUNCTION

[Adrian Klaver]

On 11/8/19 12:18 AM, İlyas Derse wrote:
I'm trying to migration to PostgreSql from SQL Server.  I have Stored 
Procedures what have output parameters and return tables. How can i do 
both together.


Can you show an example of a SQL Server procedure that demonstrates what 
you want to achieve?




Its like ;

CREATE or replace FUNCTION public."test" (INOUT "x" integer, INOUT "y" 
character varying(36))


RETURNS TABLE  (
"id" integer,
"filesize" character varying(36)
)
AS $$
  BEGIN
   x=6;
RETURN QUERY
SELECT * FROM    public."tbl_employees" ;

END;
$$ LANGUAGE plpgsql;

I can not create that because of inout parameters.
Another place;

do $$
DECLARE b integer = 1;
DECLARE d integer = 2 ;
BEGIN
   select * from public."test"();
END;
$$;

  Anybody have an idea ?



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: AW: AW: AW: AW: broken backup trail in case of quickly patroni switchback and forth

[Brad Nicholson]

"Zwettler Markus (OIZ)"  wrote on 2019/11/08
07:51:33 AM:

> From: "Zwettler Markus (OIZ)" 
> To: Brad Nicholson 
> Cc: Adrian Klaver , "pgsql-
> gene...@lists.postgresql.org" 
> Date: 2019/11/08 07:51 AM
> Subject: [EXTERNAL] AW:  AW: AW: AW: broken backup trail in case of
> quickly patroni switchback and forth
>
> It depends. It is a switchover if Patroni could to a clean shutdown.
> But, it might start killing processes after a certain period if a
> normal shutdown after SIGTERM didn't happen. This would not be a
> switchover anymore. In other words there is no guarantee for a
> "clean" switchover. This might be the reason why the Patroni guys
> are always talking about failover only.


If it can't do a clean shutdown, that points to something wrong with
Postgres itself.  Why doesn't a fast shutdown work for you in those cases?

> It's not a Patroni issue but it's triggered by Patroni as it will do
> "some kind of switchover" on a regular shutdown.

Sure, but you should be looking at why Postgres can't cleanly shutdown.

How are you telling Patroni to switchover? Are you using the Patroni
switchover command via patronictl or the API, or sending a signal to the
Patroni process?  I think the explicit switchover
command will not behave this way.  It will return you a 503 if it can't
switchover and not change the primary (that is something you can confirm
with the Patroni developers).

Brad.

Re: SQL SERVER migration to PostgreSql

[SERHAD ERDEM]

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

CREATE OR REPLACE FUNCTION get_film (p_pattern VARCHAR)

RETURNS TABLE (

film_title VARCHAR,

film_release_year INT

)

AS $$

BEGIN

RETURN QUERY SELECT

title,

cast( release_year as integer)

FROM

film

WHERE

title ILIKE p_pattern ;

END; $$



LANGUAGE 'plpgsql';





2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

CREATE OR REPLACE FUNCTION get_film (p_pattern VARCHAR,p_year INT)

RETURNS TABLE (

film_title VARCHAR,

film_release_year INT

) AS $$

DECLARE

var_r record;

BEGIN

FOR var_r IN(SELECT

title,

release_year

FROM film

WHERE title ILIKE p_pattern AND

release_year = p_year)

LOOP

film_title := upper(var_r.title) ;

film_release_year := var_r.release_year;

RETURN NEXT;

END LOOP;

END; $$

LANGUAGE 'plpgsql';


From: İlyas Derse 
Sent: Thursday, November 7, 2019 1:28 PM
To: pgsql-general@lists.postgresql.org 
Subject: SQL SERVER migration to PostgreSql

I'm trying to migration to PostgreSql from SQL Server. I have Stored Procedures 
what have output parameters and returning tables.But you know what, we can not 
returning tables in stored procedures in PostgreSql and we can not use output 
parameters in functions in PostgreSql.

So i did not find to solves this problem. Anybody have an idea ?

Re: INOUT PARAMETERS WITH RETURN TABLES IN FUNCTION

[Thomas Kellerer]

İlyas Derse schrieb am 08.11.2019 um 09:18:
> I'm trying to migration to PostgreSql from SQL Server.  I have Stored 
> Procedures what have output parameters and return tables. How can i do both 
> together. 
> 
> CREATE or replace FUNCTION public."test" (INOUT "x" integer, INOUT "y" 
> character varying(36))
> RETURNS TABLE  (
> "id" integer,
> "filesize" character varying(36)
> )
> AS $$
>  BEGIN
>   x=6;
> RETURN QUERY
> SELECT * FROM    public."tbl_employees" ;
> 
> END;
> $$ LANGUAGE plpgsql;
> 
> I can not create that because of inout parameters.
> Another place;
> 
> do $$
> DECLARE b integer = 1;
> DECLARE d integer = 2 ;
> BEGIN
>   select * from public."test"();
> END;
> $$;
> 
>  Anybody have an idea ? 


Can't you just include the "out" parameters in the result? 

CREATE or replace FUNCTION public.test(x integer, y character varying(36))
  RETURNS TABLE  (id integer, filesize character varying(36), x integer, y 
varchar)
AS $$
begin
  x := 42;
  y := 'foo';
  
  RETURN QUERY
SELECT t.*, x, y 
FROM  public.tbl_employees t;
END;

It's different because x and y are repeated for every row, but that's the only 
thing I can think of.

INOUT PARAMETERS WITH RETURN TABLES IN FUNCTION

[İlyas Derse]

I'm trying to migration to PostgreSql from SQL Server.  I have Stored
Procedures what have output parameters and return tables. How can i do both
together.

Its like ;

CREATE or replace FUNCTION public."test" (INOUT "x" integer, INOUT "y"
character varying(36))

RETURNS TABLE  (
"id" integer,
"filesize" character varying(36)
)
AS $$
 BEGIN
  x=6;
RETURN QUERY
SELECT * FROMpublic."tbl_employees" ;

END;
$$ LANGUAGE plpgsql;

I can not create that because of inout parameters.
Another place;

do $$
DECLARE b integer = 1;
DECLARE d integer = 2 ;
BEGIN
  select * from public."test"();
END;
$$;

 Anybody have an idea ?

AW: broken backup trail in case of quickly patroni switchback and forth

[Zwettler Markus (OIZ)]

1) If I got you right this means enabling archiving on both machines 
(archive_mode=on, archive_command=cp...). Yes?

2) Will the latest transactions on the actual primary be archived (copied from 
pg_xlog to the local archive_directory) before this primary is reinstated as 
new standby?

Thanks,
Markus



On Thu, 2019-11-07 at 13:52 +, Zwettler Markus (OIZ) wrote:
> we are using Patroni for management of our Postgres standby databases.
> 
> we take our (wal) backups on the primary side based on intervals and 
> thresholds.
> our archived wal's are written to a local wal directory first and moved to 
> tape afterwards.
> 
> we got a case where Patroni switched back and forth sides quickly, e.g.:
> 12:00h: primary - standby
> 12:05h: standby - primary
> 12:10h: primary - standby
> 
> we realised that we will not have a wal backup of those wal's generated 
> between 12:05h and 12:10h in this scenario.
> 
> how can we make sure that the whole wal sequence trail will be backuped? any 
> idea?

You'll have to archive WAL from both machines.  Then you have everything you 
should need.

Make sure "recovery_target_timeline = 'latest'" so that recovery will follow 
the timeline jumps.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com