On Wednesday 27 May 2009 23:02:19 Zdenek Kotala wrote:
> Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
> > Of course the concrete example that you show doesn't actually take
> > advantage of this, so if it is important to you, please send a patch to
> > fix it.
>
> Fix attached. I found on
On Thursday 28 May 2009 00:54:32 Tom Lane wrote:
> To wit, the current
> coding fails to respect the gettext domain when working with pluralized
> messages.
The ngettext() calls use the default textdomain that main.c sets up. The PLs
use dngettext(). Is that not correct?
--
Sent via pgsql-hac
Kevin Grittner wrote:
Greg Stark wrote:
Without any real way to represent predicates this is all pie in the
sky
And this is 180% opposite from what I just heard at PGCon should be
the focus of discussion at this point. Let's get agreement on what
would be nice user-facing behavior first.
On Wed, 27 May 2009, andy wrote:
I have a Sun blade 1000 that's just collecting dust now days...It weighs
a ton.
Bah, I know I picked one of those up myself once, which means it's far
from being what I'd consider a heavy server as Sun hardware goes. Specs
say it's 70 pounds and pulls 670W.
On Wed, May 27, 2009 at 10:00 PM, Josh Berkus wrote:
> Andy,
>
>> I have a Sun blade 1000 that's just collecting dust now days. I was
>> wondering if there were any pg-hackers that could find use for it.
>>
>> Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
>> scsi disks.
On Wed, May 27, 2009 at 10:02 PM, Josh Berkus wrote:
> Robert,
>
>> However, since we're on that tangent, I'm not completely convinced
>> that additional lists of search paths that get prepended or appended
>> to the main search path are the right way to go. It seems like that's
>> just chopping
On Wed, May 27, 2009 at 10:09 PM, Aidan Van Dyk wrote:
> * Robert Haas [090527 21:30]:
>
>> > And actually looking at the history of the gpo repo, the branches are all
>> > messed up with "merges" and stuff that I'm not sure where they are coming
>> > from... 8.2, 8.3, and master(HEAD) are all t
On Wed, May 27, 2009 at 9:49 PM, Tom Lane wrote:
> Greg Stark writes:
>> Without any real way to represent predicates this is all pie in the
>> sky. The reason we don't have predicate locking is because of this
>> problem which it sounds like we're no closer to solving.
>
> Yeah. The fundamental
Tom Lane wrote:
> Bruce Momjian writes:
> > Is this a TODO item?
>
> We already have a TODO item about replacing GEQO.
>
> However, linking to this thread might be more useful than the 404 that's
> there now...
Removed and added.
--
Bruce Momjian http://momjian.us
EnterpriseDB
I wrote:
> Running some performance tests now.
Preliminary tests comparing 8.4beta2 to the snapshot from March 2nd
show different plans which perform at the same speed (within the
noise) when fully cached. It appears that the beta2 plan performed
much better when it wasn't cached, but I wasn'
Bruce Momjian writes:
> Is this a TODO item?
We already have a TODO item about replacing GEQO.
However, linking to this thread might be more useful than the 404 that's
there now...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
* Robert Haas [090527 21:30]:
> > And actually looking at the history of the gpo repo, the branches are all
> > messed up with "merges" and stuff that I'm not sure where they are coming
> > from... 8.2, 8.3, and master(HEAD) are all the same as my gpo repo, but the
> > back branchs are very bad.
Is this a TODO item?
---
Adriano Lange wrote:
> Hi
>
> Tobias Zahn escreveu:
> > Hello Adriano,
> > thank you very much for posting your patch. I think it will help to make
> > further work easier, too. I hope you don't min
Robert,
However, since we're on that tangent, I'm not completely convinced
that additional lists of search paths that get prepended or appended
to the main search path are the right way to go. It seems like that's
just chopping up the problem into smaller bits without really fixing
anything. I
Andy,
I have a Sun blade 1000 that's just collecting dust now days. I was
wondering if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel
scsi disks.
It weighs a ton.
I'd be happy to donate it to a good cause.
Feh,
On Wed, 27 May 2009, Kevin Grittner wrote:
"Marc G. Fournier" wrote:
I'm curious as to what is different about these vs all the other
tags I've ever done, both before, and after ...
Any chance you tagged, changes were committed, and you then tagged
files from such a later commit as part of
Greg Stark wrote:
> Postgres supports a whole lot more scan types than just these two
> and many of them use multiple indexes or indexes that don't
> correspond to ranges of key values at all.
Well, certainly all of the plans I've looked at which use btree
indexes could be handled this way. T
--
Greg
On 28 May 2009, at 02:49, Tom Lane wrote:
Greg Stark writes:
Without any real way to represent predicates this is all pie in the
sky. The reason we don't have predicate locking is because of this
problem which it sounds like we're no closer to solving.
Yeah. The fundamental
I have a Sun blade 1000 that's just collecting dust now days. I was wondering
if there were any pg-hackers that could find use for it.
Its dual UltraSPARC III 750 (I think) and has two 36? gig fiber channel scsi
disks.
It weighs a ton.
I'd be happy to donate it to a good cause.
-Andy
--
Greg Stark writes:
> Without any real way to represent predicates this is all pie in the
> sky. The reason we don't have predicate locking is because of this
> problem which it sounds like we're no closer to solving.
Yeah. The fundamental problem with all the "practical" approaches I've
hear
I find it pretty hard to beleive that 8k is precisely where a drop in
performance shows up unless there's some peculiar reason.
The only peculiar reason I can imagine is full page writes. If the
dbt2 workload is modifying already full pages then the full page
writes will always be just shy
On Wed, May 27, 2009 at 5:22 PM, Aidan Van Dyk wrote:
> gpo: from git://git.postgresql.org/git/postgresql.git
> git: from git://repo.or.cz/PostgreSQL.git
[...]
> But the gpo conversion seems to be in pretty bad shape:
> ai...@db1-dapper:/tmp$ grep 'new file' pg-gpo-* | wc
>
On 28 May 2009, at 01:51, "Kevin Grittner"
wrote:
At the point where we added an escalation
to table locking for the limit, started with the table lock when we
knew it was a table scan, and locked the index range for an index
scan,
I still think you're stuck in the mssql/sybase mode of t
On Wed, May 27, 2009 at 9:00 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I think we should introduce a new value for SET TRANSACTION
> ISOLATION
>> LEVEL, maybe SNAPSHOT, intermediate between READ COMMITTED and
>> SERIALIZABLE.
>
> The standard defines such a level, and calls it REPEATABL
On Wed, May 27, 2009 at 9:01 PM, Josh Berkus wrote:
> Sure. I think that having better search path management would be a
> wonderful thing; it would encourage people to use schema more in general.
>
> However, that doesn't mean that I think it should be part of the extensions
> design, or even a
"Marc G. Fournier" wrote:
> I'm curious as to what is different about these vs all the other
> tags I've ever done, both before, and after ...
Any chance you tagged, changes were committed, and you then tagged
files from such a later commit as part of the release, or moved the
tag to the later
On Wed, 2009-05-27 at 20:38 -0400, Tom Lane wrote:
> A lesson that I think we've learned the hard way over the past few years
> is that GUCs are fine for controlling performance issues, but you expose
> yourself to all sorts of risks if you make fundamental semantics vary
> depending on a GUC.
I a
On Wed, 2009-05-27 at 20:55 -0400, Tom Lane wrote:
> Hmm, what I gathered was that that's not changing any basic semantic
> guarantees (and therefore is okay to control as a GUC). But I haven't
> read the paper so maybe I'm missing something.
On second read of this comment:
http://archives.postgr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, May 27, 2009 16:33:28 +0300 Peter Eisentraut
wrote:
> On Wednesday 27 May 2009 00:54:52 Marc G. Fournier wrote:
>> So, you are suggesting:
>>
>> cvs -q tag -d REL7_1_BETA2 .
>> cvs -q tag -d REL7_1_BETA3 .
>
> Note that there ar
Mark Wong writes:
> Oopsies. I've rerun, but now that there is no dip, the average
> throughput still didn't change much:
> BS notpm % Change from default
> -- - --
> 1 14673 -5.1%
> 2 15864 2.7%
> 4 15774 2.1%
> 8 15454 (default)
> 16 16118 4.3%
> 32 16051 3.9%
> 64 14874 -3.8%
Tom Lane wrote:
> Hmm, what I gathered was that that's not changing any basic semantic
> guarantees (and therefore is okay to control as a GUC). But I
> haven't read the paper so maybe I'm missing something.
The paper never suggests attempting these techniques without a
predicate locking impl
Tom,
Well, we could certainly take that attitude and eliminate all this
hassle ;-). However, I think that more-flexible search path handling
might have other uses, so I don't see any reason not to think about it.
Sure. I think that having better search path management would be a
wonderful t
Robert Haas wrote:
> I think we should introduce a new value for SET TRANSACTION
ISOLATION
> LEVEL, maybe SNAPSHOT, intermediate between READ COMMITTED and
> SERIALIZABLE.
The standard defines such a level, and calls it REPEATABLE READ.
Snapshot semantics are more strict than required for tha
On Wed, 2009-05-27 at 19:51 -0500, Kevin Grittner wrote:
> Jeff Davis wrote:
>
> > 1. implementation of the paper's technique sans predicate locking,
> > that would avoid more serialization anomalies but not all?
>
> I saw that as a step along the way to support for fully serializable
> transa
Jeff Davis writes:
> On Wed, 2009-05-27 at 20:38 -0400, Tom Lane wrote:
>> * Anything else you want to control should be a GUC, as long as it
>> doesn't affect any correctness properties.
> But that still leaves out another behavior which avoids some of the
> serialization anomalies currently pos
On Wed, May 27, 2009 at 1:46 AM, Simon Riggs wrote:
>
> On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
>> It appears for this workload using a 16KB or 32KB gets more than 4%
>> throughput improvement, but some of that could be noise.
>
> The baseline appears to have a significant jump in txn
Jeff Davis wrote:
> 1. implementation of the paper's technique sans predicate locking,
> that would avoid more serialization anomalies but not all?
I saw that as a step along the way to support for fully serializable
transactions. If covered by a "migration path" GUC which defaulted to
curren
On Wed, May 27, 2009 at 7:54 PM, Kevin Grittner
wrote:
> Jeff Davis wrote:
>> On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
>
>>> (C) One or more GUCs will be added to control whether the new
>>> behavior is used when serializable transaction isolation is
>>> requested or whether, for
Jeff Davis writes:
> On Wed, 2009-05-27 at 18:54 -0500, Kevin Grittner wrote:
>> I've gotten the distinct impression that some would prefer to continue
>> to use their existing techniques under snapshot isolation. I was sort
>> of assuming that they would want a GUC to default to legacy behavior
Tom Lane wrote:
Josh Berkus writes:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
Well, we could certainly take that attitude and eliminate all this
hassle ;
On Wed, 2009-05-27 at 18:54 -0500, Kevin Grittner wrote:
> I've gotten the distinct impression that some would prefer to continue
> to use their existing techniques under snapshot isolation. I was sort
> of assuming that they would want a GUC to default to legacy behavior
> with a new setting for
Josh Berkus writes:
> Personally, if we're tracking stuff through special dependancies which
> pg_dump will be aware of anyway, I don't see why extension objects
> should go into a special schema.
Well, we could certainly take that attitude and eliminate all this
hassle ;-). However, I think t
Tom,
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension into a different schema. It's not really related to how
we track which objects belong to which extension.
Really, they're on their own.
Eith
Jeff Davis wrote:
> On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
>> (C) One or more GUCs will be added to control whether the new
>> behavior is used when serializable transaction isolation is
>> requested or whether, for compatibility with older PostgreSQL
>> releases, the transac
On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
> (2) The standard requires this because it is the only cost-effective
> way to ensure data integrity in some environments, particularly those
> with a large number of programmers, tables, and queries; and which
> have complex data integrity
Joe Conway writes:
> The attached addresses items#2 and 3 as listed by Bruce here:
>http://momjian.us/cgi-bin/pgsql/joe
> I think it is consistent with the discussions we had a PGCon last week.
> Any objections to me committing this for 8.4?
It's hard to review it without any docs that say
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
Linux version 2.6.16.60-0.31-smp (ge...@buildhost) (gcc version 4.1.2
20070115 (SUSE Linux)) #1 SMP Tue Oct 7 16:16:29 UTC 2008
./configure --prefix=/usr/local/pgsql-8.4beta2
--enable-integer-datetimes --enable-debug --disable-n
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement.
Yeah, I likes.
Some folks on this
lis
On Mon, May 25, 2009 at 11:16 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Preliminary note: I'm using the term "extension" as if it's what we
> already agree to call them, feel free to ignore this and use whatever
> term you see fit. We'll have the naming issue tackled, please not now
> though.
>
[.
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection paramete
Peter Eisentraut writes:
> On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
>> I experimented with this and found that indeed both format strings are
>> checked ... if you have a reasonably recent libintl.h AND you have
>> specified --enable-nls. Otherwise it all goes to heck, apparently
>> becaus
Greetings, Please help provide a chm file for 8.4b2. Unlike prior Windows
installations, the postgreSQL.chm is absent. This file format provides very
valuable searching capabilities.
Appreciatively! --LS
Larry Silvermintz, Ph.D.| Biologist & Engineer
(510) 705-1432
--
Sent via pg
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
wrote:
> On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
> wrote:
>> At a normal startup, the checkpoint record would be there as usual. And an
>> archive recovery starts at the location indicated by the backup label.
>>
>> AFAICS calling Reques
All,
Wait, I thought we'd given up on the search path model and wanted to
track extensions via dependencies. No?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Yes, in Python >= 2.4 there is the Decimal datatype.
However, unlike the other mappings employed by plpythonu, Decimal requires an
import statement to be in scope.
-Caleb
On 5/27/09 2:07 PM, "Tom Lane" wrote:
Peter Eisentraut writes:
> On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
>>
Josh Berkus writes:
> Wait, I thought we'd given up on the search path model and wanted to
> track extensions via dependencies. No?
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension into a different
* Heikki Linnakangas [090527 07:29]:
> OTOH, there's some value in staying with current GIT repository. In
> EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
> repository that's based on the PostgreSQL mirror. If PostgreSQL switches
> to a new GIT repository/mirror, I'l
Robert Haas wrote:
> Tom and Bruce do give way before a clear consensus, but on the other
> hand I think Simon is right that there was never much chance of
> getting anything committed here without Heikki's endorsement, which
> was slow in coming by his own admission. (I'm not in any way saying
>
Andrew Dunstan writes:
> Another way of handling this might be to provide for prepending or
> appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement. Some folks on this
list might recognize the following coding pattern:
create
On Monday 25 May 2009 00:55:17 Tom Lane wrote:
> 2. In tsearch.sql, there are multiple places where the test is trying
> to exercise some just-created index. This works as expected if the
> tests are run serially, but the indexes are (usually) not used if the
> tests are run in parallel. The reas
Peter Eisentraut writes:
> On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
>> ... My own
>> feeling on the matter is that PyFloat is the wrong mapping for numeric, but
>> I didn't want to muddy this patch by changing that.
> Yeah, that one had me wondering for a while as well, but as you sa
Here is output of:
for FILE in `find . -name *.po`;do LC_ALL=C msgfmt -v -o /dev/null $FILE
2>> msgfmt.txt; done
Zdenek
Peter Eisentraut píše v st 27. 05. 2009 v 23:08 +0300:
> On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
> > The problem here is (1 row) instead of (%lu row). When
Andrew Gierth writes:
> Splitting up search_path is something I've been thinking about for a
> while (and threw out on IRC as a suggestion, which is where Dimitri
> got it); it was based on actual experience running an app that set the
> search path in the connection parameters in order to select
Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection parameters in order to select which
On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
> Previously numeric->string->PyFloat_FromString, now
> numeric->double->PyFloat_FromDouble, which makes use of postgres
> numeric->double routines rather than python string->double routines, and it
> is conceivable that there are precision vari
> "David" == "David E Wheeler" writes:
>> The moment you're adding specific schemas where to put extensions
>> into, you have to adapt your search_path. Some applications
>> already have to manage search_path for their own needs, so we're
>> trying to avoid having those people to care abo
Peter Eisentraut writes:
> On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
>> I experimented with this and found that indeed both format strings are
>> checked ... if you have a reasonably recent libintl.h AND you have
>> specified --enable-nls. Otherwise it all goes to heck, apparently
>> becaus
I want to try to get agreement that it would be a good idea to
implement serializable transactions, and what that would look like
from the user side. At this point, we should avoid discussions of
whether it's possible or how it would be implemented, but focus on
what that would look like and wheth
On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
> Peter Eisentraut writes:
> > I tried throwing various kinds of subtle garbage into the errmsg/ngettext
> > line, but it was all discovered by gcc -Wall.
>
> I experimented with this and found that indeed both format strings are
> checked ... if you
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
> The problem here is (1 row) instead of (%lu row). When I run msgfmt
> without -v everything works fine but I think we should fixed it (there
> are more occurrences of this issue).
I don't think we can find all these occurrences without the Sola
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
> Of course the concrete example that you show doesn't actually take advantage
> of this, so if it is important to you, please send a patch to fix it.
Fix attached. I found only two problems, both in psql. I did not fix .po
files. Is necess
On Monday 25 May 2009 17:52:07 Zdenek Kotala wrote:
> Peter Eisentraut píše v ne 24. 05. 2009 v 00:40 +0300:
> > I think this is not the best way to do it, because it will confuse
> > pgindent and editors and such. The DATA() macros in include/catalog have
> > this solved; see include/catalog/genb
Simon Riggs wrote:
> Do we need table-level predicate locks at all? What would they give
> us? Why not just go straight for fine-grained page-level locks?
I don't want to get too far into implementation discussions at this
phase (see Tom's slides ;-)), but suffice it to say that a table scan
All data types should map to the same python object types as they did before,
so int32->PyInt, int64->PyLong, numeric->PyFloat, etc.
The conversion routines are slightly different, eg int32 is initialized via
PyInt_FromLong() instead of first converting the integer to a string then
calling PyIn
On Wed, 2009-05-27 at 13:34 -0500, Kevin Grittner wrote:
> For the record, it became clear that I did a bad job of communicating
> on this thread...
You did good work, IMHO. Not everything will reach consensus and that's
not your fault.
> first implement table level predicate
> locks, since tha
I wrote:
> Greg Stark wrote:
>> This thread has really been one of those cases where everyone
>> thought they were having a different kind of discussion.
>
> Apparently so.
In light of discussions at PGCon, I'm going to abandon this thread in
favor of a discussion of what this feature would
On Wed, 2009-05-27 at 17:39 +0300, Heikki Linnakangas wrote:
> I agree we could've should've handled this more promptly, and I'll take
> my part of the blame for that. I let the various proposed patches sit
> for long times before reviewing them thoroughly, partly because I was
> busy and part
On Wed, 2009-05-27 at 13:14 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > My experience is that consensus/votes will be overruled by final
> > committer, if they disagree,
>
> That's a fairly strong statement.
I was attempting to be open and honest to allow us to face our faults,
On Wed, May 27, 2009 at 1:14 PM, Andrew Dunstan wrote:
> Simon Riggs wrote:
>>
>> My experience is that consensus/votes will be overruled by final
>> committer, if they disagree,
>
> That's a fairly strong statement. I can't think of an occasion when this has
> happened on any matter of significan
On May 27, 2009, at 1:50 AM, Dimitri Fontaine wrote:
The moment you're adding specific schemas where to put extensions
into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid
having
those people to care abou
On May 23, 2009, at 9:51 PM, Robert Haas wrote:
vacuums everything. ISTM it'd be useful to be able to just vacuum all
databases in a cluster, so I hacked it into vacuumdb.
I think you meant "ISTM it'd be useful to be able to just analyze all
databases in a cluster".
Heh. "Oops".
Of course, u
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement. I can't think of an occasion when this
has happened on any matter of significance, and I can remember many
times when Tom, Bruce and others
On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
> >
> > > We are not going to improve unless we face our faults.
> >
> > True. Who or what is at fault, in your opinion?
>
> Well, we knew there was an i
Simon Riggs wrote:
>
> On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
>
> > We are not going to improve unless we face our faults.
>
> True. Who or what is at fault, in your opinion?
Well, we knew there was an issue but we didn't finalize our conclusions
and address it as best we could
On Wed, May 27, 2009 at 11:44 AM, Markus Wanner wrote:
> Peter Eisentraut wrote:
>>> In what way do you consider the tags "broken"?
>> The tag applies to different commits on different files.
> That's perfectly valid for CVS (and can be represented in subversion as
> well). Such a tag cannot (easi
Hi,
Peter Eisentraut wrote:
> http://archives.postgresql.org/pgsql-hackers/2008-12/msg01879.php
Thanks for the link. I'm assuming you've adjusted the tags to fit a
single commit.
Out of curiosity: do you think (or have evidence that) this is the only
tag that spans multiple commits?
>> In what
Robert Haas wrote:
> I noticed in Bruce's talk that there are a number of post-migration
> steps which are currently partially manual. Ideally we'd like to
> automate them all, preferably in some sort of well-thought-out
order.
> I actually suspect this is something like: analyze each database,
Hi,
On Wed, May 27, 2009 at 10:49 PM, Simon Riggs wrote:
>
> On Wed, 2009-05-27 at 21:28 +0900, Fujii Masao wrote:
>> Hi,
>>
>> On Wed, May 27, 2009 at 3:27 PM, Kolb, Harald (NSN - DE/Munich)
>> wrote:
>> > In our use case it's important to have a short failover time.
>> > So everything what kee
Aidan Van Dyk wrote:
* Heikki Linnakangas [090527 07:29]:
OTOH, there's some value in staying with current GIT repository. In
EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
repository that's based on the PostgreSQL mirror. If PostgreSQL switches
to a new GIT reposit
On Wed, 2009-05-27 at 09:51 -0400, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Simon Riggs wrote:
> > >
> > > On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> > > >
> > > > I think the big frustration is that this issue was first brought up
> > > > March 25 and it took two months to
Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
I think the big frustration is that this issue was first brought up
March 25 and it took two months to resolve it, at which point we were in
beta. I think many hoped a better i
* Heikki Linnakangas [090527 07:29]:
> OTOH, there's some value in staying with current GIT repository. In
> EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
> repository that's based on the PostgreSQL mirror. If PostgreSQL switches
> to a new GIT repository/mirror, I'l
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
> We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (p
Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> > > Tom Lane wrote:
> > > > Heikki Linnakangas writes:
> > > > > I don't think we're going to get this to work reliably without
> > > > > extending
> > > > > the interface between the bac
* Marc G. Fournier [090526 18:00]:
>> Specifically, it's 2 tags, and I just remove them:
>>REL7_1_BETA2
>>REL7_1_BETA3
>
> So, you are suggesting:
>
> cvs -q tag -d REL7_1_BETA2 .
> cvs -q tag -d REL7_1_BETA3 .
>
> correct?
Not directly, I claim *no* knowledge of the safety of any CVS co
* Markus Wanner [090527 06:20]:
> Has anybody ever tried using cvs2git? Being based on cvs2svn, it should
> yield better results than cvsps. It's even recommended from the issues
> section of the git-cvsimport man page [1]. And git-cvsimport seems to be
> able to continue from an initial impor
Simon Riggs wrote:
>
> On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Heikki Linnakangas writes:
> > > > I don't think we're going to get this to work reliably without
> > > > extending
> > > > the interface between the backend and restore_command. We've discu
On Wed, 2009-05-27 at 21:28 +0900, Fujii Masao wrote:
> Hi,
>
> On Wed, May 27, 2009 at 3:27 PM, Kolb, Harald (NSN - DE/Munich)
> wrote:
> > In our use case it's important to have a short failover time.
> > So everything what keeps the time low, would be good to have.
>
> Yes. I think that it's
Greg Stark writes:
> On Wed, May 27, 2009 at 12:47 AM, Tom Lane wrote:
>> I'm not too thrilled about that solution because it still eliminates
>> predictability of execution of volatile functions.
> How so? It means the volatile function might only be executed for the
> matching rows
Exactly.
On Wednesday 27 May 2009 05:51:05 Mark Wong wrote:
> BS notpm % Change from default
> -- - --
> 1 14673 -4.8%
> 2 15864 2.9%
> 4 15774 2.3%
> 8 15413 (default)
> 16 16118 4.6%
> 32 16051 4.1%
> 64 14874 -3.5%
This means that both somewhat larger and somewhat smaller than 8 give bet
1 - 100 of 125 matches
Mail list logo
