On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs wrote:
> That was not the feedback I have received. Nobody has commented on that
> to me, though many have commented on the need for the current patch. As
> mentioned, I went to the trouble of running a meeting to gain additional
> feedback and the resu
On Wed, Dec 23, 2009 at 7:42 PM, Tom Lane wrote:
> I'm still not really eager to introduce yet another category of
> keywords, but perhaps it is worth doing. Comments?
If we consider that they can now be a problem in pl/pgsql, it might be
a good idea to consider it for this release.
(I'm thinki
On Sun, Oct 25, 2009 at 10:08 AM, Peter Eisentraut wrote:
> As a file point, I would prefer something like
>
> include 'whatever/*.conf'
+1 for that. That's what Apache does and it works well for the users
and the packagers.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Fri, Oct 16, 2009 at 9:26 PM, Tom Lane wrote:
> So, while I do think it's something we should leave alone until it gets
> in the way, this is a sufficiently large value of "in the way" that I'm
> willing to talk about removing add_missing_from. I'm just concerned
> about the impact of that, co
Hi Magnus,
On Mon, Sep 14, 2009 at 9:41 PM, Magnus Hagander wrote:
> First, the patch removes the logging_collector parameter and basically
> assumes that logging_collector is always on.
Alvaro commited this a few days ago:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?
On Thu, Aug 27, 2009 at 12:03 AM, Dimitri
Fontaine wrote:
> Is the offering good enough? We might need to run some kind of tutorials
> for users to be able to run large tests easily, and maybe think about
> some newer tools allowing to compare logs of two application runs in two
> database versions
Pierre,
On Thu, Aug 6, 2009 at 11:39 AM, PFC wrote:
> The best for this is lzo : very fast decompression, a good compression ratio
> on a sample of postgres table and indexes, and a license that could work.
The license of lzo doesn't allow us to include it in PostgreSQL
without relicensing Postgr
On Fri, Jul 3, 2009 at 9:14 PM, Peter Eisentraut wrote:
> On Sunday 10 May 2009 15:32:26 Guillaume Smet wrote:
>> I attached a patch which allows to add the SQL state code into the
>> log_line_prefix. I used %e (as in error) as %s is already used.
>
> Committed.
Thanks
On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan wrote:
> You have correctly identified the requirement in the sentence quoted above.
> I for one am quite prepared to support core or some person designated by
> core having such authority. I agree with you that without something like
> that not much
2009/6/17 Petr Jelinek :
> I agree that Default ACLs are more important and I already offered Stephen
> help on that. But I've seen countless requests for granting on all tables to
> a user and I already got some positive feedback outside of the list, so I
> believe there is demand for this. Also t
On Mon, Jun 1, 2009 at 10:40 PM, Tom Lane wrote:
> We could certainly put in a quick hack that just covered a few of the
> cases for built-in types, but it's not very pleasing ...
Jonah proposed a patch for that a long time ago.
See http://archives.postgresql.org/pgsql-patches/2006-10/msg00154.p
On Thu, May 28, 2009 at 6:06 PM, Simon Riggs wrote:
> On Thu, 2009-05-28 at 17:50 +0200, Guillaume Smet wrote:
>
>> I think it's a step forward, maybe not sufficient for you but I prefer
>> the situation now than before. It's safer because of the principle of
>>
On Thu, May 28, 2009 at 5:36 PM, Simon Riggs wrote:
> If you feel we have moved forwards, that's good, but since no part of
> the *safe* maintenance procedure has changed, I don't see that myself.
> Only the unsafe way of doing it got faster.
I disagree with you.
The situation was:
- you stop th
On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
wrote:
> So you check. This solves Guillaume's immediate concern. If you have a
> suggestion for further improvements, I'm all ears.
Thanks for applying the patch.
Yes, the problem is that before this change, even with a working
replication and
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.
&g
On Sun, May 10, 2009 at 4:07 PM, Tom Lane wrote:
> This might or might not be worth doing, but it seems pretty nearly
> entirely useless for the claimed purpose. What is your division between
> "user errors" and "system errors", and how will the SQLSTATE help you
> make that?
We use http://www.p
On Sun, May 10, 2009 at 3:29 PM, Andrew Dunstan wrote:
> If we're going to do this I think it needs to be added to CSV log output
> too.
AFAICS, it's already done for the CSV output hence my "the only way to
have the SQL state in the *standard* log file".
Did I miss something?
Thanks for your f
On Sun, May 10, 2009 at 2:32 PM, Guillaume Smet
wrote:
> I attached a patch which allows to add the SQL state code into the
> log_line_prefix. I used %e (as in error) as %s is already used.
Patch added to the next commit fest page.
--
Guillaume
--
Sent via pgsql-hackers mailing list
Hi -hackers,
A customer of us recently wanted to separate user errors from system
errors as different teams are working on these 2 types of errors and
while they might want to ignore user errors (bad-written SQL queries
and so on), they want to be sure system errors are analyzed carefully.
A good
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 RequestXLogSwitch() before CreateCheckPoint would be
> equivalent to c
On Tue, Apr 21, 2009 at 11:38 AM, wrote:
> I've queries returning tupels of A, with a (sub-)selected constant-expression
> that indicates whether a referenced tupel exists in B or not. For this issue
> the EXISTS clause is used.
>
> In past (8.3) the planner resolves this into index-scans using
Hi,
On Wed, Apr 8, 2009 at 9:11 PM, I wrote:
> Following the discussion here
> http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
> , I wrote a small patch which rotates the last XLog file on shutdown
> [snip]
Any comment or advice on how I can fix it with a different me
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao wrote:
> 1. the trigger file containing "smart" is created.
> 2. pg_standby is executed.
>2-1. nextWALfile is restored.
>2-2. the trigger file is deleted because nextWALfile+1 doesn't exist.
> 3. the restored nextWALfile is applied.
> 4. pg_stan
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao wrote:
> One idea to solve this problem is to tell pg_standby as a
> command-line argument about whether the trigger file can be
> removed. That parameter value can be set to 'true' when the last
> applied record is re-fetched. Though pg_standby is call
On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao wrote:
> RequestXLogSwitch() doesn't wait until the switched WAL file has
> actually been archived. So, some WAL files still may not exist in
> the standby server also after clean shutdown of the primary.
Thanks for your comment.
RequestXLogSwitch() do
Hi,
Following the discussion here
http://archives.postgresql.org/message-id/49d9e986.8010...@pse-consulting.de
, I wrote a small patch which rotates the last XLog file on shutdown
so that the archive command is also executed for this file and we are
sure we have all the useful XLog files when we p
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao wrote:
> Here is the patch;
> - Smart failover is chosen if the trigger file labeled "smart" or
> an empty one exists.
> - Fast failover is chosen if the trigger file labeled "fast" exists,
> the signal (SIGUSR1 or SIGINT) is received or the wait timeo
On Wed, Apr 1, 2009 at 11:44 PM, Kevin Grittner
wrote:
> Where does GPL come into it? (I hadn't seen that mentioned before for
> either product.)
Richard is one of the developers of Snowball so he might want to keep
its license compatible with GPL2.
Moreover, Snowball is used by a lot of projec
On Sat, Mar 28, 2009 at 11:05 PM, Bruce Momjian wrote:
> Based on mentions of his name in previous release notes, you are
> correct; change committed.
Thanks Bruce.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander wrote:
> That can be argued to just be completing the pg_hba rewrite stuff that
> happened long before november with the final logical step.
>
> I guess if you stretch that definition as well, this could also be an
> extension to that :)
Yes, that
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
wrote:
> 2009/3/27 Tatsuhito Kasahara :
>> But if I can also check last query string, I guess which apllication
>> do that and point out the problem point.
>
> Oh, I just understand why you want this patch. I usually have one
On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao wrote:
> OK, I'll change the patch as Simon suggested; removing -t and adding
> two new options: -f = fast failover (existing behavior), -p patient failover.
> Also I'll default the patient failover, so it's performed when the signal
> (SIGINT or SIGUSR
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut wrote:
> Simon Riggs wrote:
>>
>> If we go with this, I would suggest we make *neither* the default by
>> removing -t, and adopting two new options: something like -f == fast
>> failover, -p == patient failover.
>
> -m smart|fast|immediate :-)
Th
On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas wrote:
> Perhaps so, but again, it's not a new regression, so why should it be
> considered a blocker for 8.4beta?
I agree they shouldn't. You were talking about bumping them to 8.5
which is a totally different thing.
--
Guillaume
--
Sent via pgsql
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs wrote:
> Or take it further back still and think about why "idle in transaction"
> occurs at all and fix *that*. Maybe not in Postgres at all, possibly in
> the driver or even higher up client stack.
>From my experience, the main reasons for this probl
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote:
> I think we should also boot everything in the "pre-existing bugs"
> category, and the first two items from the "questions" category, which
> don't seem important enough to worry about at this stage of the game.
> That would leave us with 14 ite
2009/3/27 Tatsuhito Kasahara :
> But if I can also check last query string, I guess which apllication
> do that and point out the problem point.
Oh, I just understand why you want this patch. I usually have one
database per server so I didn't see your point.
Considering this usage, +1 for me.
--
On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian wrote:
> Guillaume Smet wrote:
>> - "Add -M (query mode) to /contrib/pgbench (ITAGAKI Takahiro)"
>> ->Itagaki san's name inconsistent with other mentions of his name
>
> Above all fixed, thanks.
I think you f
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas wrote:
> That includes a whole slough of patches that weren't submitted until
> after November 1st and which I think should probably be bumped en
> masse to 8.5:
>
> postgresql.conf: patch to have ParseConfigFile report all parsing
> errors, then bail
On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs wrote:
> Why do we have separate parameters for autovacuum and vacuum, except for
> maintenance_work_mem?
>
> Should we also have autovacuum_work_mem?
We already discussed it here:
http://archives.postgresql.org/message-id/49353a69.20...@hagander.net
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs wrote:
> Earlier, we discussed having a single trigger file that contains an
> option rather than two distinct trigger files. That design is better
> because it allows the user to choose at failover time, rather than
> making a binding decis
Bruce,
Here is the second set of comments:
- pg_hba.conf: it seems to me the format has changed which may break
existing pg_hba.conf (it broke the default one of the RPM packaging).
We should make it very visible as the format hasn't changed for a
while. I suppose we'll put it at the top but I ju
Hi,
Just to warn people that I'm making a comprehensive proof reading of
the release notes.
Here are the first comments:
- "This was available previously via a configure
--enable-integer-datetimes (Neil Conway)" -> I don't think we need
Neil's name in the details
- "New semi- and ansi-joins (Tom
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao wrote:
> What does "the default" mean? You mean that new trigger should use
> the existing trigger option character (-t)?
Yes, that's my point.
I understand it seems weird to switch the options but I'm pretty sure
a lot of persons currently using -t w
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
wrote:
> I would love to get it, but when I suggested it some time in the past
> Tom shot it down as bad idea.
>
> http://archives.postgresql.org/message-id/20071016132131.ga4...@depesz.com
I agree with Tom here. I tracked a lot of idle i
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
wrote:
> I find it hard to imagine a use case for the existing default
> behavior.
I thought a bit about it and I think it can be useful when your
priority is the availability of the service and you don't consider a
data loss that important: even if
On Wed, Mar 25, 2009 at 9:44 AM, Fujii Masao wrote:
> Yeah, I agree... but there may be scripts for warm-standby based on
> the existing default behavior. So, I didn't make a new trigger the default.
I don't use pg_standby personnaly but I admit I'm quite surprised by
the current behaviour. I'm p
On Wed, Mar 25, 2009 at 7:29 AM, Fujii Masao wrote:
> Attached patch fixes the above problem by adding a new trigger option
> to pg_standby; the presence of this new trigger file causes recovery to
> end after replaying all the available WAL files.
Shouldn't it be the default? It seems like the m
On Sun, Mar 22, 2009 at 10:46 PM, Tom Lane wrote:
> There might (or might not) be some use-case
> for being able to declare that module A depends on module B,
Typically, earthdistance requires cube so the module dependency is
already something that might be useful. But as you said, it doesn't
req
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus wrote:
> SET ROLE special WITH SETTINGS
>
> ... or similar; I'd need to find an existing keyword which works.
Perhaps something like "SET ROLE special NEW SESSION;".
It solves a problem mentioned by Tom as it's very clear that it's a
new session so wh
On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane wrote:
> Can you put together even a weakly reproducible test case? Something
> that only fails every tenth or hundredth time would still help.
It seems that Olivier can reproduce the problem at will on Unixware. I
don't know if it's easy to find useful i
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote:
> The question is how you want to implement this in a data type independent
> fashion. You can't assume that increasing the typmod is a noop for all data
> types.
Sure. See my previous answer on -hackers (I don't think this
discussion belo
On Wed, Mar 4, 2009 at 11:06 AM, Heikki Linnakangas
wrote:
> While this isn't a bug, it's a reasonable feature request. I've added this
> to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER
>
> Patches are welcome.
I remember someone proposed a patch for that a long time ago:
http://arch
On Mon, Feb 23, 2009 at 8:53 PM, Tom Lane wrote:
> There are a number of options at this point, including fixing the
> problem only in HEAD, fixing back to 8.1 but no further, or making
> wrapper functions in the back branches to preserve the existing
> argument lists of heap_create_with_catalog a
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle wrote:
> I didn't find such a notion in the standard. A view is automatically
> updatable if it meets the criteria of updatability). If you don't want your
> view writable, you have to GRANT the necessary ACLs.
Perhaps I'm a bit old school on this one
On Sat, Jan 24, 2009 at 1:17 AM, Tom Lane wrote:
> I think that we probably want the rules to show up automatically during
> an upgrade from an older version
I'm really not convinced by that. Is it required by the standard? It's
really far from being compliant with the principle of least surprise
On Mon, Jan 12, 2009 at 5:48 PM, Dave Page wrote:
> I would. PostgreSQL is not a commercial application which has to be
> released on schedule to satisfy shareholders - it's an Open Source
> project that aims to provide it's users with useful features.
It has nothing to do with commercial/non com
On Mon, Jan 12, 2009 at 5:18 PM, Tom Lane wrote:
> Basically I think we are up against the same type of project management
> decision we've had several times before: are we willing to slip the
> 8.4 release schedule for however long it will take for hot standby
> and the other replication-related
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure wrote:
> I disagree at least with hot standby. I've been using/testing (as
> have others) it under a variety of workloads for several months now
> with no issues outside of corrected issues in the very early patches.
> Also, a relatively few amount
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane wrote:
> However, we are getting off onto a tangent. I wasn't trying to start
> a discussion about general project policies, but about the specific
> status of this particular group of patches.
I concur with Gregory on this one.
IM(Very)HO, it's really
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane wrote:
> However, the
> de facto policy is that we try to keep them passing in locales that
> are used by any of the regular developers. I think it would be useful
> to have buildfarm members testing in a few common locales.
If you define common locales,
On Sat, Dec 6, 2008 at 12:53 PM, hubert depesz lubaczewski
<[EMAIL PROTECTED]> wrote:
> First run - without visibility maps, timing of vacuums:
> Time: 267844.822 ms
> Time: 138854.592 ms
> Time: 305467.950 ms
> Time: 487133.179 ms
>
> Second run - on head:
>
> Time: 252218.609 ms
> Time: 234388.76
On Fri, Dec 5, 2008 at 8:11 PM, Robert Haas <[EMAIL PROTECTED]> wrote:
> Correct. As compared with 8.2.9, ANALYZE was substantially faster,
> but query planning was significantly slower.
>
> Thanks also to Greg for reposting my emails. I didn't even realize I
> hadn't sent them to the list.
Any
Robert,
On Fri, Dec 5, 2008 at 7:24 PM, Greg Smith <[EMAIL PROTECTED]> wrote:
> comparing to 8.2.9 results:
> - q1 was 32% slower with dst = 10, 33% slower with dst = 1000
> - other queries were 19% slower with dst = 10, 25% slower with dst = 1000
You mean that HEAD is slower than 8.2.9 or I don'
On Wed, Dec 3, 2008 at 10:49 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> The autovacuum workers change that and make it a default behaviour (as
>> we can have 3*maintenance_work_mem by default).
>
> It's still one per process, it's just that autovac uses more than one
> process.
I agree. Wha
Greg,
On Mon, Dec 1, 2008 at 3:17 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> ./pgtune -i ~/data/postgresql.conf
First, thanks for your work: it will really help a lot of people to
have a decent default configuration.
A couple of comments from reading the code (I didn't run it yet):
- it would b
On Wed, Dec 3, 2008 at 2:00 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It seems like mostly a confusion-generator to me. Is there any actual
> evidence that autovac should use a different maintenance_work_mem than
> other processes?
IMHO, the point is that we were used to consider the
maintenance_
On Fri, Nov 28, 2008 at 6:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Hm. People have complained of that fact from time to time in normal
> usage as well. Should we simply change SIGINT handling to allow it to
> cancel an idle transaction?
If this means that we would be able to able to easily r
On Wed, Nov 26, 2008 at 9:45 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, the *first* sentence there says it "resets the session to its
> initial state", so it seems to me the intent is clear. But maybe we
> should alter the second sentence to read, say, "This _currently_ has the
> same effect
On Wed, Nov 26, 2008 at 8:13 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> DISCARD ALL was specifically added in 8.3 for the purpose of connection
> poolers to be a "big hammer" that exactly emulates a new session. I'm somewhat
> skeptical that there are any applications using it directly at all,
On Thu, Sep 11, 2008 at 9:01 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Could someone please point me at where this optimization was committed? I'm
> having trouble locating it.
I think it's this one:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00296.php
--
Guillaume
--
Sen
On Fri, Aug 15, 2008 at 11:42 AM, alexander lunyov <[EMAIL PROTECTED]> wrote:
> i didn't find anything like postgresql.conf on old server. Right now i'm
> tried to start 6.5.3 on windows (downloaded binary from ftp archive on
> postgresql.org, installed last cygwin) with the data dir from old serve
On Fri, Aug 15, 2008 at 9:54 AM, alexander lunyov <[EMAIL PROTECTED]> wrote:
> Thanks for the tip.
> I want to try new pg_dump to connect to old server, but i can't - old
> postgres doesn't listening to network socket. Why postgres 6.5.3 not
> binding to network socket? It started with this line:
On Thu, Jun 26, 2008 at 3:04 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Okay, it seems fairly close to RHEL-4. Doesn't
> look like there are any RHEL4 or CentOS4 machines in the buildfarm,
> which is why we didn't find out about it earlier.
FYI, I set up a CentOS 4 vserver on one of our buildfarm
Mark,
On Tue, Jul 1, 2008 at 1:15 PM, Mark Cave-Ayland
<[EMAIL PROTECTED]> wrote:
> Thanks very much for supplying the WIP patch. In the interest of testing and
> feedback, I've just downloaded PostgreSQL CVS head and applied your patch,
> compiled up a slightly modified version of PostGIS (withou
On Thu, May 29, 2008 at 4:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> IIRC I made a few cosmetic cleanups along with the actual bug fix.
> I'll take a look this afternoon and put it in.
Thanks.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, May 29, 2008 at 4:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, nothing's been done about that AFAIK. What's the consensus,
> do we want to change that behavior in 8.3.2?
IIRC, noone voted against backpatching it after Alvaro and you agreed
with doing so.
Archives link: http://archive
On Wed, May 28, 2008 at 4:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> If you've got any bug fixes you've been working on, now is a good time
> to get them finished up and sent in...
Has the s/\x09//g patch for psql from Bruce and you been
backported to 8.3? I didn't see it on pgsql-commiters.
On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> No, we don't change behaviors in back branches unless we get lots of
> complaints, and we haven't in this case.
I suspect it's annoying for a lot of people, just not annoying enough
to make them complain about it.
I unders
On Wed, Mar 12, 2008 at 4:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > The other alternative is to convert tabs to spaces on output. Can't
> > remember why we didn't do that.
>
> Yeah. The idea I had was to invent a parameter specifying the
On Mon, Apr 2, 2007 at 2:44 AM, Phil Currier <[EMAIL PROTECTED]> wrote:
> On 4/1/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
>
> > Phil, did you make any progress with your patch? Your results seemed
> > very encouraging and your implementation interesting.
>
On Sun, Apr 20, 2008 at 6:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> It's probably due to the RANDOMIZE_ALLOCATED_MEMORY overhead added here:
>
> > pgsql/src/backend/utils/mmgr/aset.c 1.77
>
> Right now that's on by default in assert-enabled builds. I'm not
> sure if we want to leave it like
Hi all,
While working on our network problems to send the full build result to
the buildfarm server, I just saw that a full buildfarm run with
-DCLOBBER_CACHE_ALWAYS option takes nearly 2 hours more than before
(from ~ 5h40 to 7h30).
This phenomenon has started with this run:
http://www.pgbuildfa
On Fri, Apr 11, 2008 at 9:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> To be blunt, that seems like a really bad idea, and I have not the
> slightest hesitation about breaking your ability to do it. How
> do you know that the recheck-need corresponds to what you are testing
> on the applicatio
On Fri, Apr 11, 2008 at 7:41 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Offhand I suspect
> only the PostGIS project would be affected.
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I e
On Mon, Mar 31, 2008 at 4:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > Did you commit a patch already, do you want me to rerun the build?
>
> Yes; no --- looks like it'll run by itself in an hour anyay.
I set up a new box with -DCLOBBER_CACHE_ALWAYS called pigeon so
On Sun, Mar 30, 2008 at 6:29 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Applied to HEAD.
>
> At this point it would probably be a good idea if a couple of buildfarm
> machines were to start testing builds with --disable-integer-datetimes
> ... any volu
FYI, we (Stefan and I) started a wiki page to organize this effort:
http://wiki.postgresql.org/wiki/Performances_QA_testing . Ideas and
participation are very welcome.
I also described the platform we have here and the usage of each
server:
http://wiki.postgresql.org/wiki/QA_Platform_hosted_at_Op
On Wed, Apr 2, 2008 at 1:53 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> As far as the other more powerful machines you mentioned go, would need to
> know a bit more about the disks and disk controller in there to comment
> about whether those are worth the trouble to integrate. The big missing
>
On Wed, Apr 2, 2008 at 2:53 AM, Dave Cramer <[EMAIL PROTECTED]> wrote:
> I for one would be very interested in the JDBCBench code.
OK, I didn't make anything fancy, I just fixed the problem I
encountered when profiling Sequoia (I mostly used it as an injector).
I'll post the code tomorrow if I c
On Tue, Apr 1, 2008 at 3:29 PM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> I'm almost done scripting up everything to load the TIGER/Line
> Shapefiles from the US Census into PostgreSQL/PostGIS. Once it's done
> and working I would be happy to provide it to whomever asks, and it
> might be an
On Wed, Apr 2, 2008 at 1:53 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> The pgbench-tools utilities I was working on at one point anticipated this
> sort of test starting one day. You can't really get useful results out of
> pgbench without running it enough times that you get average or median
On Wed, Apr 2, 2008 at 2:05 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> I'm not sure if all of those changes are net positive for PostgreSQL
> though, they weren't last time I played with this.
I fixed most of the bugs of JDBCBench I found when I benchmarked
Sequoia a long time ago. Totally forg
On Tue, Apr 1, 2008 at 8:06 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, the lack of any formal testing of the extended-Query protocol
> is a real problem. I'm not sure of a good fix, but it bears some
> thinking about. Not only do we not have an automated way to notice
> if we broke funct
-hackers,
As I announced it a couple of months ago, apart from the boxes donated
to PostgreSQLFr (affected to the web team IIRC), Continuent also
donated 7 servers and a Gb/s switch to us for QA testing. It took some
time to set them up but they're now up and running and available.
These servers a
On Tue, Apr 1, 2008 at 7:35 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's not like we have never before changed internal APIs in a
> minor update. (There have been security-related cases where we gave
> *zero* notice of such changes.) Nor am I willing to surrender the
> option to do so
On Wed, Mar 12, 2008 at 7:52 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> the read only standby would be what i'd most like to see.
+1 for this one.
Working on setting up a benchfarm could be a good idea too.
--
Guillaume
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Mon, Mar 10, 2008 at 11:36 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> The time to analyze is also quite constant, just before you run out of
> memory. :) The MaxAllocSize is the limiting factor in all this. In my
> example, statistics targets larger than about 80 created pg_stati
On Sun, Feb 24, 2008 at 10:39 PM, Guillaume Smet
<[EMAIL PROTECTED]> wrote:
> On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> > I'm at PostgreSQL 8.3 for my production database and everything is
> > working great. I had no problems
Hi Mark,
On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> I'm at PostgreSQL 8.3 for my production database and everything is
> working great. I had no problems converting free text search from 8.2 to
> 8.3, and I really like the improvements.
>
> I tried using insert
1 - 100 of 220 matches
Mail list logo
