On 3 July 2017 at 21:08, Daniele Varrazzo wrote:
> Please open a bug to the psycopg bug tracker:
>
> https://github.com/psycopg/psycopg2/issues
>
> specifying your platform (win/linux/other, 32/64 bit). Please also add
> an idea of the number you are expecting to see (I think we should be
> able t
On 30 June 2017 at 06:24, ..: Mark Sloan :.. wrote:
> Hi all,
>
> Kind of new to a lot things here so if I am way off please correct me.
>
> using psycopg2 with postgres / greenplum / redshift it's now pretty easy to
> have a single query have a affected row count higher than it seems .rowcount
>
On Mon, Jul 18, 2011 at 5:28 PM, Federico Di Gregorio
wrote:
> On 18/07/11 11:25, James Henstridge wrote:
>> If all adapters that support transactions function like that, then I
>> think it would be sensible to require them to raise an error in that
>> case. If they don&
On Mon, Jul 18, 2011 at 3:52 PM, M.-A. Lemburg wrote:
> Vernon Cole wrote:
>> A cursor and/or a
>> connection should probably be context managers, so that they will work in a
>> "with" statement.
>
> This is was discussed before and it should probably go into
> the DB API in some form.
>
> I'm no
On Sat, Sep 25, 2010 at 12:04 AM, Daniele Varrazzo
wrote:
> On Fri, Sep 24, 2010 at 9:48 AM, M.-A. Lemburg wrote:
>
>> I'd also look around to check how other tools that interoperate with
>> PG in two-phase commits handle this. XA is a widely used standard
>> in the industry, so I assume the prob
2008/9/22 Vernon Cole <[EMAIL PROTECTED]>:
> Dear Pythonaholics:
>
> I have not been following the development of Python 2.6 and 3.0, so the
> following took me by surprise when I read it this morning. It seems to me on
> first glance, that this new feature, "Named Tuple", is exactly what is
> need
I dropped the ball a bit on this.
I took the last round of feedback and integrated it into a new version
of the specification. If people are happy with this, what is the next
step?
James.
Abstract
Many databases have support for two-phase commit. Adapters for some
of these databases e
On 24/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-24 15:36, M.-A. Lemburg wrote:
> > On 2008-01-24 02:44, James Henstridge wrote:
> >> I've had a bit more time to think about this, and have two proposals
> >> on how to handle transacti
On 25/01/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> This description suggests that the TM provides the "main" transaction
> identifier and the resource manager could add the branch part.
I guess the reason why the TM generally assigns the branch qualifiers
in XA systems is that it is in the
On 23/01/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote at 2008-1-22 20:31 +0100:
> > ...
> >Branch ids are used for e.g. multiple connections of the same RM
> >engaging in a global transaction. Each of those connections gets
> >its own branch id.
>
> But using multiple connec
On 24/01/2008, Stuart Bishop <[EMAIL PROTECTED]> wrote:
> James Henstridge wrote:
>
> > Proposal 1:
> > * Plain string IDs should work fine as transaction identifiers for
> > applications built from scratch with that assumption: they would
> > need to ide
On 23/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-23 02:18, James Henstridge wrote:
> >> [XID format used in XA]
> >> So, essentially, only the global transaction id and the branch id
> >> are relevant and both are represented in the data str
On 23/01/2008, Konjkov Vladimir <[EMAIL PROTECTED]> wrote:
> When I'm implementin on C my Python module that are used to access
> ODBC 2.0 database, I can't found description in PEP-0249 about the
> case when one .executeXXX follows another on the same cursor object.
>
> I think that after .exec
On 23/01/2008, Konjkov Vladimir <[EMAIL PROTECTED]> wrote:
> in definition of
> .execute(operation[,parameters])
> .
> A reference to the operation will be retained by the
> cursor. If the same operation object is passed in again,
> then the cursor can optimize its behavior.
The operation obje
On 22/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-22 12:33, James Henstridge wrote:
> > On 22/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> >> Thanks. I like it a lot, except for making the XID an object - this
> >> always appears to
On 22/01/2008, Stuart Bishop <[EMAIL PROTECTED]> wrote:
> It seems that the formatID is unnecessary and just a requirement of the XA C
> interface. Also, the xid() method you propose should be camelcase to match
> the other type constructors, so Xid(gtrid, bqual=None) or
> TransactionId(gtrid, bqua
On 22/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Thanks. I like it a lot, except for making the XID an object - this
> always appears to be a string in all the backends you've checked and
> also in the XA standard, so I'd go for a simple string instead of
> an object (those are always lots
On 22/01/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> James Henstridge wrote at 2008-1-21 23:40 +0900:
> > ...
> >= DB-API Two-Phase Commit =
> >
> >Many databases have support for two-phase commit. Adapters for some
> >of these databases expose t
On 21/01/2008, James Henstridge <[EMAIL PROTECTED]> wrote:
> On 18/01/2008, James Henstridge <[EMAIL PROTECTED]> wrote:
> > So is there any recommendations for what a two-phase commit API should
> > look like?
>
> I did a bit of investigation into a few databases,
On 21/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Sorry, I wasn't clear enough:
>
> If a connection fails and the transaction XID persists, how do you:
>
> * identify which XIDs are still pending (xa_recover)
>
> * tell the RM to drop all resources associacted with an XID
>(xa_forget)
On 21/01/2008, Federico Di Gregorio <[EMAIL PROTECTED]> wrote:
> > Perhaps an argument to xa_commit() would be appropriate here?
> >
> > connection.xa_commit(onephase=True)
> >
> > Without the argument, the commit would be considered to be a
> > ProgrammingError. That would reduce the chance o
On 21/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Thanks for the explanations. I was actually thinking of the
> connection between the TM and the RM (the database backend).
> The typical behavior of a TM is to cancel the ongoing
> two-phase commit transaction if an RM becomes unavailable.
On 21/01/2008, Federico Di Gregorio <[EMAIL PROTECTED]> wrote:
>
> Il giorno lun, 21/01/2008 alle 20.09 +0900, James Henstridge ha scritto:
> > > IMHO, it should raise an error if the transaction was started for
> > > two-phase. Otherwise I don't see any reas
On 21/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-21 11:28, Federico Di Gregorio wrote:
> > I agree with your analisys, I'll add some comments about the proposal
> > below.
> >
> > Il giorno lun, 21/01/2008 alle 19.08 +0900, James
On 21/01/2008, Federico Di Gregorio <[EMAIL PROTECTED]> wrote:
> I agree with your analisys, I'll add some comments about the proposal
> below.
>
> Il giorno lun, 21/01/2008 alle 19.08 +0900, James Henstridge ha scritto:
> > 1. Add a Connection.begin(...) me
On 18/01/2008, James Henstridge <[EMAIL PROTECTED]> wrote:
> So is there any recommendations for what a two-phase commit API should
> look like?
I did a bit of investigation into a few databases, and came up with a
proposal for an extension to the DB-API.
I know that there are a fe
On 19/01/2008, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> It does this indeed.
>
> And it assumes that a resource manager accepts a vote only
> when it can garantee that the subsequent "commit" will succeed (and
> does not fail).
>
> A resource manager needs to expose both a "vote" (with the above
On 18/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > If that has more than just 'prepare_transaction', 'commit_transaction' and
> > 'rollback_transaction' it has no place in the DB-API IMO. These three
> > actions are the entirety of what PostgreSQL provides and are the building
> > blocks y
On 18/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> > Looking at the IDataManager API, it looks like it looks like the
> > correct way to implement two phase commit would be:
> >
> > 1. if tpc_begin() is called, note that two-phase commit is being used.
> > 2. in commit(), simply prepare the
On 18/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> While this would seem desirable, it is not how the Zope TM
> works.
>
> Phase 1 is implemented by doing a vote on the success
> of the transaction. Phase 2 then finishes or aborts the transaction
> depending on the vote.
>
> If something fai
On 18/01/2008, Nand Rathi <[EMAIL PROTECTED]> wrote:
> Hello All
>
> Greetings
>
> I see a current thread regarding 2PC protocol, but my
> requirement is little different.
>
> I need to write some python programs which will access
> 2 databases simultaneously (Oracle & Postgresql). I
> need to use
On 18/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-18 09:37, James Henstridge wrote:
> > Hello,
> >
> > I've been looking at implementing two phase commit for the psycopg2
> > driver for PostgreSQL. It was suggested that I bring up the issue
Hello,
I've been looking at implementing two phase commit for the psycopg2
driver for PostgreSQL. It was suggested that I bring up the issue on
this list to see if there were any suggestions about what form the API
should take.
The API from the initial patch I produced stuck pretty close to the
33 matches
Mail list logo
