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 c
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, cr
On Fri, Jan 8, 2010 at 05:22, Ron Mayer 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 are required.
>>
>>
-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 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
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
--
http://
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' (wh
David Fetter 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 are already part
On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker wrote:
> On Thu, Jan 7, 2010 at 15:16, Tim Bunce 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 maintained by, those who do.
>
> Sin
On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
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. I have no objection
>> t
On Fri, Jan 8, 2010 at 10:02, Dimitri Fontaine wrote:
> David Fetter 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
> play
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 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 or SR.
> We'
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 "pgbench_ac
On Thu, Jan 7, 2010 at 10:07 PM, Josh Berkus 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 author, in
Fujii Masao wrote:
> On Fri, Jan 8, 2010 at 5:55 PM, Heikki Linnakangas
> 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 in the log every time a
>
> 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 ne
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
> conf
On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
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. Then it
> streams until the connecti
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
> 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 doesn't seem wise to co
On Fri, Jan 8, 2010 at 10:40 AM, Markus Wanner 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 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| 100
tuple_len
2010/1/8 Takahiro Itagaki :
>
> Pavel Stehule 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.
Personally I thing, so this behave is bad. Or the
Pavel Stehule 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
~
Pgbench sets the ta
2010/1/8 Takahiro Itagaki :
>
> Pavel Stehule 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 wrote:
> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
>> Alex Hunsaker 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 Thursday, January 7, 2010, Robert Haas wrote:
> On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark wrote:
>> On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner wrote:
>>> Row level locks are very fine grained, but those are spilled to disk in
>>> its current implementation. So those are an even worse fit
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 te
On Fri, Jan 8, 2010 at 6:39 PM, Heikki Linnakangas
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.
s/walreceiver/walsender?
> We could tr
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
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 lib
On Fri, Jan 8, 2010 at 7:41 PM, Heikki Linnakangas
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 the trigger
> file during replic
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 caus
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
Fujii Masao wrote:
> On Fri, Jan 8, 2010 at 6:39 PM, Heikki Linnakangas
> 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.
>
> s/walrece
Nikhil Sontakke 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 (pgsql-hackers@postgresql.org)
To make changes to your sub
On Fri, Jan 8, 2010 at 10:31 PM, Heikki Linnakangas
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. The standby would be out-of-
(continued from -general)
W dniu 7 stycznia 2010 22:31 użytkownik Greg Smith
napisał:
> 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 pg_class where rel
On Fri, Jan 8, 2010 at 10:35 PM, Heikki Linnakangas
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 problem from a
> standby that's s
Magnus Hagander wrote:
> On Fri, Jan 8, 2010 at 05:22, Ron Mayer 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
On Fri, Jan 8, 2010 at 15:14, Ron Mayer wrote:
> Magnus Hagander wrote:
>> On Fri, Jan 8, 2010 at 05:22, Ron Mayer
>> 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.
Magnus Hagander 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 kill if the sys
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 (pgsql-hackers@postgresql.or
Jeff Davis 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 thought this mig
Alex Hunsaker wrote:
> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
> > Alex Hunsaker 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()
> {
> ...
> }
> #else
> void
On Fri, Jan 8, 2010 at 7:34 AM, Greg Stark wrote:
> On Thursday, January 7, 2010, Robert Haas wrote:
>> On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark wrote:
>>> On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner wrote:
Row level locks are very fine grained, but those are spilled to disk in
i
On Fri, Jan 8, 2010 at 9:46 AM, Kevin Grittner
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 energy on it now. For purpo
Magnus Hagander escribió:
> On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker wrote:
> > On Thu, Jan 7, 2010 at 15:16, Tim Bunce 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
Markus Wanner 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 necessarily
> suff
Markus Wanner 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 predicate l
Greg Stark 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.
That, too. W
Hey Andrew
On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan 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 some of the too
On Fri, Jan 8, 2010 at 07:53, Bruce Momjian wrote:
> Alex Hunsaker wrote:
>> On Thu, Jan 7, 2010 at 20:26, Tom Lane wrote:
>> > Alex Hunsaker writes:
> The usual solution for this kind of thing is:
>
> #ifdef LINUX
> #define OOM_ADJUST oom_adjust()
> #else
> #define
On Fri, Jan 8, 2010 at 10:12 AM, Dave Page 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 should be
I had this flagged as needing a response, but it fell through the
cracks yesterday. Apologies for the delayed response.
Markus Wanner wrote:
> I'm not clear if Kevin plans to go down to tuple level locking
> with granularity of the SIREAD thing.
Eventually, where possible, subject to escala
On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
> Hey Andrew
>
> On Fri, Jan 8, 2010 at 12:57 PM, Andrew Dunstan 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 a
On Fri, Jan 8, 2010 at 07:27, Tom Lane 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
Also it updates t
Alvaro Herrera 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 (pgsql-hackers@post
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 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 instead.
>
On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake 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 wrote:
>> >
>> > Windows came late to the buildfarm. According to the CVS log, the buildfarm
>> > client was first check
On Fri, 2010-01-08 at 16:33 +, Dave Page wrote:
> On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake
> 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
> >> wrote:
> >> >
> >> > Windows came late to the bui
Alex Hunsaker writes:
> On Fri, Jan 8, 2010 at 07:27, Tom Lane 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 basic approach? I'm in a bit o
On Fri, Jan 8, 2010 at 02:03, Magnus Hagander 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 .gitignore in it.
On Fri, Jan 8, 2010 at 4:34 PM, Joshua D. Drake wrote:
> On Fri, 2010-01-08 at 16:33 +, Dave Page wrote:
>> On Fri, Jan 8, 2010 at 3:56 PM, Joshua D. Drake
>> wrote:
>> > On Fri, 2010-01-08 at 15:12 +, Dave Page wrote:
>> >> Hey Andrew
>> >>
>> >> On Fri, Jan 8, 2010 at 12:57 PM, Andrew
Robert Haas wrote:
> On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan 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 he believes
Tom Lane wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 8, 2010 at 07:27, Tom Lane 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 th
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 loc
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 h
Bruce Momjian 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 strives
* 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 possi
On Thu, Jan 7, 2010 at 9:28 PM, Kevin Grittner
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, such a technique shows a p
"Kevin Grittner" wrote:
> Bruce Momjian 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 changes to your subscription:
http:/
* 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
obvio
On Fri, Jan 8, 2010 at 10:07, Stephen Frost 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.
> Or, at bes
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alex Hunsaker writes:
> > On Fri, Jan 8, 2010 at 07:27, Tom Lane 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
Greg Stark 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 have the dire
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, t
* 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 proje
On Friday 08 January 2010 17:38:15 Alex Hunsaker wrote:
> On Fri, Jan 8, 2010 at 02:03, Magnus Hagander 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 d
On Fri, Jan 8, 2010 at 5:13 PM, David E. Wheeler 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
>> install extensio
Stephen Frost 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 the package
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
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 that phase, which
On Fri, Jan 8, 2010 at 11:44 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Jan 7, 2010 at 9:11 PM, Andrew Dunstan 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. W
On Thu, Jan 7, 2010 at 5:45 PM, Tom Lane wrote:
> Peter Eisentraut 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 annoyance to
>> keep up to date
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 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 people have a source p
On Fri, Jan 8, 2010 at 12:24 PM, Tom Lane wrote:
> Stephen Frost 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 horribl
On Thu, Jan 7, 2010 at 21:07, David E. Wheeler 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 builds on the existin
On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander wrote:
> On Thu, Jan 7, 2010 at 21:07, David E. Wheeler 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 re
Stephen Frost 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 about the inte
On Fri, Jan 8, 2010 at 18:44, Dave Page wrote:
> On Fri, Jan 8, 2010 at 5:38 PM, Magnus Hagander wrote:
>> On Thu, Jan 7, 2010 at 21:07, David E. Wheeler wrote:
>>> Hackers,
>>>
>>> I've posted a [plan] to implement PGAN][], a CPAN for PostgreSQL
>>> extensions. I've tried to closely follow the
2010/1/8 Magnus Hagander :
> On Fri, Jan 8, 2010 at 18:44, Dave Page 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 from the mirror
>> list, and then
Greg Stark 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 and abstract
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 installatio
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
