Skip site navigation (1) Skip section navigation (2)

Re: Speed dblink using alternate libpq tuple storage

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
To: markokr(at)gmail(dot)com
Cc: greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com
Subject: Re: Speed dblink using alternate libpq tuple storage
Date: 2012-02-27 08:20:30
Message-ID: 20120227.172030.48560991.horiguchi.kyotaro@oss.ntt.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello, 

> On OOM, the old result is freed to have higher chance that
> constructing new result succeeds.  But if we want to transport
> error message, we need to keep old PGresult around.  Thus
> two separate paths.

Ok, I understood the aim. But now we can use non-local exit to do
that for not only asynchronous reading (PQgetResult()) but
synchronous (PQexec()). If we should provide a means other than
exceptions to do that, I think it should be usable for both
syncronous and asynchronous reading. conn->asyncStatus seems to
be used for the case.

Wow is the modification below?

- getAnotherTuple() now returns 0 to continue as before, and 1
  instead of EOF to signal EOF state, and 2 to instruct to exit
  immediately.

- pqParseInput3 set conn->asyncStatus to PGASYNC_BREAK for the
  last case,

- then PQgetResult() returns immediately when
  asyncStatus == PGASYNC_TUPLES_BREAK after parseInput() retunes.

- and PQexecFinish() returns immediately if PQgetResult() returns
  with aysncStatys == PGASYNC_TUPLES_BREAK.

- PGgetResult() sets asyncStatus = PGRES_TUPLES_OK if called with
  asyncStatus == PGRES_TUPLES_BREAK

- New libpq API PQisBreaked(PGconn*) returns if asyncStatus ==
  PGRES_TUPLES_BREAK can be used to check if the transfer is breaked.

> Instead use ("%s", errmsg) as argument there.  libpq code
> is noisy enough, no need to add more.

Ok. I will do so.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-02-27 08:50:34
Subject: Re: Initial 9.2 pgbench write results
Previous:From: Koichi SuzukiDate: 2012-02-27 08:16:42
Subject: Re: 3rd Cluster Hackers Summit, May 15th in Ottawa

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group