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:
> 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
"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:/
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
* 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
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
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
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
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
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
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
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.
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, 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
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
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.
>
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
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
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
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
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, 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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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
(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: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-
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
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
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:
> 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
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
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 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
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 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 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, 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()
>
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
>
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:
>
>> 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:
> 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
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
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
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
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.
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,
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
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
> 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"?
-
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
>
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
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
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'
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
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
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 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
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
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
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://
-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
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.
>>
>>
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
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
101 - 177 of 177 matches
Mail list logo
