A couple of small issues spotted while reviewing the streaming
replication patch:
- Because sentPtr is initialized to zeros, GetOldestWALSendPointer will
return zero before a just-launched WAL sender has sent its first
message. That can lead to WAL files that are still needed by another
standby
Dne 8.12.09 00:27, Bernd Helmle napsal(a):
--On 13. November 2009 23:29:41 +0100 Zdenek Kotala
zdenek.kot...@sun.com wrote:
t contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail thread is
On Dec 8, 2009, at 12:05 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
I could live with the equals signs, but the use of parentheses seems
weird and inconsistent with normal english usage (which permits
parentheses as a means of making parenthetical comments).
But it is
On Tue, Dec 8, 2009 at 5:30 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
A couple of small issues spotted while reviewing the streaming
replication patch:
Thanks for the review!
- Because sentPtr is initialized to zeros, GetOldestWALSendPointer will
return zero before a
On Tue, Dec 8, 2009 at 8:30 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
- It's possible to shut down master, change max_wal_senders to 0,
restart and do an operation like CLUSTER which then skips WAL-logging.
Then shutdown, change max_wal_senders back to non-zero. All this
Greg Stark wrote:
On Tue, Dec 8, 2009 at 8:30 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
- It's possible to shut down master, change max_wal_senders to 0,
restart and do an operation like CLUSTER which then skips WAL-logging.
Then shutdown, change max_wal_senders back
2009/12/8 黄晓骋 huangxcl...@gmail.com:
From the above, I think the tuple lock is unnecessary, because it uses
transaction lock.
Besides, tuple lock is unlocked after the tuple is updated but not after the
transaction commits. I mean it's not 2PL.
It's a two step process. An update marks the
On Mon, Dec 07, 2009 at 07:07:13PM -0500, Andrew Dunstan wrote:
Josh Berkus wrote:
Not everything is sanely convertible into some sort of plugin. A plugin
mechanism for this would be FAR more trouble that it is worth, IMNSHO.
We are massively over-egging this pudding (as a culinary blogger
Tim Bunce wrote:
I've no contribution to the main topic, but I'd like to point out that
the JSON is a subset of YAML meme is not without controversy:
http://search.cpan.org/~mlehmann/JSON-XS-2.26/XS.pm#JSON_and_YAML
It may not be relevant in your use-case, but I thought it worth a
On Tue, Dec 8, 2009 at 9:13 AM, Andrew Dunstan and...@dunslane.net wrote:
Well, if we're going to commit this, as now appears likely, we should have
some language lawyers go over our code for both YAML and JSON with a fine
tooth comb to make sure what we are producing is strictly According To
I find the backend libpq changes related to non-blocking I/O quite
complex. Can we find a simpler solution?
The problem we're trying to solve is that while the walsender backend
sends a lot of WAL records to the client, the client can send a lot of
messages to the backend. If volume of the
Thanks for the answers.
I will change it for PostgreSQL 8.4 and try to use DBT-2.
But, I'm not quite sure if DTrace will give me the workload that I want.
Since, i want to trace the Workload that is above the Buffer Layer. With
workload I mean two fields (operation: read/write and Block Number).
On Mon, Dec 07, 2009 at 10:49:13AM +, Dave Page wrote:
On behalf of the core team, I'm pleased to announce that the
Congratulations!
+1 Congrats to you all, and thanks for the contributions, both past and
future.
As an aside, this sort of thing is one of the best signs to an external
Greg Smith wrote:
Jonas J wrote:
P.S.: I'm using PostgreSQL 8.1.4 to run with TPCC-UVA benchmarks tests...
Ah. PostgreSQL 8.1 is significantly slower than the current
versions, and you're not going to get as much help with issues
related to the source code as if you're using a newer one.
On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote:
David P. Quigley wrote:
Not to start a flame war here about access control models but you gave 3
different examples one of which I don't think has any means to do
anything productive here.
You won't be starting a flame war for the same
On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
I'd be willing to take a look at the framework and see if it really is
SELinux centric. If it is we can figure out if there is a way to
accomodate something like SMACK and FMAC. I'd like to hear from someone
with
I wrote:
Frankly, I'd be amazed if there was a performance regression,
OK, I'm amazed. While it apparently helps some cases dramatically
(Andres had a case where run time was reduced by 93.2%), I found a
pretty routine case where run time was increased by 3.1%. I tweaked
the code and got
On Tuesday 08 December 2009 16:23:11 Kevin Grittner wrote:
I wrote:
Frankly, I'd be amazed if there was a performance regression,
OK, I'm amazed. While it apparently helps some cases dramatically
(Andres had a case where run time was reduced by 93.2%), I found a
pretty routine case where
Robert Haas robertmh...@gmail.com writes:
+1. I'm a little concerned about the bit about the YAML specification
changing, too, but at least if we can ensure that we're compliant with
the spec that is current at the time the code goes in we have a leg to
stand on.
If the spec is in flux, that
Peter St. Onge wrote privately:
With the local server room renovations, there may be some older
equipment being retired. Are there any architectures that you would
like to see added to the buildfarm?
Hackers,
Any nominations?
cheers
andrew
--
Sent via pgsql-hackers mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
If the spec is in flux, that seems like More Than Sufficient reason
to reject the patch for the time being. It can be resubmitted when
it's no longer shooting at a moving target.
Saying that it is in flux is a bit of a stretch. Even if it
Andrew Dunstan and...@dunslane.net writes:
Peter St. Onge wrote privately:
With the local server room renovations, there may be some older
equipment being retired. Are there any architectures that you would
like to see added to the buildfarm?
Any nominations?
Sure, what's being offered?
Andres Freund and...@anarazel.de wrote:
Could you show your testcase?
OK. I was going to try to check other platforms first, and package
up the information better, but here goes.
I created 1 lines with random IP-based URLs for a test. The
first few lines are:
create table t1 (c1
On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote:
Andres Freund and...@anarazel.de wrote:
Could you show your testcase?
Will hopefully look into this later.
I dont see why it could get slower?
I don't either. The best I can tell, following the pointer from
orig to any of its
Andres Freund and...@anarazel.de wrote:
Did you test that with a optimized build?
After running a series of tests with --enable-cassert to confirm
that nothing squawked, I disabled that before doing any
performance testing. Going from memory, I used --enable-debug
--with-libxml and --prefix.
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
As Alvaro mentioned, the original patch used ACE but it added too much
code so the
On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
wrote:
On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian br...@momjian.us wrote:
As Alvaro mentioned, the
On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
wrote:
On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
On Mon, Dec 7, 2009 at 1:00 PM, Bruce
On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote:
On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley dpqu...@tycho.nsa.gov
wrote:
On Mon, 2009-12-07
On 12/8/09 7:51 AM, Andrew Dunstan wrote:
Peter St. Onge wrote privately:
With the local server room renovations, there may be some older
equipment being retired. Are there any architectures that you would
like to see added to the buildfarm?
Got any Sparc machines? We're likely about to
I might be able to help with:
Sparc
PA-Risc (HP-UX)
IA64
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
-Original Message-
From:
On Tue, Dec 08, 2009 at 10:51:01AM -0500, Andrew Dunstan wrote:
Peter St. Onge wrote privately:
With the local server room renovations, there may be some older
equipment being retired. Are there any architectures that you
would like to see added to the buildfarm?
Hackers,
Any
Robert Haas robertmh...@gmail.com writes:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code. It would be nice
if it were possible to use the exist
Kevin Grittner wrote:
After running a series of tests with --enable-cassert to confirm
that nothing squawked, I disabled that before doing any
performance testing. Going from memory, I used --enable-debug
--with-libxml and --prefix. I didn't explicitly use or disable any
compiler
I wrote a small script to check our SGML, and the following links are
returning not found in our docs:
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
in charset.sgml, detailed info about some charsets. Do we just remove
this? Anybody know if similar info is available elsewhere?
Greg Smith g...@2ndquadrant.com wrote:
Now that you ask, of course I just spotted a bug in there such
that the documented behavior for the PGDEBUG feature doesn't
actually work. If you were using that to turn off asserts, that
may not have worked as expected. Don't know what you did there
On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the
2009/12/7 Greg Smith g...@2ndquadrant.com:
Magnus Hagander wrote:
Our instalation chapter (15.2) has a link to
http://developer.postgresql.org/~petere/bsd-gettext/ to get gettext on
other systems. this link is broken. Can somebody provide a proper
one, or should we remove it?
Goals of his
On 12/8/09 12:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote:
On 12/8/09 11:51 AM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 10:51 AM,
2009/12/8 Magnus Hagander mag...@hagander.net
I wrote a small script to check our SGML, and the following links are
returning not found in our docs:
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
in charset.sgml, detailed info about some charsets. Do we just remove
this? Anybody
Hi,
On Tuesday 08 December 2009 20:09:22 Greg Smith wrote:
Andres, are using any optimization flags when you're testing?
I was testing with and without debug/cassert - and did not get adverse results
in both...
Unfortunately it looks like I wont get to test today, but only tomorrow
morning
Magnus Hagander wrote:
ftp://ftp.sco.com/skunkware
Link to sco skunkware which supposedly is available there if you
don't have the CD, in the installation notes for Unixware and
OpenServer. Which it isn't. Suggest we just remove this sentence, but
leave the reference to the CD.
This is now
2009/12/8 Thom Brown thombr...@gmail.com:
2009/12/8 Magnus Hagander mag...@hagander.net
I wrote a small script to check our SGML, and the following links are
returning not found in our docs:
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
in charset.sgml, detailed info about some
2009/12/8 Greg Smith g...@2ndquadrant.com:
Magnus Hagander wrote:
ftp://ftp.sco.com/skunkware
Link to sco skunkware which supposedly is available there if you
don't have the CD, in the installation notes for Unixware and
OpenServer. Which it isn't. Suggest we just remove this sentence, but
Kevin Grittner wrote:
Anyway, I'm not sure whether your reply directly answers the point
I was raising -- peg doesn't do anything with the compiler
optimization flags under the covers, does it?
Not really. It does this:
PGDEBUG=--enable-cassert --enable-debug
./configure
Magnus Hagander wrote:
ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
in charset.sgml, detailed info about some charsets. Do we just remove
this? Anybody know if similar info is available elsewhere?
Now http://examples.oreilly.com/cjkvinfo/doc/cjk.inf
--
Greg Smith2ndQuadrant
Greg Smith g...@2ndquadrant.com writes:
Kevin Grittner wrote:
Anyway, I'm not sure whether your reply directly answers the point
I was raising -- peg doesn't do anything with the compiler
optimization flags under the covers, does it?
Not really. It does this:
PGDEBUG=--enable-cassert
2009/12/8 Magnus Hagander mag...@hagander.net:
2009/12/8 Greg Smith g...@2ndquadrant.com:
Magnus Hagander wrote:
ftp://ftp.sco.com/skunkware
Link to sco skunkware which supposedly is available there if you
don't have the CD, in the installation notes for Unixware and
OpenServer. Which it
Tom Lane wrote:
--enable-cassert might have a noticeable performance impact.
We usually try to not have that on when doing performance testing.
All covered in the tool's documentation, and it looks like Kevin did the
right thing during his tests by checking the pg_config output to confirm
Tom Lane t...@sss.pgh.pa.us wrote:
--enable-cassert might have a noticeable performance impact.
We usually try to not have that on when doing performance testing.
Right. I turned it on for some initial tests to confirm that we had
no assertion failures; then turned it off for the
On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve
* Robert Haas (robertmh...@gmail.com) wrote:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code.
I've really got to take exception to this. I've only been
On Tue, Dec 8, 2009 at 2:50 PM, David P. Quigley dpqu...@tycho.nsa.gov wrote:
On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote:
On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One of the major and fundamental stumbling blocks
--On 13. November 2009 17:16:15 -0500 Robert Haas robertmh...@gmail.com
wrote:
Don't think. Benchmark. :-)
(If you can measure it at all, it's too much, at least IMHO.)
I've tried to benchmark this now on my (fairly slow compared to server
hardware) MacBook and see some negative trend
Bernd Helmle wrote:
I've tried to benchmark this now on my (fairly slow compared to server
hardware) MacBook and see some negative trend for those memory probes
in pgbench. Running dozens of rounds with pgbench (scale 150, 10
clients / 1000 transactions)
That makes for a 5.5 minute test, which
--On 8. Dezember 2009 15:51:52 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Try this instead, which will give you a test where checkpoints have a
minimal impact, but lots of memory will be thrown around:
pgbench -i -s 10 db
pgbench -S -c 10 -T 600 db
Thanks for the input, will try
On Mon, Nov 16, 2009 at 5:59 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
New version: rebased to current CVS.
This one no longer applies to HEAD, could you update it please?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil -
On Tue, 2009-12-08 at 15:24 -0500, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code.
On mån, 2009-12-07 at 17:33 +0100, Martijn van Oosterhout wrote:
On Mon, Dec 07, 2009 at 01:09:59PM -0300, Alvaro Herrera wrote:
Given the extreme patience and diligence exhibited by KaiGai, I
hesitate to say this, but it seems to me that this would be
critically important for the long
On mån, 2009-12-07 at 11:45 -0500, Chris Browne wrote:
I feel about the same way about this as I did about the adding of
native Windows support; I'm a bit concerned that this could be a
destabilizing influence. I was wrong back then; the Windows support
hasn't had the ill effects I was
On Tue, Dec 8, 2009 at 3:24 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in
On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
[snip...]
I can say from experience that this project is very skeptical of
frameworks that aren't accompanied by at least one, and preferably
multiple, working implementations. So there is a bit of a chicken and
egg problem here. What
Peter Eisentraut pete...@gmx.net writes:
PGACE wasn't a plugin system. It was an API inside the core code. If
it had been a plugin system, this would have been much easier, because
the plugin itself could have been developed independently.
Well, it should certainly have used function
I wrote:
Perhaps it is some quirk of using 32 bit pointers on the 64 bit
AMD CPU? (I'm looking forward to testing this today on a 64 bit
build on an Intel CPU.)
The exact same test on 64 bit OS (SuSE Enterprise Server) on Intel
gave very different results. With 10 runs each of 200
On Tue, 2009-12-08 at 16:51 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
PGACE wasn't a plugin system. It was an API inside the core code. If
it had been a plugin system, this would have been much easier, because
the plugin itself could have been developed
Robert Haas wrote:
On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley dpqu...@tycho.nsa.gov
wrote:
I'd be willing to take a look at the framework and see if it really is
SELinux centric. If it is we can figure out if there is a way to
accomodate something like SMACK and FMAC. I'd like to hear
Robert Haas wrote:
Sorry. I spent a lot of time for both CommitFest 2008-11 and
CommitFest 2009-07 in the hopes of getting something committable, and
I wasn't successful. I'm just at the end of my rope. It seems fairly
clear that Tom isn't going to commit any piece of SE-PostgreSQL at
all,
On Tue, Dec 8, 2009 at 9:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I suspect we should have a WAL record to say unlogged operation
performed here which a standby database would recognize and throw a
large warning up.
+1. Seems like a very simple solution.
Sounds
Fujii Masao masao.fu...@gmail.com writes:
Thought? Am I missing something?
This seems terribly overdesigned. Just emit a warning when you see
the unlogged op record and have done.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The first question is: do we really need to be prepared for that? The
XLogRecPtr acknowledgment messages the client sends are very small, and
if the client is mindful about not sending them too often
On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Thought? Am I missing something?
This seems terribly overdesigned. Just emit a warning when you see
the unlogged op record and have done.
Sounds quite simple. OK, I'll do so.
On Mon, Dec 7, 2009 at 8:33 AM, marcin mank marcin.m...@gmail.com wrote:
The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider:
leki_dev=# select levenshtein('','a',2,4,5);
levenshtein
-
1
(1 row)
leki_dev=# select levenshtein('a','',2,4,5);
Robert Haas wrote:
patch attached.
I cannot get this patch to apply for anything. All 4 hunks fail, both
on HEAD and on the the pre-8.4-pgindent version of fuzzystrmatch.c.
Either I'm doing something wrong here, or there's something wrong with
this patch file.
The author converted tabs
David P. Quigley wrote:
So I was reading through a set of slides that KaiGai has and he
mentioned a May commitfest link and I looked for the comments related to
his PGACE patches. I've been crawling through the commitfest paces so I
can figure out what the latest version of the pgace patch is.
Can I ask the final decision whether the YAML formatter should be
applied or rejected? As far as I read the discussion, we can apply it
because serveral users want it and we don't have a plan to support
extensible formatters in the core.
Greg Smith g...@2ndquadrant.com wrote:
-The patch is
David P. Quigley wrote:
I understand that PostgreSQL is a fast moving target with a large developer
base but so is the Linux Kernel and a
similar framework has been working there for years now.
It sounds like how you're thinking about this project's development
model is inverted from the
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Before we go too far with this, I'd like to know how we will handle the
problems outlined here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00916.php
Hm, I think that's only a problem if we define it to be a
On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
patch attached.
I cannot get this patch to apply for anything. All 4 hunks fail, both
on HEAD and on the the pre-8.4-pgindent version of fuzzystrmatch.c.
Either I'm doing something wrong here, or
Takahiro Itagaki wrote:
Can I ask the final decision whether the YAML formatter should be
applied or rejected? As far as I read the discussion, we can apply it
because serveral users want it and we don't have a plan to support
extensible formatters in the core.
The path I thought made sense
Magnus,
Just in case anybody was wondering, I've added myself as a reviewer of
this one for next commitfest - I doubt that's very surprising :-)
Others are of course more than welcome to chip in!
Greg Smith wrote:
There are also a couple of patches that for various reasons have yet to
get
Tatsuo Ishii wrote:
Now that Greg is going to close the Nov Commit Festa, I think he is
requesting initial reviews for the patches.
While Magnus might take a look anyway, in general we'll all be taking a
break from review until January 15th, when the final CommitFest for this
version
Greg Smith wrote:
Takahiro Itagaki wrote:
Can I ask the final decision whether the YAML formatter should be
applied or rejected? As far as I read the discussion, we can apply it
because serveral users want it and we don't have a plan to support
extensible formatters in the core.
The path
It looks like the last round of issues on this patch only came from
Tom's concerns, so I'm not sure if anyone but Tom (or a similarly picky
alternate committer) is going to find anything else in a re-review. It
looks to me like all the issues were sorted out anyway. Euler, you're
off the
Tatsuo Ishii wrote:
Now that Greg is going to close the Nov Commit Festa, I think he is
requesting initial reviews for the patches.
While Magnus might take a look anyway, in general we'll all be taking a
break from review until January 15th, when the final CommitFest for this
Euler Taveira de Oliveira wrote:
If there is no more objections, I'll flag the patch 'ready for committer'
I just executed that. Note that there are two bits of subjective
tweaking possible to do with this one when it's committed: slimming
down the width of the display, and Euler's
On Tue, Dec 8, 2009 at 10:30 PM, Tatsuo Ishii is...@postgresql.org wrote:
Tatsuo Ishii wrote:
Now that Greg is going to close the Nov Commit Festa, I think he is
requesting initial reviews for the patches.
While Magnus might take a look anyway, in general we'll all be taking a
break from
Zdenek Kotala wrote:
thanks for your useful comments. I attached new doc patch version. I
removed example changes and add link to create database cluster (I hope)
everywhere. Please, look on it and let me know if there is still
something what should be changed.
That looks much better.
Greg Smith g...@2ndquadrant.com writes:
To be clear about which version we're talking about:
http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp
is the candidate for commit that includes the cleanup you've already done.
I suppose this is subject to the
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
Of course there's also no rule that you couldn't review these sooner -
that might help get the ball rolling!
Of course I did before he publishes the patches. (I and he are
On Tue, Dec 8, 2009 at 10:12 PM, Greg Smith g...@2ndquadrant.com wrote:
It looks like the last round of issues on this patch only came from Tom's
concerns, so I'm not sure if anyone but Tom (or a similarly picky alternate
committer) is going to find anything else in a re-review. It looks to me
On Tue, Dec 8, 2009 at 10:48 PM, Tatsuo Ishii is...@postgresql.org wrote:
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
Of course there's also no rule that you couldn't review these sooner -
that might help get the ball
Bruce Momjian br...@momjian.us writes:
I installed PL/pgSQL by default via initdb with the attached patch. The
only problem is that pg_dump still dumps out the language creation:
CREATE PROCEDURAL LANGUAGE plpgsql;
ALTER PROCEDURAL LANGUAGE plpgsql OWNER TO postgres;
What is odd
Robert Haas wrote:
Since Itagaki Takahiro is now a committer, I sort of assumed he would
be committing his own patches.
Maybe, but I wasn't going to be the one to suggest that Tom get cut out
of the loop after he raised a list of issues with the patch already.
I think the situation for
David P. Quigley wrote:
On Tue, 2009-12-08 at 15:26 -0500, Robert Haas wrote:
[snip...]
I can say from experience that this project is very skeptical of
frameworks that aren't accompanied by at least one, and preferably
multiple, working implementations. So there is a bit of a chicken and
Greg Smith g...@2ndquadrant.com wrote:
I just executed that. Note that there are two bits of subjective
tweaking possible to do with this one when it's committed: slimming
down the width of the display, and Euler's suggestion's for rewording.
I linked to both of those messages in the
Michael Paquier michael.paqu...@gmail.com wrote:
Please find attached the latest version of the patch,
with the threading bug corrected and the documentation updated as well.
Why do you use BUFFER_SIZE-1 for snprintf?
snprintf(commandShell, SHELL_COMMAND_SIZE-1, ...)
Trailing nulls are
2009/12/9 Bruce Momjian br...@momjian.us:
I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts, which I
think I can handle.
I think that's a horribly bad idea.
We have already got a similar issue with ECPG,
Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code.
I've really got to take exception
Fujii Masao wrote:
On Tue, Dec 8, 2009 at 11:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If that's deemed not good enough, we could modify just internal_flush()
so that it uses secure_poll to wait for the possibility to either read
or write, instead of blocking for
On Sun, Sep 13, 2009 at 10:42 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I've attached a patch which removes the iteration over the blocks to be
backed-up from the critical section of XLogInsert. Now those blocks are
only looped over in one piece of code which both computes the CRC and builds
1 - 100 of 101 matches
Mail list logo
