[HACKERS] 9.2 release schedule
What are our plans for a 9.2 final release date? If we wait until September 1 to release our first release candidate, we will probably not release final until mid/late September. Is that what we want? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Using pg_upgrade on log-shipping standby servers
On fre, 2012-07-20 at 13:11 -0400, Bruce Momjian wrote:
I think the commands to run after pg_upgrade --link completes on both
primary and standby might be as easy as:
cd /u/pg/pgsql.old/data
find . -links 1 -exec cp {} /u/pgsql/data \;
Why would we want anything more complicated than this?
In practice these are on different machines, and the way the machines
are connected could vary wildly. So an automated solution might be
difficult to find.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resetting libpq connections after an app error
On Sat, Jul 21, 2012 at 01:08:58AM +0100, Daniele Varrazzo wrote:
Hello,
apologize for bumping the question to -hackers but I got no answer
from -general. If there is a better ML to post it let me know.
In a libpq application, if there is an application error between
PQsendQuery and PQgetResult, is there a way to revert a connection
back to an usable state (i.e. from transaction status ACTIVE to IDLE)
without using the network in a blocking way? We are currently doing
while (NULL != (res = PQgetResult(conn-pgconn))) {
PQclear(res);
}
but this is blocking, and if the error had been caused by the network
down, we'll just get stuck in a poll() waiting for a timeout.
There is PQreset(), which also exists in a non-blocking variant.
Hope this helps,
--
Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/
He who writes carelessly confesses thereby at the very outset that he does
not attach much importance to his own thoughts.
-- Arthur Schopenhauer
signature.asc
Description: Digital signature
Re: [HACKERS] Using pg_upgrade on log-shipping standby servers
On Sat, Jul 21, 2012 at 11:24:21AM +0300, Peter Eisentraut wrote:
On fre, 2012-07-20 at 13:11 -0400, Bruce Momjian wrote:
I think the commands to run after pg_upgrade --link completes on both
primary and standby might be as easy as:
cd /u/pg/pgsql.old/data
find . -links 1 -exec cp {} /u/pgsql/data \;
Why would we want anything more complicated than this?
In practice these are on different machines, and the way the machines
are connected could vary wildly. So an automated solution might be
difficult to find.
Yeah, I was thinking of just suggesting scp as a doc example and let
users adjust that:
cd /u/pg/pgsql.old/data
find . -links 1 -exec scp {} postg...@momjian.us:/u/pgsql/data \;
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 release schedule
On 21 July 2012 08:08, Bruce Momjian br...@momjian.us wrote: What are our plans for a 9.2 final release date? If we wait until September 1 to release our first release candidate, we will probably not release final until mid/late September. Is that what we want? Personally I had hoped to see an earlier release date than that. Can we finish the 9.2 release notes? -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Event Triggers reduced, v1
On Fri, Jul 20, 2012 at 3:51 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Jul 20, 2012 at 2:12 PM, Tom Lane t...@sss.pgh.pa.us wrote: The Windows buildfarm members don't seem too happy with the latest patch. I'm looking at this now, but am so far mystified. Something's obviously broken as regards how the trigger flags get set up, but if that were broken in a trivial way it would be broken everywhere, and it's not. Will keep searching... I think this is fixed now. Let me know if anyone sees evidence of remaining breakage. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resetting libpq connections after an app error
Martijn van Oosterhout klep...@svana.org writes: On Sat, Jul 21, 2012 at 01:08:58AM +0100, Daniele Varrazzo wrote: In a libpq application, if there is an application error between PQsendQuery and PQgetResult, is there a way to revert a connection back to an usable state (i.e. from transaction status ACTIVE to IDLE) without using the network in a blocking way? We are currently doing There is PQreset(), which also exists in a non-blocking variant. Note that PQreset essentially kills the connection and establishes a new one, which might not be what Daniele is looking for. The alternative approach is to issue PQcancel and then just let the query flush out as you normally would in an async application, ie PQisBusy/PQconsumeInput until ready, then PQgetResult (which you throw away), repeat until you get NULL. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 release schedule
Peter Geoghegan pe...@2ndquadrant.com writes: On 21 July 2012 08:08, Bruce Momjian br...@momjian.us wrote: What are our plans for a 9.2 final release date? If we wait until September 1 to release our first release candidate, we will probably not release final until mid/late September. Is that what we want? Personally I had hoped to see an earlier release date than that. Me too, but we are running out of time ... it's already late July. I think the immediate goal must be to clear the list of open issues http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items and then get another beta out. It seems unlikely that we could do a beta next week (for one thing, certain key people are going to be out sailing...) but maybe we could schedule the next beta for first Monday in August? That gives us about ten days to get the open issues dealt with before wrapping. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] libpq one-row-at-a-time API
Here is 2 approaches how to get to state where only PQsetSingleRowMode() is available. Both on top of REL9_2_STABLE branch. a) Remove callback hooks, keep rowBuf, implement single-row-mode on top of that. This was posted before, I just additionally removed the PQgetRowData() function. git pull git://github.com/markokr/postgres.git single-row-mode1 https://github.com/markokr/postgres/commits/single-row-mode1 Commits: libpq: Single-row based processing libpq, dblink: Remove row processor API Advantage: makes easier to play with PQgetRowData() or potatial faster PGresult creation methods. Smaller change compared to libpq from 9.2beta than b). b) Revert row-callback changes completely, implement single-row-mode on top of virgin libpq. Only problem here was keeping fixes implemented as part of row-callback patch. Single-row-mode itself is quite simple. git pull git://github.com/markokr/postgres.git single-row-mode1 https://github.com/markokr/postgres/commits/single-row-mode1 Feature patch: https://github.com/markokr/postgres/commit/b5e822125c655f189875401c61317242705143b9 Commits: dblink: revert conversion to row processor API patch libpq: revert row processor API patch libpq: random fixes libpq: single-row mode dblink: use single-row-mode Advantage: smaller change compared to libpq from 9.1 than a). As the patch has suffered a lot from trying to provide both macro- and micro-optimization (on-the-fly row processing vs. more efficient row processing), maybe b) is safer choice for 9.2? In case somebody wants to look at the patches without git (or web), I attaches them as tgz too. -- marko single-row.tgz Description: GNU Unix tar archive -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 release schedule
I wrote: Peter Geoghegan pe...@2ndquadrant.com writes: On 21 July 2012 08:08, Bruce Momjian br...@momjian.us wrote: What are our plans for a 9.2 final release date? If we wait until September 1 to release our first release candidate, we will probably not release final until mid/late September. Is that what we want? Personally I had hoped to see an earlier release date than that. Me too, but we are running out of time ... it's already late July. I think the immediate goal must be to clear the list of open issues http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items and then get another beta out. It looks like the most optimistic schedule we could possibly make, assuming no show-stopper bugs are reported, is: * Wrap beta3 on August 2 for release Monday Aug 6 * RC1 two weeks later (release Aug 20) * 9.2.0 two weeks after that (release Sept 3) Now that schedule isn't actually going to work so far as the USA contingent is concerned, because Sept 3 is Labor Day. But we could figure that there's room for one week's slip in there, either for RC1 or final, giving us a release date of Sept 10. Again, this is assuming no major bugs are found to force more slippage or additional betas/RCs. But I think it's reasonable to shoot for If All Goes Well. Comments, objections? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [patch] libpq one-row-at-a-time API
Marko Kreen mark...@gmail.com writes: Here is 2 approaches how to get to state where only PQsetSingleRowMode() is available. Both on top of REL9_2_STABLE branch. a) Remove callback hooks, keep rowBuf, implement single-row-mode on top of that. This was posted before, I just additionally removed the PQgetRowData() function. b) Revert row-callback changes completely, implement single-row-mode on top of virgin libpq. Only problem here was keeping fixes implemented as part of row-callback patch. Single-row-mode itself is quite simple. Yeah, I was wondering if we shouldn't revisit the whole patch given that where we're ending up looks little like where we thought we were going. I hadn't had time to pursue the idea, but I'm glad you did. Will look at these. One reason to stick with approach (a) is that it gives us the option to easily add PQgetRowData(), in case future testing shows that that's actually worth the risk and usage restrictions. While I'm a bit dubious of that, I'm prepared to be proven wrong. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
