Re: Two-phase commmit, plpgsql and plproxy

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Igor Katson <descentspb(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Two-phase commmit, plpgsql and plproxy
Date: 2009-02-11 22:23:12
Message-ID: 1234390992.21038.13.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 2009-02-12 at 00:57 +0300, Igor Katson wrote:
> Thanks, Jeff. That's not good news, cause I am not able to do that.

There may be some creative solution, but I don't know plproxy well
enough to suggest one.

> The postgres manual says, that
> " The intended usage of the feature is that a prepared transaction will
> normally be committed or rolled back as soon as an external transaction
> manager has verified that other databases are also prepared to commit. "
>
> So does this "external transaction manager" exist? I am not clear about
> what it is.

PostgreSQL does not provide a transaction manager.

When you are dealing with multiple databases, the transaction manager
needs to make decisions like "this transaction failed on one node,
therefore we need to roll all the other transactions back".

I think you are basically trying to make plproxy into the transaction
manager. You might get some better suggestions from people who know
plproxy well.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Inigo Barandiaran 2009-02-11 22:24:13 Re: createdb.exe and psql.exe without Promting Password
Previous Message Fernando Moreno 2009-02-11 22:09:29 Re: Saber cuando se dispara el trigger (After: insert,update,delete)