Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?
Дата
Msg-id 4F8557B80200002500046DD4@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?  (Michael Nolan <htfoot@gmail.com>)
Ответы Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?
Список pgsql-hackers
Michael Nolan <htfoot@gmail.com> wrote:
> On 4/11/12, 乔志强 <qiaozhiqiang@leadcoretech.com> wrote:

>> But when a transaction larger than 1GB...
>
> Then you may need WAL space larger than 1GB as well.  For
> replication to work, it seems likely that you may need to have
> sufficient WAL space to handle a row, possibly the entire
> transaction..  But since a single statement can update thousands
> or millions of rows, do you always need enough WAL space to hold
> the entire transaction?

No.

>>   Does master send WAL to standby before the transaction commit ?

Yes.

> A related question is what happens if there is a rollback?

PostgreSQL doesn't use a rollback log; WAL files can be reclaimed as
soon as the work they represent has been persisted to the database
by a CHECKPOINT, even if it is not committed.  Because there can be
multiple versions of each row in the base table, each with its own
xmin (telling which transaction committed it) and xmax (telling
which transaction expired it) visibiliity checking can handle the
commits and rollbacks correctly.  It also uses a commit log (CLOG),
hint bits, and other structures to help resolve visibility.  It is a
complex topic, but it does work.

-Kevin

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Last gasp
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Last gasp