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 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 database named
> > 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-hac
Tom Lane 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 uselessness; and to
On Thu, Jan 7, 2010 at 07:19, Fujii Masao wrote:
> On Wed, Jan 6, 2010 at 11:11 PM, Magnus Hagander 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 connect to? Perhaps it could/shou
On Thu, Jan 7, 2010 at 09:26, Fujii Masao 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 authentication configurat
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] http://developer.postgresql.org/pgdocs/postgres/high-availab
On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander 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 can be sup
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
On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander 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 CIDR-address auth-m
2010/1/7 Markus Wanner :
> (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 potentially
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
> >
On Thu, Jan 7, 2010 at 6:09 PM, Joshua Tolley 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.
> Comments?
>
>
On 7/01/2010 9:15 AM, Robert Haas wrote:
On Wed, Jan 6, 2010 at 4:52 PM, Kevin Grittner
wrote:
"David E. Wheeler" wrote:
Last I heard, Andrew was willing to require Test::More for
testing, so that a Perl script could handle multiple psql
connections (perhaps forked) and output test results
2010/1/7 Albe Laurenz :
> 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
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 f
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 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 of other u
On Thu, Jan 7, 2010 at 02:37, Takahiro Itagaki
wrote:
>
> Chuck McDevitt 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
>> data in UTF-16 encoded Unicode, regardl
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
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 she
On Wed, Jan 06, 2010 at 08:46:11PM -0500, Tom Lane wrote:
> Tim Bunce 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 versions l
On Wed, Jan 6, 2010 at 11:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 6, 2010 at 10:13 PM, Tom Lane wrote:
>>> Robert Haas writes:
What tools do we have for identifying memory leaks?
>>>
>>> User complaints :-(
>
>> YGTBFKM.
>
> Not really. Given the memory context archite
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' f
Tom Lane wrote:
> Peter Eisentraut 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 ca
Dave Page wrote:
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue 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
versi
On Thu, Jan 7, 2010 at 12:21 PM, Hiroshi Inoue wrote:
> Dave Page wrote:
>>
>> On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue 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 insta
Fujii Masao wrote:
> On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander 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?
>
> Y
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 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 farther than
>
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On mn, 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 pa
On Thu, Jan 7, 2010 at 10:21, Fujii Masao wrote:
> On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander 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 follow
On Thu, Jan 7, 2010 at 13:34, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Thu, Jan 7, 2010 at 5:44 PM, Magnus Hagander wrote:
Such information are supplied in the parameter 'primary_conninfo' of
recovery.conf. For example;
primary_conninfo = 'host=192.168.1.50 port
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
Postg
Stefan Kaltenbrunner 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 would just use it a
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs 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 introducing further
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
> On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs 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
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.
Why -o and not, say, -Z? I imagine you picked -o for "only" but it
seems strange.
--
Alvaro Herrera
2010/1/7 Albe Laurenz :
> 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 system that all
Tom Lane wrote:
Stefan Kaltenbrunner 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 would just
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 wrote:
> On 1/6/10 9:13 AM, Robert Haas wrote:
> > On Wed, Jan 6, 2010 at 12:06 PM, David Fetter wrote:
>
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.
>
>
> Why -o and not, say, -Z? I imagine you picked -o for "only" but it
> seems strange
Fujii Masao writes:
> On Thu, Jan 7, 2010 at 5:46 PM, Magnus Hagander 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
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 patc
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 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
-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 y
Joachim Wieland 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 manipulated atomica
On Thu, Jan 7, 2010 at 3:31 AM, Takahiro Itagaki
wrote:
>
> Tom Lane 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 chang
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 writes:
> Le 28/12/2009 17:06, Tom Lane a écrit :
>> I think we were st
On Thu, Jan 7, 2010 at 7:02 AM, Leonardo F 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 via pgsql-hacke
On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas 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:
>
> http://archives.postgresql.org/pgsql-hackers/2009-09/m
On Thu, Jan 7, 2010 at 16:47, Robert Haas wrote:
> On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas 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 10:50 AM, Magnus Hagander wrote:
> On Thu, Jan 7, 2010 at 16:47, Robert Haas wrote:
>> On Fri, Dec 25, 2009 at 3:09 PM, Robert Haas 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
On Wed, Jan 6, 2010 at 21:36, Tom Lane wrote:
> Robert Haas 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
>> http://archives.postgresql.org/pgsql-
> 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 42
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
simple
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 Pe
On Thu, Jan 7, 2010 at 11:05 AM, Leonardo F 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 bit...
>
"Greg Sabino Mullane" 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 we've started
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 th
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane wrote:
> Joachim Wieland 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
>
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs 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 ago I thought yo
On Wed, Jan 6, 2010 at 3:03 AM, Heikki Linnakangas
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
> git://git.postgresql.org/git/users/heikki/postgres.git, branch
> 'repl
On Thu, Jan 7, 2010 at 11:46 AM, Andrew Dunstan 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 has
> talked abo
Leonardo F 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 two-argument
form.
W
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.
--
Dav
On Thu, 2010-01-07 at 17:50 +0100, Joachim Wieland wrote:
> On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs 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...
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
visib
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 st
Andrew Dunstan 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 is moving the goa
2010/1/7 Devrim GÜNDÜZ :
> 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 such scheduling
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 con
Simon Riggs 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 state for virt
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" 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 that case,
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 :
> 2010/1/7 Devrim GÜNDÜZ :
>> 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,
Magnus Hagander 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 to learn that less
-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 would
On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
> Simon Riggs 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 bac
-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 u
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 a
On Thu, Jan 7, 2010 at 12:24 PM, Tom Lane wrote:
> Magnus Hagander 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 less
-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
> 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 opendir(),
> > stat() and
"Kevin Grittner" wrote:
> Robert Haas 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.
Robert's advice being the last (and only)
Simon Riggs 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 the list of s
On Thu, Jan 7, 2010 at 10:33 AM, Guillaume Lelarge
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 writes:
>>
On Thu, Jan 7, 2010 at 19:08, Kevin Grittner
wrote:
> "Kevin Grittner" wrote:
>> Robert Haas 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
-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 extern
On Sun, Dec 27, 2009 at 2:12 PM, Andres Freund 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 pgsql-hackers mailing
Robert Haas 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, barely-tested pile of code
> i
On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
> Simon Riggs 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 p
1 - 100 of 225 matches
Mail list logo
