On Fri, Jan 29, 2010 at 9:03 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Dec 23, 2009 at 7:42 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Oct 25, 2009 at 10:08 AM, Peter Eisentraut pete...@gmx.net 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
On Fri, Oct 16, 2009 at 9:26 PM, Tom Lane t...@sss.pgh.pa.us 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
Hi Magnus,
On Mon, Sep 14, 2009 at 9:41 PM, Magnus Hagander mag...@hagander.net 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:
On Thu, Aug 27, 2009 at 12:03 AM, Dimitri
Fontainedfonta...@hi-media.com 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
Pierre,
On Thu, Aug 6, 2009 at 11:39 AM, PFCli...@peufeu.com 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
On Fri, Jul 3, 2009 at 9:14 PM, Peter Eisentrautpete...@gmx.net 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 Peter
On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstanand...@dunslane.net 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
2009/6/17 Petr Jelinek pjmo...@pjmodos.net:
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
On Mon, Jun 1, 2009 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, May 28, 2009 at 5:02 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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,
On Thu, May 28, 2009 at 5:36 PM, Simon Riggs si...@2ndquadrant.com 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
On Thu, May 28, 2009 at 6:06 PM, Simon Riggs si...@2ndquadrant.com 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
least surprise: I'm
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
At a normal startup, the checkpoint record would be there as usual. And an
archive recovery starts at the location
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
On Sun, May 10, 2009 at 2:32 PM, Guillaume Smet
guillaume.s...@gmail.com 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
On Sun, May 10, 2009 at 3:29 PM, Andrew Dunstan and...@dunslane.net 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?
On Sun, May 10, 2009 at 4:07 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao masao.fu...@gmail.com 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
On Fri, Apr 10, 2009 at 5:47 AM, Fujii Masao masao.fu...@gmail.com 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
On Thu, Apr 9, 2009 at 5:00 AM, Fujii Masao masao.fu...@gmail.com 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.
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
On Fri, Apr 3, 2009 at 5:42 AM, Fujii Masao masao.fu...@gmail.com 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
On Wed, Apr 1, 2009 at 11:44 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Sat, Mar 28, 2009 at 11:05 PM, Bruce Momjian br...@momjian.us 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
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
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.
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Mar 27, 2009 at 9:07 AM, Simon Riggs si...@2ndquadrant.com 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
On Fri, Mar 27, 2009 at 12:56 PM, Peter Eisentraut pete...@gmx.net 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
On Fri, Mar 27, 2009 at 3:38 AM, Fujii Masao masao.fu...@gmail.com 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
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
guillaume.s...@gmail.com wrote:
2009/3/27 Tatsuhito Kasahara kasahara.tatsuh...@oss.ntt.co.jp:
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
On Fri, Mar 27, 2009 at 4:24 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Mar 27, 2009 at 9:38 AM, Magnus Hagander mag...@hagander.net 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
On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao masao.fu...@gmail.com 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
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) -
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
Hi Simon.
On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs si...@2ndquadrant.com 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
On Thu, Mar 26, 2009 at 7:34 PM, Simon Riggs si...@2ndquadrant.com 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:
On Fri, Mar 27, 2009 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Mar 27, 2009 at 2:44 AM, Bruce Momjian br...@momjian.us 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 fixed this one the wrong way
On Wed, Mar 25, 2009 at 7:29 AM, Fujii Masao masao.fu...@gmail.com 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?
On Wed, Mar 25, 2009 at 9:44 AM, Fujii Masao masao.fu...@gmail.com 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
On Wed, Mar 25, 2009 at 2:59 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
On Wed, Mar 25, 2009 at 5:48 PM, hubert depesz lubaczewski
dep...@depesz.com 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
On Sun, Mar 22, 2009 at 10:46 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Mar 13, 2009 at 2:39 AM, Josh Berkus j...@agliodbs.com 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
On Fri, Mar 6, 2009 at 6:20 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 4, 2009 at 11:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut pete...@gmx.net 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
On Mon, Feb 23, 2009 at 8:53 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Jan 24, 2009 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle maili...@oopsware.de 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
On Mon, Jan 12, 2009 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us 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.
On Mon, Jan 12, 2009 at 4:56 PM, Merlin Moncure mmonc...@gmail.com 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
On Mon, Jan 12, 2009 at 5:18 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jan 12, 2009 at 5:48 PM, Dave Page dp...@pgadmin.org 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
On Fri, Jan 9, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us 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
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.763 ms
Time:
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't
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 chance
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. What I
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
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 be
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
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, and
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 as ...,
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
--
Sent
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 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 server,
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 (without
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 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:
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 to
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
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 number of
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.
IIRC, the problem was that you weren't
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:
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 that for
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
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 application
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 volunteers out
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 that
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:
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
piece
-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
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
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 forgot
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 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 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 can
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_statistic
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 ...
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 converting free text search from 8.2
On Feb 6, 2008 9:56 AM, Dave Page [EMAIL PROTECTED] wrote:
Whenever a commit fest is in progress, the
focus will shift from development to review, feedback and commit of
patches. Each fest will continue until all patches in the queue have
either been committed to the CVS repository, returned
1 - 100 of 219 matches
Mail list logo
