Re: Uber migrated from Postgres to MySQL

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: simon(at)2ndquadrant(dot)com
Cc: vik(at)2ndquadrant(dot)fr, chris(dot)travers(at)gmail(dot)com, scottm(at)openscg(dot)com, achill(at)matrix(dot)gatewaynet(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Uber migrated from Postgres to MySQL
Date: 2016-08-05 13:06:37
Message-ID: 20160805.220637.1874193968731231742.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>>> https://www.postgresql.org/docs/current/static/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK
>>
>> I wonder if their problem could be fixed by using
>> hot_standby_feedback. I have encountered similar problem but it seems
>> hot_standby_feedback was not any help in this case:
>>
>> https://www.postgresql.org/message-id/20130829.164457.863984798767991096.t-ishii%40sraoss.co.jp
>
> There have been various bugs and enhancements over the years, not all
> of which were backpatched.

The paticular case still does not work with PostgreSQL 9.5.3.

On primary:
create table t1(i int);
insert into t1 values(1),(2),(3);

On standby:
begin;
test=# select version();
version
--------------------------------------------------------------------------------------------------------
PostgreSQL 9.5.3 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4, 64-bit
(1 row)

select * from t1;
i
---
1
2
3
(3 rows)

On primary:
delete from t1;

On standby:
select * from t1;
i
---
(0 rows)

On primary:
test=# vacuum verbose t1;
INFO: vacuuming "public.t1"
INFO: "t1": removed 3 row versions in 1 pages
INFO: "t1": found 3 removable, 0 nonremovable row versions in 1 out of 1 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "t1": truncated 1 to 0 pages
DETAIL: CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM

After while on standby:
test=# select * from t1;
FATAL: terminating connection due to conflict with recovery
DETAIL: User was holding a relation lock for too long.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alex Ignatov 2016-08-05 13:30:02 Re: Question about wal files / pg_xlogs
Previous Message Michail Shurutov 2016-08-05 10:48:44 Re: how to replace last 4 digital phone number into star using regexp_replace?