Hi,
Kevin Grittner wrote:
We're very much on the same page. My goal was to get predicate
locking that didn't miss anything, even though it was ridiculously
coarse, then implement the simplest possible SSI on top of it, without
worrying about optimizations, then incrementally move toward
On Thu, Jan 7, 2010 at 1:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This strikes me as a completely bad idea. We need get no farther than
the point that it assumes nobody can have a database named replication
Though I might misunderstand your point. My proposal would force the users
who have a
Is anybody interested? Otherwise the entry could be removed from the TODO
list...
Even if not, you can still submit a patch. There are a lot more users
of PG than there are people who read -hackers.
Ok, I'll try and submit a patch. Thank you very much.
--
Sent via pgsql-hackers
Tom Lane t...@sss.pgh.pa.us wrote:
I don't necessarily know what the right thing to do with the new ones
is, but I am pretty sure that pg_indent will revert any changes you
make to the existing ones.
That it will. The proposed changes to the existing lines are an
exercise in
On Thu, Jan 7, 2010 at 07:19, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander mag...@hagander.net wrote:
I haven't read up on the rest of the patch, but where do we put the
rest of the information about the replication master? Like which IP
and port to
On Thu, Jan 7, 2010 at 09:26, Fujii Masao masao.fu...@gmail.com wrote:
The same problem also exists in pg_hba.conf. It's because I introduced
new keyword replication in pg_hba.conf to authenticate the standby
server. This restriction is not acceptable? If so, I'd need to consider
an
Having concluded I really need to start playing with hot standby, I started
looking for documentation on the subject. I found what I was looking for; I
also found this page[1], which, it seems, ought to mention hot standby.
Comments?
[1]
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net wrote:
Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo'
So the password can just go there, no?
Yeah, the password
Kevin Grittner wrote:
Another interesting thing which crossed my mind (and I should
probably add a section for such things in the wiki) is that, given
the overhead and conflict implications of using table scans in
serializable transactions, we should perhaps try to discourage table
scans from
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net wrote:
However, wouldn't it make more logical sense to replace host/hostssl
with replication/replicationssl rather than overload the database
field?
Seems good. How about the following formats?
replication user
2010/1/7 Markus Wanner mar...@bluegap.ch:
(It's interesting that with database page level granularity, he states
that predicate locking would not be necessary. Instead any page can be
locked at any time. For this to work, according to my reasoning, you'd
have to know in advance on which page
Robert Haas wrote:
Jeff Davis wrote:
I have a question regarding true serializability and predicate locking.
There's some context on the wiki page:
If you have the following DDL:
create table mytable(mycircle circle);
create index mytable_mycircle_idx on mytable
using gist
On Thu, Jan 7, 2010 at 6:09 PM, Joshua Tolley eggyk...@gmail.com wrote:
Having concluded I really need to start playing with hot standby, I started
looking for documentation on the subject. I found what I was looking for; I
also found this page[1], which, it seems, ought to mention hot standby.
On 7/01/2010 9:15 AM, Robert Haas wrote:
On Wed, Jan 6, 2010 at 4:52 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
David E. Wheelerda...@kineticode.com wrote:
Last I heard, Andrew was willing to require Test::More for
testing, so that a Perl script could handle multiple psql
2010/1/7 Albe Laurenz laurenz.a...@wien.gv.at:
I don't know if such a thing would be easy to implement in
PostgreSQL, but I had thought that the standard approach to
implement predicate locking is like this:
Whenever you touch (read) a data structure, you tag it with a lock
that prevents
Nicolas Barbier wrote:
I don't know if such a thing would be easy to implement in
PostgreSQL, but I had thought that the standard approach to
implement predicate locking is like this:
Whenever you touch (read) a data structure, you tag it with a lock
that prevents anybody else from modifying
On Wed, Jan 06, 2010 at 03:36:39PM -0500, Tom Lane wrote:
BUG #5236: Aparent bug in ecpg
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00078.php
Michael needs to look at that one.
I'm waiting for a reproducable test case.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue in...@tpf.co.jp wrote:
Maybe I'm missing the point and have a question.
For example, do 32bit psql and the 64bit one have the same name?
If so, where will they be installed?
I'm only talking about libpq. I see no reason to have 32 64 bit
versions
On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Chuck McDevitt cmcdev...@greenplum.com wrote:
Just an FYI regarding this bug:
http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php
The wide-char version of any WIN32 API call will accept or return
On Wed, Jan 06, 2010 at 07:07:12PM -0500, Andrew Dunstan wrote:
Alvaro Herrera wrote:
decibel wrote:
We've actually run into similar issues. Alvaro came up with a patch
that fixes our specific issue, but I think he said there were some
other cases that needed to be fixed as well. Anyone
By popular request, I've set up a job that will push a mirror of the
master branch of our git repository
(git.postgresql.og/git/postgresql.git) to github. The main reason is
visibility, and the ability for github folks to work with their
tools. (Trivial job, literally two lines in an existing
On Wed, Jan 06, 2010 at 08:46:11PM -0500, Tom Lane wrote:
Tim Bunce tim.bu...@pobox.com writes:
On Wed, Jan 06, 2010 at 01:45:45PM -0800, David E. Wheeler wrote:
On Jan 6, 2010, at 12:20 PM, Tom Lane wrote:
One of the things on my to-do list for today is to make configure reject
Perl
On Wed, Jan 6, 2010 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
What tools do we have for identifying memory leaks?
User complaints :-(
Hi,
Kevin Grittner wrote:
I'm probably not quite as clueless as you think on this; I realize
that keeping SIREAD locks in memory will require many more slots for
locks, escalation from tuple level to page or coarser when there are
many on a table, or (most likely) both.
..oh, there's the
Hi all,
attached a patch that adds the following functions for bit string:
- overlay
- get_bit
- set_bit
Some info:
1) overlay is implemented as calls to substring; given the different way
substring behaves when used with strings vs bit strings:
test=# SELECT substring(B'0001'
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On m??n, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
Yea, I am not excited about having vacuumdb do only analyze, but it
seems the most minimal solution. I spelled it --only-analyze and just
posted the reason and patch.
I
Dave Page wrote:
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue in...@tpf.co.jp wrote:
Maybe I'm missing the point and have a question.
For example, do 32bit psql and the 64bit one have the same name?
If so, where will they be installed?
I'm only talking about libpq. I see no reason to have
On Thu, Jan 7, 2010 at 12:21 PM, Hiroshi Inoue in...@tpf.co.jp wrote:
Dave Page wrote:
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue in...@tpf.co.jp wrote:
Maybe I'm missing the point and have a question.
For example, do 32bit psql and the 64bit one have the same name?
If so, where will
Fujii Masao wrote:
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net wrote:
Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo'
So the password can just go there, no?
Hello
can somebody explain advantages of new vacuum?
Thank you
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
The attached patch supports new keyword 'replication' on .pgpass file.
This keyword is used to specify the password for the standby server to
connect to the primary server.
This strikes me as a completely bad idea. We need get no
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On mC3A5n, 2010-01-04 at 13:07 -0500, Bruce Momjian wrote:
Yea, I am not excited about having vacuumdb do only analyze, but it
seems the most minimal solution. I spelled it --only-analyze and just
posted the reason and patch.
Magnus Hagander wrote:
However, wouldn't it make more logical sense to replace host/hostssl
with replication/replicationssl rather than overload the database
field?
It makes more sense to me to overload the database field. When you
connect for replication, you're not connecting to any
On Thu, Jan 7, 2010 at 10:21, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net wrote:
However, wouldn't it make more logical sense to replace host/hostssl
with replication/replicationssl rather than overload the database
field?
On Thu, Jan 7, 2010 at 13:34, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander mag...@hagander.net wrote:
Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;
Hi,
Nicolas Barbier wrote:
The specifics of relation databases can be entirely ignored in case
serializability is provided on the page layer level.
Aha, I now see very vaguely how that could work, yes. Thank you for
elaborating on this. I agree that this isn't the best way forward for
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
*sigh* - that was mostly ment as a joke and not a really serious
comment. However the idea I actually had with BZ back in the days was
not to use it as a full fledged tracker(in the sense of exposing it to
users or developers)
Instead I
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Building racy infrastructure when it can be avoided with a little care
still seems not to be the best path to me.
Doing that will add more complexity in an area that is hard to test
effectively. I think the risk of
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Building racy infrastructure when it can be avoided with a little care
still seems not to be the best path to me.
Doing that will add more complexity in an
Tom Lane wrote:
bugzilla doesn't really interface to email well enough to do that.
I gather that debbugs might work better, but I have no personal
experience with it.
1. My recollection is that last time we looked the debbugs people
themselves said they didn't think it was suitable for
Bruce Momjian escribió:
Oh, interesting about pg_dump. Let's just go with --analyze-only.
--only-analyze is feeling odd to me too.
Done, attached and applied.
bikeshedding
Why -o and not, say, -Z? I imagine you picked -o for only but it
seems strange.
/
--
Alvaro Herrera
2010/1/7 Albe Laurenz laurenz.a...@wien.gv.at:
Nicolas Barbier wrote:
In such a pure implementation of predicate locking, the overlap
testing is be done using the algebraic properties of the conditions,
which is of course extremely difficult (if not impossible) to
implement perfectly in a
Tom Lane wrote:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
*sigh* - that was mostly ment as a joke and not a really serious
comment. However the idea I actually had with BZ back in the days was
not to use it as a full fledged tracker(in the sense of exposing it to
users or
Adding on to this use case:
what do we do when we reach end of year?
Probably auto-archive as per weekly, monthly , quarterly or yearly tables?
On Thu, Jan 7, 2010 at 1:14 AM, Josh Berkus j...@agliodbs.com wrote:
On 1/6/10 9:13 AM, Robert Haas wrote:
On Wed, Jan 6, 2010 at 12:06 PM, David
Alvaro Herrera wrote:
Bruce Momjian escribi?:
Oh, interesting about pg_dump. Let's just go with --analyze-only.
--only-analyze is feeling odd to me too.
Done, attached and applied.
bikeshedding
Why -o and not, say, -Z? I imagine you picked -o for only but it
seems strange.
/
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander mag...@hagander.net wrote:
However, wouldn't it make more logical sense to replace host/hostssl
with replication/replicationssl rather than overload the database
field?
Seems good. How about the
Tom Lane wrote:
I'm getting more and more confused here. I thought we were talking
about client-side .pgpass. This seems to be talking about pg_hba.conf.
Yeah, the topic was covertly changed.
It seems we have consensus to not change .pgpass, and to leave
pg_hba.conf as it is now in the patch
On Thu, Jan 07, 2010 at 08:01:16PM +0530, Chetan Suttraway wrote:
Adding on to this use case:
what do we do when we reach end of year?
Probably auto-archive as per weekly, monthly , quarterly or yearly tables?
Because such requirements are so specific to each place, it's easier
to do this in
On Thursday 07 January 2010 14:45:55 Joachim Wieland wrote:
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Building racy infrastructure when it can be avoided with a little care
still seems not to be the best path to me.
Doing that will add more complexity in an
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Doing this without DBI is going to be ten times harder than doing it
with DBI. Are we really sure that's not a viable option?
In the buildfarm? Yes, I think so. The philosophy of the buildfarm is
that it should do what you would do
Joachim Wieland j...@mcknight.de writes:
As there were so many boolean SomethingCancelPending variables I changed them
to be bitmasks and merged all of them into a single variable.
This seems like a truly horrid idea, because those variables are set by
signal handlers. A bitmask cannot be
On Thu, Jan 7, 2010 at 3:31 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I don't necessarily know what the right thing to do with the new ones
is, but I am pretty sure that pg_indent will revert any changes you
make to the existing ones.
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2009 17:06, Tom Lane a écrit :
I think we were
On Thu, Jan 7, 2010 at 7:02 AM, Leonardo F m_li...@yahoo.it wrote:
attached a patch that adds the following functions for bit string:
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
The next CommitFest starts January 15th.
...Robert
--
Sent
On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure whether we ever posted this schedule anywhere official -
if so, I can't find it - but my understanding is that we have
consensus on the release schedule described here:
On Thu, Jan 7, 2010 at 16:47, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure whether we ever posted this schedule anywhere official -
if so, I can't find it - but my understanding is that we have
consensus on the
On Thu, Jan 7, 2010 at 10:50 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 7, 2010 at 16:47, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote:
I'm not sure whether we ever posted this schedule anywhere official -
if
On Wed, Jan 6, 2010 at 21:36, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The first of these in particular is a fairly detailed report of what
looks might be a fairly serious problem.
pg_listener entries deleted under heavy NOTIFY load only on Windows
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
Ok; but what about what I said about the difference between bit/string
substring?
That affects overlay behaviour for bit...
I've even got
ERROR: invalid memory alloc request size
On 2010-01-07 11:50 +0200, Craig Ringer wrote:
On 7/01/2010 9:15 AM, Robert Haas wrote:
Doing this without DBI is going to be ten times harder than doing it
with DBI. Are we really sure that's not a viable option?
At this point, I'm personally wondering if it's worth putting together a
On 2010-01-07 18:13 +0200, Marko Tiikkaja wrote:
I had a similar syntax in mind, but instead of using threads, just
execute the file in order using asynchronous connections.
I completely failed to make the point here which was to somehow mark
which statements will (or, should) block. So here
On Jan 6, 2010, at 6:26 PM, Tom Lane wrote:
We have not yet fully accepted the notion that you must have Perl to
build (and, in fact, I am right now trying to verify that you don't).
I don't think that requiring Perl to test is going to fly.
I believe that the build farm already requires
On Thu, Jan 7, 2010 at 11:05 AM, Leonardo F m_li...@yahoo.it wrote:
Thanks! Please add your patch here:
https://commitfest.postgresql.org/action/commitfest_view/open
Ok; but what about what I said about the difference between bit/string
substring?
That affects overlay behaviour for
Greg Sabino Mullane g...@turnstep.com writes:
We could even bundle DBI and DBD::Pg to ensure that the minimum versions
are there.
As a packager, my reaction to that is over my dead body. We have
enough trouble keeping our own software up to date, and pretty much
every external component that
David E. Wheeler wrote:
On Jan 6, 2010, at 6:26 PM, Tom Lane wrote:
We have not yet fully accepted the notion that you must have Perl to
build (and, in fact, I am right now trying to verify that you don't).
I don't think that requiring Perl to test is going to fly.
I believe that
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
As there were so many boolean SomethingCancelPending variables I changed them
to be bitmasks and merged all of them into a single variable.
This seems like a truly horrid idea, because
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
I have reworked Simon's patch a bit and attach the result.
Oh dear, this is exactly what I've been working on...
Sorry, as you have posted a first patch some days
On Wed, Jan 6, 2010 at 3:03 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
I've done that in my git branch.
Could you push that git branch to a public place?
Ahh, sorry, forgot that again. It's there now, at
On Thu, Jan 7, 2010 at 11:46 AM, Andrew Dunstan and...@dunslane.net wrote:
Using DBI/DBD::Pg would raise another issue - what version of libpq would it
be using? Not the one in the build being tested, that's for sure. If you
really want to use Perl then either a Pure Perl DBI driver (which Greg
Leonardo F m_li...@yahoo.it writes:
I've even got
ERROR: invalid memory alloc request size 4244635647
with:
SELECT substring(B'0001' from 5 for -2);
Hm, yeah, somebody was sloppy about exposing the three-argument
form of varbit substring and using -1 to represent the
On Wed, Jan 06, 2010 at 08:40:28PM -0500, Andrew Dunstan wrote:
A parallel psql seems to me a better way to go. We talked about that
a while ago, but I don't recall what happened to it.
Greg Stark had a patch a couple of years ago. Dunno what happened to
it since then.
Cheers,
David.
--
On Thu, 2010-01-07 at 17:50 +0100, Joachim Wieland wrote:
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
I have reworked Simon's patch a bit and attach the result.
Oh dear, this is exactly what I've been
On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
Personally, I would rather have a release without SR in June or July
than a release with SR in August or September.
If SR will be ready until then, I'd like to see a release in September
which has SR in it. We already postponed SR a lot.
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
@Simon: Is there a reason why you have not yet removed recoveryConflictMode
from PGPROC?
Unfortunately we still need a mechanism to mark which backends have been
cancelled already. Transaction state for virtual transactions isn't
On Jan 6, 2010, at 6:31 PM, Kevin Grittner wrote:
As far as I've been able to determine so far, to call psql in a
relatively portable way would require something like this:
http://perldoc.perl.org/perlfork.html
Here's an example using IPC::Open3:
#!/usr/local/bin/perl -w
use
Andrew Dunstan and...@dunslane.net writes:
Unless I am mistaken, Perl is required in any case to build from CVS,
although not from a tarball.
Right, but to my mind building from a tarball needs to include the
ability to run the regression tests on what you built. So injecting
Perl into that
2010/1/7 Devrim GÜNDÜZ dev...@gunduz.org:
On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
Personally, I would rather have a release without SR in June or July
than a release with SR in August or September.
June, yes. July, frankly, no, because July == September, when it comes
to any
On Jan 7, 2010, at 9:08 AM, Tom Lane wrote:
Right, but to my mind building from a tarball needs to include the
ability to run the regression tests on what you built. So injecting
Perl into that is moving the goalposts on build requirements.
In that case, there's nothing for it except
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
@Simon: Is there a reason why you have not yet removed recoveryConflictMode
from PGPROC?
Unfortunately we still need a mechanism to mark which backends have been
cancelled already. Transaction
On Thursday 07 January 2010 18:10:43 Magnus Hagander wrote:
Not having our release schedule driven by marketing is a *strength* of
our project!
Yes.
We made the mistake last time to delay the release significantly for a
single feature. It turned out said feature didn't make it *anyway*.
David E. Wheeler da...@kineticode.com writes:
On Jan 7, 2010, at 9:08 AM, Tom Lane wrote:
Right, but to my mind building from a tarball needs to include the
ability to run the regression tests on what you built. So injecting
Perl into that is moving the goalposts on build requirements.
In
On Jan 7, 2010, at 9:19 AM, Tom Lane wrote:
In that case, there's nothing for it except concurrent psql.
Unless we are prepared to define concurrency testing as something
separate from the basic regression tests. Which is kind of annoying but
perhaps less so than the alternatives. It
2010/1/7 Magnus Hagander mag...@hagander.net:
2010/1/7 Devrim GÜNDÜZ dev...@gunduz.org:
On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
Personally, I would rather have a release without SR in June or July
than a release with SR in August or September.
June, yes. July, frankly, no,
Magnus Hagander mag...@hagander.net writes:
We made the mistake last time to delay the release significantly for a
single feature. It turned out said feature didn't make it *anyway*.
Let's not repeat that mistake.
Yeah, we've certainly learned that lesson often enough, or should I say
failed
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
However, HS is already in the tree, and HS without SR is a whole lot
less compelling than HS with SR. So it's going to be pretty
unsatisfying if we can't get SR in there.
I don't think that's the case. Having HS alone would be a huge win,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Unless we are prepared to define concurrency testing as something
separate from the basic regression tests. Which is kind of annoying but
perhaps less so than the alternatives. It certainly seems to me to
be the kind of thing you wouldn't
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
@Simon: Is there a reason why you have not yet removed recoveryConflictMode
from PGPROC?
Unfortunately we still need a mechanism to mark
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Using DBI/DBD::Pg would raise another issue - what version of libpq
would it be using? Not the one in the build being tested, that's for
sure.
Er...why not? That's what psql uses. As for those advocating using a
custom C program written
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
However, HS is already in the tree, and HS without SR is a whole lot
less compelling than HS with SR. So it's going to be pretty
unsatisfying if we can't get SR in there.
I don't think that's the case. Having HS
On Thu, Jan 7, 2010 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
We made the mistake last time to delay the release significantly for a
single feature. It turned out said feature didn't make it *anyway*.
Let's not repeat that mistake.
Yeah,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
while I agree that HS is very useful without SR, I think that it's
mostly the well known powerusers inthe community are actively waiting
for HS and not so much for SR. For the typical user outside of -hackers
or even -general I'm not so
Magnus Hagander wrote:
On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
I have a Windows-specific patch for open(), attached for reference.
But we need to consider about other issues:
- We need to consider about not only only open(), but also
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I think you should have users/kgrittner/postgres.git rather than
serializable.git. serializable sounds more like the branch name.
I'll wait a bit for other comments before taking any action.
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
While we're discussing this: the current coding with
AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe.
I realize that's just a toy placeholder, but getting rid of it has to be
on
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
guilla...@lelarge.info wrote:
Le 04/01/2010 22:36, Guillaume Lelarge a écrit :
Le 29/12/2009 14:12, Guillaume Lelarge a écrit :
Le 29/12/2009 00:03, Guillaume Lelarge a écrit :
Le 28/12/2009 22:59, Tom Lane a écrit :
Guillaume Lelarge
On Thu, Jan 7, 2010 at 19:08, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I think you should have users/kgrittner/postgres.git rather than
serializable.git. serializable sounds more like the
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
We could even bundle DBI and DBD::Pg to ensure that the minimum versions
are there.
As a packager, my reaction to that is over my dead body. We have
enough trouble keeping our own software up to date, and pretty much
every external
On Sun, Dec 27, 2009 at 2:12 PM, Andres Freund and...@anarazel.de wrote:
While unlikely to cause issues two new LWLockAcquire calls use the wrong
locking mode.
Patch attached.
Does it make sense to add this to the 2010-01 CommitFest so we don't
lose track of it?
...Robert
--
Sent via
Robert Haas robertmh...@gmail.com writes:
I like Andres' suggestion upthread of setting a deadline and
determining to bounce the patch if it's not committed by that date.
If it turns out we have to bounce it, that stinks, but I don't think
it makes sense to go to beta with a huge,
On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
While we're discussing this: the current coding with
AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe.
I realize that's
1 - 100 of 225 matches
Mail list logo
