Hi Heikki,
http://git.postgresql.org/gitweb?p=users/heikki/postgres.git;a=commit;h=ebaa89ce8906e0ec45f105d083a0360b1f8bc7ca
You dropped all the ACKs from walreceiver to walsender. I have no objection
to that, but I think that walsender should handle at least 'X' (which means
that the standby is
On Jan 7, 2010, at 4:07 PM, Josh Berkus wrote:
Building a simple solution which doesn't initially cover all bases but
can be steadily improved is a far superior strategy to trying to spec
The Perfect Solution before even starting work. And if we want to keep
recruiting new contributors,
On Fri, Jan 8, 2010 at 05:22, Ron Mayer rm...@cheapcomplexdevices.com wrote:
David E. Wheeler wrote:
On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine. For Windows
binaries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Jan 07, 2010 at 04:44:49PM -0700, Alex Hunsaker wrote:
On Thu, Jan 7, 2010 at 15:16, Tim Bunce tim.bu...@pobox.com wrote:
Is there any reason not to add .gitignore files into the repository?
They'll make no difference to those who don't
Hi,
I am kinda puzzled as to why the query_tree_walker() function does not
examine the intoClause field? I do see another function
raw_expression_tree_walker() which does walk that entry. So what is
the exact reason here? Or we just missed it for the earlier function?
Regards,
Nikhils
--
Fujii Masao wrote:
Hi Heikki,
http://git.postgresql.org/gitweb?p=users/heikki/postgres.git;a=commit;h=ebaa89ce8906e0ec45f105d083a0360b1f8bc7ca
You dropped all the ACKs from walreceiver to walsender. I have no objection
to that, but I think that walsender should handle at least 'X' (which
David Fetter da...@fetter.org writes:
If we *must* have SR and it's not in by the 15th, let's do another
Commitfest rather than jack the people who played by the rules.
If we do add another Commitfest what we do is exactly jacking people who
played by the rules. Because all those patches that
On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Jan 7, 2010 at 15:16, Tim Bunce tim.bu...@pobox.com wrote:
Is there any reason not to add .gitignore files into the repository?
They'll make no difference to those who don't use git, but be very
helpful to, and
On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
Hi Heikki,
http://git.postgresql.org/gitweb?p=users/heikki/postgres.git;a=commit;h=ebaa89ce8906e0ec45f105d083a0360b1f8bc7ca
You dropped all the ACKs from walreceiver to walsender.
On Fri, Jan 8, 2010 at 10:02, Dimitri Fontaine dfonta...@hi-media.com wrote:
David Fetter da...@fetter.org writes:
If we *must* have SR and it's not in by the 15th, let's do another
Commitfest rather than jack the people who played by the rules.
If we do add another Commitfest what we do is
Self answer: Because the post-analysis phase does not have anything
interesting to peek in it. The only interesting thing could be the
RangeVar, but it is not going to be in an RTE form after the
transformstmt, so not much point.
Sorry for the noise.
Regards,
Nikhils
On Fri, Jan 8, 2010 at 2:22
Magnus Hagander mag...@hagander.net writes:
Why we can do it this way is because we're not starving on
reviewers. We're starving on commiters time. And seeing this:
Well, we're actually somewhat starving on senior reviewers as well.
That can take on things like the index patches, Writable CTE
Hello
I am testing vacuum changes, and I found some strange behave:
autovacuum off
[pa...@nemesis src]$ /usr/local/pgsql/bin/pgbench -i -F 10 -s 10 test
NOTICE: table pgbench_branches does not exist, skipping
NOTICE: table pgbench_tellers does not exist, skipping
NOTICE: table
On Thu, Jan 7, 2010 at 10:07 PM, Josh Berkus j...@agliodbs.com wrote:
Building them is no problem - authors can easily use EC2 for which we
have an AMI pre-configured for next to no cost, can build on their own
platform, on a community provided system, or get a friend to do it.
So any module
Fujii Masao wrote:
On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't think we need to treat 'X' differently from EOF. You get an
error anyway if the write() fails. That's actually a bit annoying, you
get a could not send data to client error
What we can do in the back branches is make the code treat any
negative value as meaning two-arg form. To throw an error we'd
need to refactor the pg_proc representation ...
I was going to fix that myself, but I think it has just been done.
How can I keep up with who's doing what?
--
The trigger file logic feels a bit backwards. As the patch stands, when
the standby starts up, it retries connecting to the master server
indefinitely, until a connection is successfully established. Then it
streams until the connection breaks. If the connection is dropped
abruptly, because of a
Hi,
Greg Stark wrote:
I think we're still talking past the issue. Predicate locks are not
row level, nor page level, nor table level. They're locks on
predicates. Ie, you have to lock against values which aren't actually
currently in the table at all. You need to be able to detect a
conflict
On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The trigger file logic feels a bit backwards. As the patch stands, when
the standby starts up, it retries connecting to the master server
indefinitely, until a connection is successfully established.
Hi,
Kevin Grittner wrote:
As I understand it, Greg's line of thinking is that we should use a
technique which has never proven practical on a large scale:
matching database changes against a list of predicate lock
expressions.
I find that approach to predicate locking pretty interesting.
Hi,
Josh Berkus wrote:
Dave wrote:
and frankly,
isn't the way this project generally works.
Isn't it? We didn't even support Windows for quite a long time. We still
have lots more active Unix developers and knowledge that Windows ones.
And isn't there some scratch your own itch philosophy
Magnus Hagander wrote:
On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So the trigger file is really a holdoff file, like a safety catch on a
gun. At the very least it should be renamed, but I don't think that's a
very useful behavior anyway.
It
On Fri, Jan 8, 2010 at 10:40 AM, Markus Wanner mar...@bluegap.ch wrote:
Hi,
Josh Berkus wrote:
Dave wrote:
and frankly,
isn't the way this project generally works.
Isn't it? We didn't even support Windows for quite a long time.
No, it's quite different for the PostgreSQL not to support
Pavel Stehule pavel.steh...@gmail.com wrote:
I am testing vacuum changes, and I found some strange behave:
Did you need SET (fillfactor=100) before vACUUM FULL?
=# select * from pgstattuple('pgbench_accounts');
-[ RECORD 1 ]--+---
table_len | 1365336064
tuple_count
2010/1/8 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Pavel Stehule pavel.steh...@gmail.com wrote:
I am testing vacuum changes, and I found some strange behave:
Did you need SET (fillfactor=100) before vACUUM FULL?
no, I tested it and with FILLFACTOR 100 VACUUM FULL is successful.
Pavel Stehule pavel.steh...@gmail.com wrote:
Personally I thing, so this behave is bad. Or there is wrong default
fillfactor 0.
No, you used fillfactor=10 here:
[pa...@nemesis src]$ /usr/local/pgsql/bin/pgbench -i -F 10 -s 10 test
~
2010/1/8 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Pavel Stehule pavel.steh...@gmail.com wrote:
Personally I thing, so this behave is bad. Or there is wrong default
fillfactor 0.
No, you used fillfactor=10 here:
[pa...@nemesis src]$ /usr/local/pgsql/bin/pgbench -i -F 10 -s 10 test
On Fri, Jan 8, 2010 at 04:46, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Jan 7, 2010 at 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in
On Thursday, January 7, 2010, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark gsst...@mit.edu wrote:
On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner mar...@bluegap.ch wrote:
Row level locks are very fine grained, but those are spilled to disk in
its current
On Fri, 2010-01-08 at 01:26 +, Simon Riggs wrote:
I'll test and commit tomorrow, since it's a fairly standalone problem
Fix attached, thanks for testing.
Works for me and I don't expect it to fail on Solaris, since the root
cause of the failure has been addressed and a correctly designed
On Fri, Jan 8, 2010 at 6:39 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
There's no guarantee walreceiver will read the 'X' before trying to
write() to the socket, so we can't rely on that to determine whether to
suppress the could not send data to client message.
On Mon, Jan 04, 2010 at 06:38:03PM -0500, Andrew Dunstan wrote:
Andrew Dunstan wrote:
Yes. I believe the test is highlighting an existing problem: that plperl
function in non-PG_UTF8 databases can't use regular expressions that
require unicode character meta-data.
Either the
Dave Page wrote:
The only reason we ever offer different functionality on different
platforms is when there are external reasons forcing us to - for
example, lack of reparse points in NTFS on Windows NT 4.0 prevented us
offering table space support, and for some time we had no Win32 port
of
On Fri, Jan 8, 2010 at 7:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Thinking more clearly, my comment above about the trigger file logic
being backwards was bollocks; if the master is shut down, standby waits
for the trigger file to appear, not to go away. And creating
Fujii Masao wrote:
You dropped CheckForStandbyTrigger() called at the end of recovery.
I think that this would be problem when an invalid record is found before
we reaches a streaming recovery state. The standby would be out-of-control
of the clusterware, and be brought up. Which might cause a
Leonardo F wrote:
What we can do in the back branches is make the code treat any
negative value as meaning two-arg form. To throw an error we'd
need to refactor the pg_proc representation ...
I was going to fix that myself, but I think it has just been done.
How can I keep up with
Fujii Masao wrote:
On Fri, Jan 8, 2010 at 6:39 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
There's no guarantee walreceiver will read the 'X' before trying to
write() to the socket, so we can't rely on that to determine whether to
suppress the could not send data to
Nikhil Sontakke nikhil.sonta...@enterprisedb.com writes:
I am kinda puzzled as to why the query_tree_walker() function does not
examine the intoClause field?
Is there any point to it?
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Fri, Jan 8, 2010 at 10:31 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
You dropped CheckForStandbyTrigger() called at the end of recovery.
I think that this would be problem when an invalid record is found before
we reaches a streaming recovery state.
(continued from -general)
W dniu 7 stycznia 2010 22:31 użytkownik Greg Smith
g...@2ndquadrant.comnapisał:
Filip Rembiałkowski wrote:
After dropping a column from table, there is still entry in pg_attribute
fi...@la_dev=# select * from pg_attribute where attrelid = (select oid
from
On Fri, Jan 8, 2010 at 10:35 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Oh, I think we need to fix that, I'm thinking of doing a select() in the
loop to check that the socket hasn't been closed yet. I meant we don't
need to try reading the 'X' to tell apart e.g a network
Magnus Hagander wrote:
On Fri, Jan 8, 2010 at 05:22, Ron Mayer rm...@cheapcomplexdevices.com wrote:
David E. Wheeler wrote:
On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
No, I'm suggesting the mechanism needs to support source and binary
distribution. For most *nix users, source will be fine.
On Fri, Jan 8, 2010 at 15:14, Ron Mayer rm...@cheapcomplexdevices.com wrote:
Magnus Hagander wrote:
On Fri, Jan 8, 2010 at 05:22, Ron Mayer rm...@cheapcomplexdevices.com
wrote:
David E. Wheeler wrote:
On Jan 7, 2010, at 1:31 PM, Dave Page wrote:
No, I'm suggesting the mechanism needs to
Magnus Hagander mag...@hagander.net writes:
Do we need to make the value configurable? I'd certainly find it
interesting to set backends to say 5 or something like that, that
makes them less likely to be killed than any old oops opened too big
file in an editor-process, but still possible to
Michael Meskes wrote:
Log Message:
---
Also update ChangerLog file.
Hmm not sure I find that commit message really helpful - but is it
actually of any use to maintain a Changelog file specifically for ECPG?
Stefan
--
Sent via pgsql-hackers mailing list
Jeff Davis pg...@j-davis.com wrote:
On Thu, 2010-01-07 at 21:02 -0500, Robert Haas wrote:
Hmm. Why would we use a GUC for this instead of an additional
option to BEGIN TRANSACTION?
I'm with you. I feel pretty strongly that we should not have
behavior-changing GUCs.
OK. I actually
Alex Hunsaker wrote:
On Thu, Jan 7, 2010 at 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
We can either drop this in core (with a lot of #ifdef LINUX added)
Any thoughts on doing something like (in fork_process.c)
#ifdef LINUX
void oom_adjust()
{
On Fri, Jan 8, 2010 at 7:34 AM, Greg Stark gsst...@mit.edu wrote:
On Thursday, January 7, 2010, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark gsst...@mit.edu wrote:
On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner mar...@bluegap.ch wrote:
Row level locks are
On Fri, Jan 8, 2010 at 9:46 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Opinions?
I think anything you decide about how to invoke the different
isolation levels will be easy to change later to meet whatever the
consensus of the community is at that time. I wouldn't spend any time
or
Magnus Hagander escribió:
On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker bada...@gmail.com wrote:
On Thu, Jan 7, 2010 at 15:16, Tim Bunce tim.bu...@pobox.com wrote:
Is there any reason not to add .gitignore files into the repository?
They'll make no difference to those who don't use git, but
Markus Wanner mar...@bluegap.ch wrote:
Greg Stark wrote:
That's about predicate locks. I've been talking about SIREAD,
which is a different thing (and which I don't consider to be a
lock). The SIREAD thingie certainly doesn't help implement
predicate locks. And predicate locking isn't
Markus Wanner mar...@bluegap.ch wrote:
Kevin Grittner wrote:
As I understand it, Greg's line of thinking is that we should use
a technique which has never proven practical on a large scale:
matching database changes against a list of predicate lock
expressions.
I find that approach to
Greg Stark gsst...@mit.edu wrote:
well the one place you *cannot* attach them is on the tuples.
The predicate locking schemes I've been reading about do attach
locks to tuples, as *part* of a complete strategy.
you need to new able to lock hypothetical new tuples which don't
exist yet.
Hey Andrew
On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan and...@dunslane.net wrote:
Windows came late to the buildfarm. According to the CVS log, the buildfarm
client was first checked in in Sept 2004, got initial Mingw support in Jan
2005 and MSVC support in March 2007, when we finally got
On Fri, Jan 8, 2010 at 07:53, Bruce Momjian br...@momjian.us wrote:
Alex Hunsaker wrote:
On Thu, Jan 7, 2010 at 20:26, Tom Lane t...@sss.pgh.pa.us wrote:
Alex Hunsaker bada...@gmail.com writes:
The usual solution for this kind of thing is:
#ifdef LINUX
#define OOM_ADJUST
On Fri, Jan 8, 2010 at 10:12 AM, Dave Page dp...@pgadmin.org wrote:
I have long spoken against making Windows a second class citizen. But I
don't think David is going to do that (and I'll hound him if he does). But
that doesn't mean it has to be fully supported from day one.
I'm not saying it
I had this flagged as needing a response, but it fell through the
cracks yesterday. Apologies for the delayed response.
Markus Wanner mar...@bluegap.ch wrote:
I'm not clear if Kevin plans to go down to tuple level locking
with granularity of the SIREAD thing.
Eventually, where possible,
On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
Hey Andrew
On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan and...@dunslane.net wrote:
Windows came late to the buildfarm. According to the CVS log, the buildfarm
client was first checked in in Sept 2004, got initial Mingw support in Jan
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
-DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at that.
It sets oom_adj for:
autovacuum workers
archivers (pgarch.c)
regular backends
Alvaro Herrera alvhe...@commandprompt.com writes:
Leonardo F wrote:
How can I keep up with who's doing what?
Read this list and pgsql-committers.
Or subscribe to the RSS feed from:
http://git.postgresql.org/gitweb?p=postgresql.git;a=summary
--
dim
--
Sent via pgsql-hackers mailing list
Hi,
Greg Stark wrote:
well the one place you *cannot* attach them is on the tuples. because
you need to new able to lock hypothetical new tuples which don't exist
yet.
Well, maybe attaching here is meant in a more general or theoretical
sense. I think we all agree that adding them to the
Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 7, 2010 at 19:08, Kevin Grittner
Robert's advice being the last (and only) offered on the topic,
I'm taking the silence as agreement and have dropped the request
for a serializable repository and added one for
/users/kgrittn/postgres
On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
Hey Andrew
On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan and...@dunslane.net wrote:
Windows came late to the buildfarm. According to the CVS log, the
On Fri, 2010-01-08 at 16:33 +, Dave Page wrote:
On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
Hey Andrew
On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan and...@dunslane.net
wrote:
Windows
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
    -DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at that.
Anybody have an objection to this
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander mag...@hagander.net wrote:
You can always create your own branch with just the .gitignore files
and merge that into whatever you're working on :)
The only thing annoying about that is if you generate diffs ala git
diff origin/master.. you get your
On Fri, Jan 8, 2010 at 4:34 PM, Joshua D. Drake j...@commandprompt.com wrote:
On Fri, 2010-01-08 at 16:33 +, Dave Page wrote:
On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
Hey Andrew
On Fri, Jan 8,
Robert Haas wrote:
On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan and...@dunslane.net wrote:
This strikes me as quite premature. Heiki just said he expects to have SR
committed next week.
Getting it committed is not what I'm worried about. What I'm
concerned about is Tom's statement that
Tom Lane wrote:
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
?? ?? ?? ??-DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at that.
Anybody have
Hi,
Kevin Grittner wrote:
SIREAD locks need to be acquired according to the exact same rules
as normal read locks in predicate locking schemes.
Understood. I didn't take that into account at first. Thanks for
pointing it out. (Whatever normal read locks are...)
We're just
using a lock level
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
Right - but the buildfarm isn't a feature being offered to end users.
And this network isn't a feature of the core code either, nor, do I
believe, is it being designed in a way that would require an overhaul
down the road to support Windows. To be
Bruce Momjian br...@momjian.us wrote:
here is the ideal schedule:
Jan 15 start commitfest
Feb 15 stop commitfest
Apr 1 start beta
Jun 1 release release candidate (RC)
Jun 20 release 8.5
Of course we rarely have an ideal schedule
So for a project which
* Magnus Hagander (mag...@hagander.net) wrote:
Do we need to make the value configurable? I'd certainly find it
interesting to set backends to say 5 or something like that, that
makes them less likely to be killed than any old oops opened too big
file in an editor-process, but still possible
On Thu, Jan 7, 2010 at 9:28 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
All valid points. I could try to make counter-arguments, but in my
view the only thing that really matters is how any such attempt
performs in a realistic workload. If, when we get to the
optimization phase,
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Bruce Momjian br...@momjian.us wrote:
Jan 15 start commitfest
Jun 20 release 8.5
over six months
OK, so over *five* months. Still
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
Or, at best, just means that the packagers won't enable it, which
On Fri, Jan 8, 2010 at 10:07, Stephen Frost sfr...@snowman.net wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
-DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at
Greg Stark gsst...@mit.edu wrote:
My comment was in relation to the idea of representing the costs
in the planner. I was a) saying you had to see how the
implementation went before you try to come up with how to
represent the costs and then b) speculating (hypocritically:) that
you might
On Jan 8, 2010, at 1:35 AM, Dave Page wrote:
I am saying that if the design won't ever work without requiring
painful dependency installation that users will likely not want to
bother with, then it is fundamentally broken. Better to write one
system that can _eventually_ work everywhere, than
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
It also seems to call into question the wisdom of annual releases.
If we had a two-year cycle which had three times as much in it,
would that be an improvement, or not?
At the moment, my vote would be how 'bout we discuss this post-8.5?.
On Jan 8, 2010, at 1:02 AM, Dimitri Fontaine wrote:
Now, I'll second Greg Smith and Tom here, in that I think we need to run
the last commitfest as usual, knowing that the outcome of the commitfest
for any given patch is not it made it but we reviewed it. It's still
right for the project to
On Friday 08 January 2010 17:38:15 Alex Hunsaker wrote:
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander mag...@hagander.net wrote:
You can always create your own branch with just the .gitignore files
and merge that into whatever you're working on :)
The only thing annoying about that is if
On Fri, Jan 8, 2010 at 5:13 PM, David E. Wheeler da...@kineticode.com wrote:
This whole bit about Windows is a red herring. Perhaps I should not have
phrased it the way I did WRT Windows. So I'm going to change it to:
The PGAN client will make no other assumptions about how to build and
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
Or, at best, just means that
Alex,
* Alex Hunsaker (bada...@gmail.com) wrote:
As long as the VM/container you are running under wont kill postmaster
for trying to access proc-- the patch I posted should work fine. It
just ignores any error (I assumed you might be running in a chroot
without proc or some such).
As I
On Fri, Jan 8, 2010 at 5:13 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
From what I understand your first cut will just take full-table
locks anyways so it won't matter what type of plan is used at
all.
Right. And it would be totally premature to try to test any
optimizations at
On Fri, Jan 8, 2010 at 11:44 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan and...@dunslane.net wrote:
This strikes me as quite premature. Heiki just said he expects to have SR
committed next week.
Getting it committed is not
On Thu, Jan 7, 2010 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2010-01-07 at 22:16 +, Tim Bunce wrote:
Is there any reason not to add .gitignore files into the repository?
I already find the .cvsignore files to be useless and an
Tom Lane wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
What I suggest is that we do something like
#ifdef LINUX_OOM_ADJ
...
fprintf(oom, %d\n, LINUX_OOM_ADJ);
...
#endif
Then,
On Fri, Jan 8, 2010 at 5:13 PM, David E. Wheeler da...@kineticode.com wrote:
Please let the Windows thread die now. PGAN doesn't ignore Windows; it
ignores installer development.
yeah, I think there are two quite separable projects here. It's quite
possible that once the binary installer
On Fri, Jan 8, 2010 at 12:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to
On Thu, Jan 7, 2010 at 21:07, David E. Wheeler da...@kineticode.com wrote:
Hackers,
I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
I've tried to closely follow the [CPAN philosophy][] to come up with a plan
that requires a minimum-work implementation that
On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 7, 2010 at 21:07, David E. Wheeler da...@kineticode.com wrote:
Hackers,
I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL extensions.
I've tried to closely follow the [CPAN philosophy][] to
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
BTW, maybe you're confused
On Fri, Jan 8, 2010 at 18:44, Dave Page dp...@pgadmin.org wrote:
On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 7, 2010 at 21:07, David E. Wheeler da...@kineticode.com wrote:
Hackers,
I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
2010/1/8 Magnus Hagander mag...@hagander.net:
On Fri, Jan 8, 2010 at 18:44, Dave Page dp...@pgadmin.org wrote:
The current set of active mirrors can always be found at
http://www.postgresql.org/mirrors.xml, so you can build URLs on the
mirror network using the protocol, host, port and path
Greg Stark gsst...@mit.edu wrote:
Well we disagree with whether we have any reasonable plan for
adding the more fine-grained locks.
We probably agree on that, too. Perhaps it's that I think we can
develop one within a few months and you don't?
AFAICT we have either a) add something clean
On Jan 8, 2010, at 9:24 AM, Dave Page wrote:
If that is the goal of your project then I withdraw my previous
comments, which were written on the belief that you were proposing a
generic distribution/build/installation system for PostgreSQL users.
It is a generic distribution and installation
On Jan 8, 2010, at 9:38 AM, Magnus Hagander wrote:
Is there a particular reason not to use the existing mirroring network
to distribute the files? If not, then I suggest using them should be
part of the design.
No, as long as PAUS can drop uploaded distributions onto the master FTP server,
1 - 100 of 177 matches
Mail list logo
