All,
A tester correctly reported this:
But in the sample file, the "synchronous_standby_names" parameter is the
first parameter under the heading "- Streaming Replication - Server
Settings" while in the documentation, that parameter has its own
subsection 18.5.5 after the "streaming rep
On Thu, Apr 7, 2011 at 2:49 PM, Merlin Moncure wrote:
> On Thu, Apr 7, 2011 at 1:28 PM, Merlin Moncure wrote:
>> int ByteOffset = xid / BITS_PER_BYTE;
>
> whoops, I just notice this was wrong -- the byte offset needs to be
> taking bucket into account. I need to clean this
On Tue, 2011-06-28 at 22:20 +0200, Florian Pflug wrote:
> Hm, so RANGEINPUT would actually be what was previously discussed as
> the "range as a pair of bounds" definition, as opposed to the
> "range as a set of values" definition. So essentially we'd add a
> second concept of what a "range" is to
On 11-06-28 01:52 AM, Jun Ishiduka wrote:
>> Considering everything that has been discussed on this thread so far.
>>
>> Do you still think your patch is the best way to accomplish base backups
>> from standby servers?
>> If not what changes do you think should be made?
> I reconsider the way to no
On Wed, Jun 15, 2011 at 1:58 AM, Fujii Masao wrote:
> After we run "pg_ctl promote", time-delayed replication should be disabled?
> Otherwise, failover might take very long time when we set recovery_time_delay
> to high value.
PFA a patch that I believe will disable recovery_time_delay after
prom
On Tue, Jun 28, 2011 at 8:11 PM, Florian Pflug wrote:
>> I wrote a little script to show to reorganize this data in a
>> possibly-easier-to-understand format - ordering each column from
>> lowest to highest, and showing each algorithm as a multiple of the
>> cheapest value for that column:
>
> If
Peter Eisentraut wrote:
> On m?n, 2011-06-27 at 14:34 -0400, Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Robert Haas wrote:
> > > > It's easier to read the patches if you do separate changes in separate
> > > > patches. Anyway, I'm a bit nervous about this hunk:
> > > >
> > > > +
On Jun28, 2011, at 22:18 , Robert Haas wrote:
> On Tue, Jun 28, 2011 at 2:33 PM, Florian Pflug wrote:
>> [ testing of various spinlock implementations ]
>
> I set T=30 and N="1 2 4 8 16 32" and tried this out on a 32-core
> loaner from Nate Boley:
Cool, thanks!
> 100 counter increments per cycl
On Tue, Jun 28, 2011 at 10:11:59PM +0200, Kohei KaiGai wrote:
> 2011/6/28 Noah Misch :
> > Suppose your query references two views owned by different roles. ?The quals
> > of those views will have the same depth. ?Is there a way for information to
> > leak from one view owner to another due to that
On Tue, Jun 28, 2011 at 5:55 PM, Florian Pflug wrote:
> On Jun28, 2011, at 23:48 , Robert Haas wrote:
>> On Tue, Jun 28, 2011 at 5:33 PM, Merlin Moncure wrote:
>>> On Tue, Jun 28, 2011 at 3:18 PM, Robert Haas wrote:
user-32:
none(1.0),atomicinc(14.4),pg_lwlock_cas(22.1),cmpxchng(41.2)
On Jun28, 2011, at 23:48 , Robert Haas wrote:
> On Tue, Jun 28, 2011 at 5:33 PM, Merlin Moncure wrote:
>> On Tue, Jun 28, 2011 at 3:18 PM, Robert Haas wrote:
>>> user-32:
>>> none(1.0),atomicinc(14.4),pg_lwlock_cas(22.1),cmpxchng(41.2),pg_lwlock(588.2),spin(1264.7)
>>
>> I may not be following
On 06/28/2011 05:31 PM, Peter Eisentraut wrote:
On tis, 2011-06-28 at 17:05 -0400, Andrew Dunstan wrote:
Couldn't you just put a text file on the build farm server with
recommended branches?
As I told Magnus, that gets ugly because of limitations in MinGW's SDK
perl. I suppose I could just no
On Tue, Jun 28, 2011 at 5:33 PM, Merlin Moncure wrote:
> On Tue, Jun 28, 2011 at 3:18 PM, Robert Haas wrote:
>> user-32:
>> none(1.0),atomicinc(14.4),pg_lwlock_cas(22.1),cmpxchng(41.2),pg_lwlock(588.2),spin(1264.7)
>
> I may not be following all this correctly, but doesn't this suggest a
> huge
Heikki Linnakangas wrote:
> On 28.06.2011 20:47, Kevin Grittner wrote:
> Hmm, the calls in question are the ones in heapgettup() and
> heapgettup_pagemode(), which are subroutines of heap_getnext().
> heap_getnext() is only used in sequential scans, so it seems safe
> to remove those calls.
I
On Tue, Jun 28, 2011 at 3:18 PM, Robert Haas wrote:
> user-32:
> none(1.0),atomicinc(14.4),pg_lwlock_cas(22.1),cmpxchng(41.2),pg_lwlock(588.2),spin(1264.7)
I may not be following all this correctly, but doesn't this suggest a
huge potential upside for the cas based patch you posted upthread when
On tis, 2011-06-28 at 17:05 -0400, Andrew Dunstan wrote:
> > Couldn't you just put a text file on the build farm server with
> > recommended branches?
>
> As I told Magnus, that gets ugly because of limitations in MinGW's SDK
> perl. I suppose I could just not implement the feature for MinGW, but
On 06/28/2011 04:51 PM, Peter Eisentraut wrote:
On tis, 2011-06-28 at 15:37 -0400, Andrew Dunstan wrote:
What I'd like to do is to allow this to read:
if ($branch eq 'global')
{
$conf{branches_to_build} = 'ALL';
}
and have it choose the right set for you.
It seems t
2011/6/28, Robert Haas :
> You know, it just occurred to me while reading this email that you're
> using the term "predicate lock" in a way that is totally different
> from what I learned in school. What I was taught is that the word
> "predicate" in "predicate lock" is like the word "tuple" in "
On tis, 2011-06-28 at 15:37 -0400, Andrew Dunstan wrote:
> What I'd like to do is to allow this to read:
>
> if ($branch eq 'global')
> {
> $conf{branches_to_build} = 'ALL';
> }
>
> and have it choose the right set for you.
It seems to me that if you put a marker file into o
2011/6/28 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of mar jun 28 16:19:02 -0400 2011:
>
>> there should be a format (syntax) error. If somebody breaks a pg_ident
>> and will do a reload, then all ident mapping is lost.
>
> No, the file is not actually parsed until the auth verificat
Excerpts from Pavel Stehule's message of mar jun 28 16:19:02 -0400 2011:
> there should be a format (syntax) error. If somebody breaks a pg_ident
> and will do a reload, then all ident mapping is lost.
No, the file is not actually parsed until the auth verification runs.
The incorrect tokens are
On Jun28, 2011, at 05:42 , Jeff Davis wrote:
> On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
>> Couldn't we also do neither of these things? I mean, presumably
>> '[1,10]'::int8range had better work.
>
> I think that if we combine this idea with Florian's "PAIR" suggestion
> here:
> http:
2011/6/28 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of dom jun 26 13:10:13 -0400 2011:
>> Hello
>>
>> >
>> > I have touched next_token() and next_token_expand() a bit more, because
>> > it seemed to me that they could be simplified further (the bit about
>> > returning the comma in t
On Tue, Jun 28, 2011 at 2:33 PM, Florian Pflug wrote:
> [ testing of various spinlock implementations ]
I set T=30 and N="1 2 4 8 16 32" and tried this out on a 32-core
loaner from Nate Boley:
100 counter increments per cycle
worker 1 2 4 8
Thanks for your reviewing,
2011/6/28 Noah Misch :
> I took a look at this patch. It's incredibly simple, which is great, and it
> seems to achieve its goal.
>
> Suppose your query references two views owned by different roles. The quals
> of those views will have the same depth. Is there a way
Excerpts from Pavel Stehule's message of dom jun 26 13:10:13 -0400 2011:
> Hello
>
> >
> > I have touched next_token() and next_token_expand() a bit more, because
> > it seemed to me that they could be simplified further (the bit about
> > returning the comma in the token, instead of being a boole
On 06/28/2011 03:48 PM, Dave Page wrote:
But if you want to run some more frequently you'd still be stuck having to
manage that yourself. There's actually not a lot of point in doing it that way,
though. We don't build unless there have been changes on the branch, unless
told otherwise, so
On Tuesday, June 28, 2011, Andrew Dunstan wrote:
>
>
> On 06/28/2011 03:17 PM, Dave Page wrote:
>
> On Tue, Jun 28, 2011 at 8:02 PM, Magnus Hagander wrote:
>
> If we can find a good way to do it, I think having BF animals
> automatically picking up new branches is a very good thing to have. So
>
On Tue, Jun 28, 2011 at 02:11:11PM -0400, Robert Haas wrote:
> On Mon, Jun 27, 2011 at 10:43 PM, Noah Misch wrote:
> > On Mon, Jun 27, 2011 at 03:45:43PM -0400, Robert Haas wrote:
> >> On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch wrote:
> >> > [patch to avoid index rebuilds]
> >>
> >> With respect
On 06/28/2011 03:17 PM, Dave Page wrote:
On Tue, Jun 28, 2011 at 8:02 PM, Magnus Hagander wrote:
If we can find a good way to do it, I think having BF animals
automatically picking up new branches is a very good thing to have. So
don't give up so easily :D If adding a more or less random file
On 06/28/2011 03:02 PM, Magnus Hagander wrote:
If it's contentious I won't bother. We've managed OK for years, and can go
on managing as we are.
If we can find a good way to do it, I think having BF animals
automatically picking up new branches is a very good thing to have. So
don't give up
On Tue, Jun 28, 2011 at 8:02 PM, Magnus Hagander wrote:
>
> If we can find a good way to do it, I think having BF animals
> automatically picking up new branches is a very good thing to have. So
> don't give up so easily :D If adding a more or less random file to
> back branches is the only way to
On Tue, Jun 28, 2011 at 20:38, Andrew Dunstan wrote:
>
>
> On 06/28/2011 01:54 PM, Magnus Hagander wrote:
>>
>> On Tue, Jun 28, 2011 at 19:46, Andrew Dunstan wrote:
>>>
>>> I'd like to add a feature to the buildfarm that automatically picks up
>>> any
>>> new branch and automatically stops buildi
New version of patch. Bug which caused falldown on trees with high number of
levels was fixed. Also some more comments and refactoring.
--
With best regards,
Alexander Korotkov.
gist_fast_build-0.3.0.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsq
On 06/28/2011 01:54 PM, Magnus Hagander wrote:
On Tue, Jun 28, 2011 at 19:46, Andrew Dunstan wrote:
I'd like to add a feature to the buildfarm that automatically picks up any
new branch and automatically stops building any branch we're not maintaining
any more. To do the latter, I need some w
On Jun23, 2011, at 23:40 , Robert Haas wrote:
>>> I tried rewriting the LWLocks using CAS. It actually seems to make
>>> things slightly worse on the tests I've done so far, perhaps because I
>>> didn't make it respect spins_per_delay. Perhaps fetch-and-add would
>>> be better, but I'm not holdin
On Tue, Jun 28, 2011 at 1:47 PM, Kevin Grittner
wrote:
> (5) When a heap scan is executed, there is no index gap to lock to
> cover the predicate involved, so we need to acquire a heap relation
> lock -- any insert to the relation by an overlapping transaction is a
> rw-conflict. While these *lo
On 28.06.2011 20:47, Kevin Grittner wrote:
(3) Heap tuples are locked so that updates or deletes by an
overlapping transaction of the tuple which has been read can be
detected as a rw-conflict. Keep in mind that access for such a
delete or update may not go through the same index on which the
c
On 06/25/2011 12:14 AM, Steve Singer wrote:
> I'm not a libpq guru but I've given your patch a look over.
>
Thanks for the review!
I have since simplified the patch to assume that partial SSL writes are
disabled -- according to SSL_write(3) this is the default behaviour.
Now the SSL retry buffer
On Tue, Jun 28, 2011 at 09:15, Robert Haas wrote:
> Anyway, if we are going to insist on rewriting substantial chunks of
> the logging infrastructure before doing this, we at least need to
> reach some agreement on what would be an acceptable outcome - and then
> let Stephen code that up as a sepa
On Mon, Jun 27, 2011 at 10:43 PM, Noah Misch wrote:
> On Mon, Jun 27, 2011 at 03:45:43PM -0400, Robert Haas wrote:
>> On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch wrote:
>> > [patch to avoid index rebuilds]
>>
>> With respect to the documentation hunks, it seems to me that the first
>> hunk might
On Tue, Jun 28, 2011 at 19:46, Andrew Dunstan wrote:
>
> I'd like to add a feature to the buildfarm that automatically picks up any
> new branch and automatically stops building any branch we're not maintaining
> any more. To do the latter, I need some way for the client to detect that we
> are or
Heikki Linnakangas wrote:
> On 27.06.2011 21:23, Kevin Grittner wrote:
> The bigger question is if those calls are needed at all
> (
http://archives.postgresql.org/message-id/4e072ea9.3030...@enterprisedb.com
> ).
Ah, I didn't properly grasp your concerns the first time I read that.
The heap r
I'd like to add a feature to the buildfarm that automatically picks up
any new branch and automatically stops building any branch we're not
maintaining any more. To do the latter, I need some way for the client
to detect that we are or aren't interested in a branch. What I'd like to
do is add
Excerpts from Tom Lane's message of mar jun 28 10:39:22 -0400 2011:
> I think it would be sensible to block branch removal, as there's
> basically never a scenario where we'd do that during current usage.
> I'm not excited about blocking branch addition, although I worry
> sooner or later somebody
Excerpts from Greg Stark's message of sáb jun 25 21:01:36 -0400 2011:
> I think this commit was ill-advised:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
> Seems way to implementation-specific and detailed for a user to make
> heads or
On Tue, Jun 28, 2011 at 12:58 PM, Jeff Davis wrote:
> On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote:
>> On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis wrote:
>> > So, in effect, RANGEINPUT is a special type used only for range
>> > constructors. If someone tried to output it, it would throw
Actually, there is no more direct need of this patch because I've rewrote
insert function for fast build. But there are still two points for having
this changes:
1) As it was noted before, it simplifies code a bit.
2) It would be better if childoffnum have the same semantics in regular
insert and f
On Tue, 2011-06-28 at 09:30 -0700, David E. Wheeler wrote:
> On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote:
>
> > Do we think that this is a good way forward? The only thing I can think
> > of that's undesirable is that it's not normal to be required to cast the
> > result of a function, and might
On Tue, 2011-06-28 at 10:58 -0400, Robert Haas wrote:
> On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis wrote:
> > So, in effect, RANGEINPUT is a special type used only for range
> > constructors. If someone tried to output it, it would throw an
> > exception, and we'd even have enough information at
On Jun 28, 2011 6:29 PM, "Tom Lane" wrote:
>
> Robert Haas writes:
> > How about if we allow addition only of branches matching
> > /^REL_[0-9_]+_STABLE$/ and disallow deletion of all branches?
>
> +1, if feasible.
>
Pretty sure that's just a Small Matter Of Programming. I'll give it a try.
/Ma
Robert Haas writes:
> How about if we allow addition only of branches matching
> /^REL_[0-9_]+_STABLE$/ and disallow deletion of all branches?
+1, if feasible.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On Jun 27, 2011, at 8:42 PM, Jeff Davis wrote:
> Do we think that this is a good way forward? The only thing I can think
> of that's undesirable is that it's not normal to be required to cast the
> result of a function, and might be slightly difficult to explain in the
> documentation in a straigh
On 28 June 2011 22:36, Alvaro Herrera wrote:
> Excerpts from HuangQi's message of lun jun 27 23:56:22 -0400 2011:
>
> > BTW, which email system are you using to send to postgres mailing
> list?
> > As you can keep the top-answering and maintain the title of your email
> with
> > [hackers] in
On Tue, Jun 28, 2011 at 11:44 AM, Cédric Villemain
wrote:
> out of curiosity, does it affect the previous benchmarks of the feature ?
I don't think there's much performance impact, because the only case
where we actually have to do any real work is when vacuum comes
through and marks a buffer we'
2011/6/27 Robert Haas :
> On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas wrote:
>> On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas wrote:
>>> Well, it seems I didn't put nearly enough thought into heap_update().
>>> The fix for the immediate problem looks simple enough - all the code
>>> has been ref
> I've nearly finished editing prior to commit, so no worries.
Thank you, let me know if I can help.
Leonardo
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 28, 2011 at 11:05 AM, Andrew Dunstan wrote:
> +1. Spurious branch addition shouldn't cause us much pain - we'd just remove
> the new branch. Unwanted deletion is more disruptive.
How about if we allow addition only of branches matching
/^REL_[0-9_]+_STABLE$/ and disallow deletion of a
On Mon, Jun 27, 2011 at 6:25 PM, Alex Hunsaker wrote:
> Ive been holding off because its marked as Waiting on Author, am now
> thinking thats a mistake. =)
>
> It links to this patch:
> http://archives.postgresql.org/message-id/20110215135131.gx4...@tamriel.snowman.net
>
> Which is older than the
I took a look at this patch. It's incredibly simple, which is great, and it
seems to achieve its goal.
Suppose your query references two views owned by different roles. The quals
of those views will have the same depth. Is there a way for information to
leak from one view owner to another due t
On 06/28/2011 10:39 AM, Tom Lane wrote:
Magnus Hagander writes:
We discussed earlier to potentially block the creation, and removal,
of branches on the origin server, to prevent mistakes like this. It
has only happened once in almost a year, so it's probably not
necessary - but I wanted to ra
On Mon, Jun 27, 2011 at 11:42 PM, Jeff Davis wrote:
> So, in effect, RANGEINPUT is a special type used only for range
> constructors. If someone tried to output it, it would throw an
> exception, and we'd even have enough information at that point to print
> a nice error message with a hint.
I do
On Tue, Jun 28, 2011 at 16:39, Tom Lane wrote:
> Magnus Hagander writes:
>> We discussed earlier to potentially block the creation, and removal,
>> of branches on the origin server, to prevent mistakes like this. It
>> has only happened once in almost a year, so it's probably not
>> necessary - b
Magnus Hagander writes:
> We discussed earlier to potentially block the creation, and removal,
> of branches on the origin server, to prevent mistakes like this. It
> has only happened once in almost a year, so it's probably not
> necessary - but I wanted to raise the option anyway in case people
Excerpts from HuangQi's message of lun jun 27 23:56:22 -0400 2011:
> BTW, which email system are you using to send to postgres mailing list?
> As you can keep the top-answering and maintain the title of your email with
> [hackers] in front, my gmail can not help on that. For this email, I jus
Sorry for the long delay...
(2011/06/17 21:59), David Fetter wrote:
> On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
>> (2011/06/17 8:44), David Fetter wrote:
>>> Sorry not to respond sooner.
>>>
>>> First, the per-column generic options are a great thing for us to
>>> have. :)
>>
On Tue, Jun 28, 2011 at 8:30 AM, Leonardo Francalanci wrote:
>> Leonardo,
>>
>> Your patch:
>>
>> use less space in xl_xact_commit
>>
>> ... has been waiting on an updated version from you for 10 days now. Do
>> you think you're likely to complete it for this CommitFest?
>
>
> I sent an email o
On Tue, 28 Jun 2011 at 10:40, Heikki Linnakangas wrote:
It seems to me you could just stop setting silent_mode. If you want
to capture any early errors at startup into a log file, like
silent_mode does to postmaster.log, you can redirect stdout and
stderr in the startup script. pg_ctl start -l
On Mon, Jun 27, 2011 at 10:32 PM, Alexander Korotkov
wrote:
> I didn't have an estimate yet, but I'm working on it.
>
Now, it seems that I have an estimate.
N - total number of itups
B - avg. number of itups in page
H - height of tree
K - avg. number of itups fitting in node buffer
step - level s
On 27.06.2011 12:38, Reinhard Max wrote:
On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote:
Max, you're the maintainer of the PostgreSQL SuSE RPMs, right?
my first name is Reinhard, but aside from that, you are right. ;)
Sorry :-)
Can you comment on the above?
I enabled it many yea
> Leonardo,
>
> Your patch:
>
> use less space in xl_xact_commit
>
> ... has been waiting on an updated version from you for 10 days now. Do
> you think you're likely to complete it for this CommitFest?
I sent an email on the subject:
http://postgresql.1045698.n5.nabble.com/use-less-space-
71 matches
Mail list logo
