Re: Problems with Binary Replication

Поиск
Список
Период
Сортировка
От Andreas
Тема Re: Problems with Binary Replication
Дата
Msg-id 4F779A0A.4000809@gmx.net
обсуждение исходный текст
Ответ на Re: Problems with Binary Replication  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Problems with Binary Replication  (Michael Nolan <htfoot@gmail.com>)
Список pgsql-general
Am 31.03.2012 23:38, schrieb Tom Lane:
> Andreas<maps.on@gmx.net>  writes:
>> Now I added 1 row on the master.
>> Before both sequence start values were 403.
>> After the insert the master shows 404 as expected but the "hot-standby"
>> shows 436.
> What are you doing to get it to "show" a value --- not nextval(),
> presumably?
>
> I think that this may be the expected behavior from pre-caching of
> sequence values.  You would see the same thing on the master if you
> were to forcibly crash and restart it.
>
>             regards, tom lane
>

I checked with pgAdmin.
Even with nextval() the sequence shouldn't move because AFAIK a
hot-standby is readonly.

The sequence on the hot-standby jumped 32 counters when I inserted a row
on the master.
Before the insert it had the same value as the master.

Actually I stumbled over it, when I worked on a test pc to prepare some
sql updates for the master.
I installed there a backup from the hot-standby because I expected this
should mirror the master 1:1.
At least those tables where only I insert stuff.

I was worried because I thought there is a serious issue.

Now what could one do to prevent those sequence gaps?
There might be scenarios where it's important not to have gaps in the
numbering even when one has to switch to the standby if there is a
failiour on the master.
E.g. numbers of invoices need to be gapless.


Thanks for the reply
:)




В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Re: pg_dump incredibly slow dumping a single schema from a large db
Следующее
От: Jasen Betts
Дата:
Сообщение: Re: loading a function from a file