Re: Speedup twophase transactions

Nikhil Sontakke <nikhils@2ndquadrant.com>

From: Nikhil Sontakke <nikhils@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: David Steele <david@pgmasters.net>, Stas Kelvich <s.kelvich@postgrespro.ru>, Simon Riggs <simon@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Jesper Pedersen <jesper.pedersen@redhat.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2017-03-17T07:39:16Z
Lists: pgsql-hackers
>
> Nikhil, do you mind if I try something like that? As we already know
> what is the first XID when beginning redo via
> ShmemVariableCache->nextXid it is possible to discard 2PC files that
> should not be here.


Yeah, that is ok.


> What makes me worry is the control of the maximum
> number of entries in shared memory. If there are legit 2PC files that
> are flushed on disk at checkpoint, you would finish with potentially
> more 2PC transactions than what should be possible (even if updates of
> max_prepared_xacts are WAL-logged).
>

The max_prepared_xacts number restricts the number of pending PREPARED
transactions *across* the 2PC files and shmem inredo entries. We can never
have more entries than this value.


Regards,
Nikhils
-- 
 Nikhil Sontakke                   http://www.2ndQuadrant.com/
 PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services

Commits

  1. Speedup 2PC recovery by skipping two phase state files in normal path

  2. Add tests for two-phase commit

  3. Improve grammar of message about two-phase state files.

  4. Speedup 2PC by skipping two phase state files in normal path