I think the v5 patch should be marked as 'Ready for Committer'
2011/6/18 Josh Kupershmidt schmi...@gmail.com:
On Sat, Jun 18, 2011 at 10:53 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
In addition, this pg_comments system view supports 'access method' class, but
we cannot set a comment on
Thanks for your review.
2011/6/19 Robert Haas robertmh...@gmail.com:
On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a preparation to rework implementation of DROP
statement
using a common code. That intends to apply get_object_address() to
On Jun19, 2011, at 00:23 , Jeff Davis wrote:
On Sat, 2011-06-18 at 22:19 +0200, Florian Pflug wrote:
Yes, that seems necessary for consistency. That leaves the question
of what to do if someone tries to modify a textrange's collation with
a COLLATE clause. For example,
For example, whats
I want to implement hugepages for shared memory, to make it transparent I want
to do in this fashion:
1. Reserve memory M of size s
2. Try to allocate hugepage memory of as big size as possible (hs), attach at
M.
3. Allocate normal shared memory of size hs - s, and attach it at M+hs.
This
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
I want to implement hugepages for shared memory, to make it transparent I
want
to do in this fashion:
1. Reserve memory M of size s
2. Try to allocate hugepage memory of as big size as possible (hs), attach at
M.
3.
Martijn van Oosterhout klep...@svana.org Sunday 19 of June 2011 12:35:18
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
I want to implement hugepages for shared memory, to make it transparent I
want to do in this fashion:
1. Reserve memory M of size s
2. Try to
On Sun, Jun 19, 2011 at 11:21:28AM +0200, Florian Pflug wrote:
I think rejecting it makes more sense, so a range would not be a
collatable type; it just happens to use collations of the subtype
internally.
Ah, crap, I put the COLLATE in the wrong place. What I actually
had in mind was
Hello
2011/6/19 Steve Singer ssinger...@sympatico.ca:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Hello
Attached patch implements a new erros's fields that describes table,
colums related to error. This enhanced info is limited to constraints
and RI.
...
I think that both the
2011/6/19 Steve Singer ssinger...@sympatico.ca:
On 11-06-18 06:36 PM, Steve Singer wrote:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Here is my review of this patch
Submission Review:
The patch applies cleanly against master
The patch does not include any
2011/6/19 Robert Haas robertmh...@gmail.com:
On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Is this profile expected?
I've certainly seen profiles before where the catcache overhead was
significant. I don't think that I've seen SearchCatCache() quite this
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
On Sat, Jun 11, 2011 at
2011/6/19 Pavel Stehule pavel.steh...@gmail.com:
2011/6/19 Robert Haas robertmh...@gmail.com:
On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Is this profile expected?
I've certainly seen profiles before where the catcache overhead was
significant. I don't
Sorry, the previous revision did not update regression test part
towards the latest one.
2011/6/19 Kohei KaiGai kai...@kaigai.gr.jp:
Thanks for your review.
2011/6/19 Robert Haas robertmh...@gmail.com:
On Tue, Jun 14, 2011 at 8:06 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached
On Jun19, 2011, at 05:10 , Steve Singer wrote:
On 11-06-18 06:36 PM, Steve Singer wrote:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Here is my review of this patch
Submission Review:
The patch applies cleanly against master
The patch does not include any
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Perhaps we should recommend:
cd /path test ! -f %f cp %p %f
That is shorter and removes the duplicate problem.
Um ... %p is relative to the database directory.
Oh, I see now. I had thought it was an absolute path, but good
2011/6/19 Florian Pflug f...@phlo.org:
On Jun19, 2011, at 05:10 , Steve Singer wrote:
On 11-06-18 06:36 PM, Steve Singer wrote:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
Here is my review of this patch
Submission Review:
The patch applies cleanly against master
On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
2011/6/19 Florian Pflug f...@phlo.org:
Speaking as someone who's wished for the feature that Pavel's patch provides
many times in the past - shouldn't there also be a field containing the
offending value? If we had that, it'd finally be possible
On 06/19/2011 08:00 AM, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
Perhaps we should recommend:
cd /path test ! -f %f cp %p %f
That is shorter and removes the duplicate problem.
Um ... %p is relative to the database directory.
Oh, I see now. I
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
1. ANALYZE happens far too infrequently to believe that any data taken
at ANALYZE time will still be relevant at execution time.
2. Using data gathered by ANALYZE will make plans less stable, and our
users complain not
On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(I will refrain for
the moment from speculating whether we'll ever have an index type that
supports regexp match directly as an indexable operator...)
Fwiw I looked into this at one point and have some ideas if anyone is
keen
2011/6/19 Florian Pflug f...@phlo.org:
On Jun19, 2011, at 14:03 , Pavel Stehule wrote:
2011/6/19 Florian Pflug f...@phlo.org:
Speaking as someone who's wished for the feature that Pavel's patch provides
many times in the past - shouldn't there also be a field containing the
offending value?
Hi
It looks like we've failed to reach an agreement on how to
proceed on the issue with missing commutators for the various
text matching operators (~, ~~, and their case-insensitive
variants). We do seem to have agreed, however, that adding
commutators for the non-deprecated operators which lack
2011/6/19 Greg Stark st...@mit.edu:
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
1. ANALYZE happens far too infrequently to believe that any data taken
at ANALYZE time will still be relevant at execution time.
2. Using data gathered by ANALYZE will make plans less
2011/6/17 Andrew Tipton andrew.t.tip...@gmail.com:
On Fri, Jun 10, 2011 at 22:16, Hitoshi Harada umi.tan...@gmail.com wrote:
Isn't it worth adding new consistent function for those purposes? The
approach in the patch as stands looks kludge to me.
Thanks for your review. Coming back to this
2011/5/14 Robert Haas robertmh...@gmail.com:
On Fri, May 13, 2011 at 6:34 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
If reviewers agree it is safe and benchmarks make evidences that no
basic performance issue are raised, then let's see if next items have
blockers or can be
2011/5/11 Bruce Momjian br...@momjian.us:
Cédric Villemain wrote:
2011/5/10 Kevin Grittner kevin.gritt...@wicourts.gov:
Simon Riggs si...@2ndquadrant.com wrote:
The typical speed up for non-covered indexes will come when we
access a very large table (not in cache) via an index scan that is
On Sun, Jun 19, 2011 at 3:25 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2011/6/18 Josh Kupershmidt schmi...@gmail.com:
I think the v5 patch should be marked as 'Ready for Committer'
I think we still need to handle my Still TODO concerns noted
upthread. I don't have a lot of time this weekend
On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
Make external_pid_file world readable
Should this be back-patched?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP:
Robert Haas wrote:
Kevin Grittner wrote:
I'm certainly open to suggestions for better wording.
How about something like this:
When the system is forced to combine multiple page-level predicate
locks into a single relation-level predicate lock because the
predicate lock table is short
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn't it be a great interface if PQResult was bi-directional? Create a
result set on the client then call the database with a
I took another look at this this evening, and realised that my
comments could be a little clearer.
Attached revision cleans them up a bit.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git
On 6/19/2011 11:04 AM, Jeff Shanab wrote:
I am wondering If I am missing something obvious. If not, I have a suggestion
for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was “bi-directional”? Create a
result set on
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
The attached patch refactors heap_hot_search_buffer() so that
index_getnext() can use it, and modifies index_getnext() to do so.
Attached is a version of the patch that applies cleanly to master.
Regards,
Jeff Davis
On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
The attached patch refactors heap_hot_search_buffer() so that
index_getnext() can use it, and modifies index_getnext() to do so.
Attached is a version of the patch that applies
On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
Collation checking is generally done by the planner. I don't see why
the input function should check, the result of an input function is by
definition DEFAULT. It's up to the 'in' operator to check.
Note that the whole idea of
On Sun, Jun 19, 2011 at 2:01 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2011-06-19 at 10:50 -0700, Jeff Davis wrote:
On Mon, 2011-06-06 at 14:03 -0400, Robert Haas wrote:
The attached patch refactors heap_hot_search_buffer() so that
index_getnext() can use it, and modifies
On Sun, Jun 19, 2011 at 10:44 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
and recent stuff on VM will allow us to move forward it seems !
Yep, looks promising. The heap_hot_search_buffer refactoring patch is
related as well.
--
Robert Haas
EnterpriseDB:
Robert Haas robertmh...@gmail.com writes:
Yikes. I think you are right. It's kind of scary that the regression
tests passed with that mistake.
Can we add a test that exposes that mistake?
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Good point --- we would be making plan decisions based on the visibility
map coverage. The big question is whether visibility map changes are
more dynamic than the values we already plan against, like
On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yikes. I think you are right. It's kind of scary that the regression
tests passed with that mistake.
Can we add a test that exposes that mistake?
Not sure. We'd have to figure out
On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark st...@mit.edu wrote:
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
1. ANALYZE happens far too infrequently to believe that any data taken
at ANALYZE time will still be relevant at execution time.
2. Using data gathered by
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug f...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow us to make ~ it's own commutator by defining both
text ~ pattern
and
pattern ~ text.
2011/6/19 Robert Haas robertmh...@gmail.com:
On Sun, Jun 19, 2011 at 11:12 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Good point --- we would be making plan decisions based on the visibility
map coverage. The big question is whether visibility map changes are
more dynamic
On Jun19, 2011, at 20:56 , Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflug f...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow us to make ~ it's own commutator by
Martijn van Oosterhout klep...@svana.org writes:
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
I want to implement hugepages for shared memory, to make it transparent I
want
At least in Linux they're trying to make hugepages transparent, so I'm
wondering if this is
On Jun19, 2011, at 20:08 , Jeff Davis wrote:
On Sun, 2011-06-19 at 12:24 +0200, Martijn van Oosterhout wrote:
Collation checking is generally done by the planner. I don't see why
the input function should check, the result of an input function is by
definition DEFAULT. It's up to the 'in'
2011/6/19 Robert Haas robertmh...@gmail.com:
On Sun, Jun 19, 2011 at 9:38 AM, Greg Stark st...@mit.edu wrote:
On Tue, Jun 14, 2011 at 4:04 PM, Robert Haas robertmh...@gmail.com wrote:
1. ANALYZE happens far too infrequently to believe that any data taken
at ANALYZE time will still be relevant
On Sun, Jun 19, 2011 at 02:48:58PM +0100, Greg Stark wrote:
On Thu, Jun 16, 2011 at 6:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
(I will refrain for the moment from speculating whether we'll ever
have an index type that supports regexp match directly as an
indexable operator...)
Fwiw I
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
Jesper
On 2011-03-11 16:51, Noah Misch wrote:
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
Automated tests would go a long way toward building confidence that this
Hey Jeff,
2011/6/19 Jeff Shanab jsha...@smartwire.com
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
** **
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
** **
Wouldn’t it be a great interface if PQResult
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflugf...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow us to make ~ it's own commutator by defining
Andrew Dunstan and...@dunslane.net writes:
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflugf...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for patterns as opposed to text. That'd
allow
On sön, 2011-06-19 at 08:59 -0700, David Fetter wrote:
On Sat, Jun 18, 2011 at 10:18:50PM +, Peter Eisentraut wrote:
Make external_pid_file world readable
Should this be back-patched?
I wasn't planning to. It's a new feature.
--
Sent via pgsql-hackers mailing list
On Sun, Jun 19, 2011 at 2:41 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 19, 2011 at 2:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yikes. I think you are right. It's kind of scary that the regression
tests passed with that mistake.
Can
On Jun19, 2011, at 22:10 , Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflugf...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we resolve the issue
by adding a distinct type for
On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be estimating
the percentage of rows on all-visible pages just at the time when that
percentage is highest. This is not exactly wonderful, either...
Hm, doesn't autovacuum run ANALYZE quite a
On Fri, Jun 17, 2011 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
4. Backend #2 visits the new, about-to-be-committed version of
pgbench_accounts' pg_class row just before backend
On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug f...@phlo.org wrote:
On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be estimating
the percentage of rows on all-visible pages just at the time when that
percentage is highest. This is not
On 06/19/2011 09:38 AM, Greg Stark wrote:
There's another problem which I haven't seen mentioned. Because the
access method will affect the cache there's the possibility of
feedback loops. e.g. A freshly loaded system prefers sequential scans
for a given table because without the cache the seeks
Greg Smith wrote:
I'm not too concerned about the specific case you warned about
because I don't see how sequential scan vs. index costing will be
any different on a fresh system than it is now.
I think the point is that if, on a fresh system, the first access to
a table is something which
I applied Jeff's patch but changed this to address concerns about the
program getting stuck running for too long in the function:
#define plpgsql_loops 512
This would be better named as plpgsql_batch_size or something similar
instead, the current name suggests it's how many loops to run
So I was the victim assigned to review this patch.
The code is pretty much impeccable as usual from Noah. But I have
questions about the semantics of it.
Firstly this bit makes me wonder:
+ /* Not-found is always final. */
+ if (!OidIsValid(relOid1))
+
On 06/19/2011 05:02 PM, Florian Pflug wrote:
On Jun19, 2011, at 22:10 , Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 06/19/2011 02:56 PM, Robert Haas wrote:
On Sun, Jun 19, 2011 at 9:53 AM, Florian Pflugf...@phlo.org wrote:
Amidst the discussion, Alvaro suggested that we
Heikki Linnakangas wrote:
* The oldserxid code is broken for non-default BLCKSZ.
o The warning will come either too early or too late
o There is no safeguard against actually wrapping around the
SLRU, just the warning
o I'm suspicious of the OldSerXidPagePrecedesLogically() logic
with 32k
On Jun20, 2011, at 00:56 , Andrew Dunstan wrote:
On 06/19/2011 05:02 PM, Florian Pflug wrote:
The only argument against that I can see is that it poses
a compatibility problem if ~ remains the pattern matching
operator. I do believe, however, that the chance of
unknown ~ unknown
appearing
On Jun19, 2011, at 23:16 , Robert Haas wrote:
On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug f...@phlo.org wrote:
On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be estimating
the percentage of rows on all-visible pages just at the time
On 06/19/2011 06:15 PM, Kevin Grittner wrote:
I think the point is that if, on a fresh system, the first access to
a table is something which uses a tables scan -- like select count(*)
-- that all indexed access would then tend to be suppressed for that
table. After all, for each individual
On Sun, Jun 19, 2011 at 7:59 PM, Florian Pflug f...@phlo.org wrote:
On Jun19, 2011, at 23:16 , Robert Haas wrote:
On Sun, Jun 19, 2011 at 5:10 PM, Florian Pflug f...@phlo.org wrote:
On Jun19, 2011, at 20:40 , Robert Haas wrote:
2. Since VACUUM and ANALYZE often run together, we will be
On Sun, Jun 19, 2011 at 3:32 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2nd, I provided the patches on the last CF, exactly to allow to go to
the exciting part: the cost-estimates changes. (after all, we can work
on the cost estimate, and if later we find a way to use ALTER
On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab jsha...@smartwire.com wrote:
I am wondering If I am missing something obvious. If not, I have a
suggestion for plpgsql.
Stored procedures can accept rows.
Libpq can receive rows (PQResult).
Wouldn’t it be a great interface if PQResult was
On Sat, Jun 18, 2011 at 11:57 AM, Rémi Zara remi_z...@mac.com wrote:
Pika failed at the isolationCheck phase, hitting an assertion:
TRAP: FailedAssertion(!(!((oldSerXidControl-tailXid) != ((TransactionId)
0)) || TransactionIdFollows(xid, oldSerXidControl-tailXid)), File:
predicate.c, Line:
On Fri, Jun 17, 2011 at 3:49 PM, Florian Pflug f...@phlo.org wrote:
The regex is always to the right of the operator.
Which is something you have to remember... It's not in any
way deducible from foo ~ bar alone.
Except that it's always been this way, going back to perl4 or tcl or
their
On Thu, Jun 16, 2011 at 9:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, if you're hacking Postgres code and don't already have a
reinstall script, you need one. Mine is basically
pg_ctl stop
cd $PGBLDROOT/src/backend
make install-bin
pg_ctl start
I've always
On Sat, Jun 18, 2011 at 10:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown t...@linux.com writes:
On 18 June 2011 04:13, Bruce Momjian br...@momjian.us wrote:
I tested on FreeBSD 7.4 and saw a 1 error return:
And on a Mac (so through Darwin 10.7.0 a BSD version too):
Yeah, see
On Fri, Jun 17, 2011 at 11:34 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 16, 2011 at 10:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
According to the above page, one purpose of time-delayed replication is to
protect against user mistakes on master. But, when an user notices his
On Sun, 19 Jun 2011, Pavel Stehule wrote:
Maybe there is second issue (little bit - performance - you have to
call a output function), But I agree, so this information is very
interesting and can help.
I am concerned about the performance impact of doing that. Not all
constraints are on
Hi Greg,
On Sun, Jun 19, 2011 at 11:44:35PM +0100, Greg Stark wrote:
So I was the victim assigned to review this patch.
Thanks for doing so.
The code is pretty much impeccable as usual from Noah. But I have
questions about the semantics of it.
Firstly this bit makes me wonder:
+
Excerpts from Pavel Stehule's message of dom jun 19 06:51:13 -0400 2011:
Hello
2011/6/19 Steve Singer ssinger...@sympatico.ca:
On 11-06-08 04:14 PM, Pavel Stehule wrote:
nbtinsert.c
pg_get_indrelation is named differently than everything else in this file
(ie _bt...). My guess is
Greg Stark wrote:
I've always wondered what other people do to iterate quickly.
I'd have bet money you had an elisp program for this by now!
The peg utility script I use makes a reinstall as simple as:
stop
peg build
The UI for peg is still is a little rough around switching to another
On Mon, Jun 20, 2011 at 07:30, Greg Smith g...@2ndquadrant.com wrote:
I applied Jeff's patch but changed this to address concerns about the
program getting stuck running for too long in the function:
#define plpgsql_loops 512
Is it OK to define the value as constant?
Also, it executes much
On Mon, Jun 20, 2011 at 1:00 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
I took another look at this this evening, and realised that my
comments could be a little clearer.
Attached revision cleans them up a bit.
Since I'm not familiar with Windows, I haven't read the code related
to
81 matches
Mail list logo
