On Fri, Jul 16, 2010 at 7:43 PM, Heikki Linnakangas
wrote:
> On 16/07/10 10:40, Fujii Masao wrote:
>>
>> So we should always prevent the standby from applying any WAL in pg_xlog
>> unless walreceiver is in progress. That is, if there is no WAL available
>> in the archive, the standby ignores pg_xl
2010/7/21 Itagaki Takahiro :
> I reviewed the core changes of the patch. I don't think we need
> mb_string_info() at all. Instead, we can just call pg_mbxxx() functions.
>
> I rewrote the patch to use pg_mbstrlen_with_len() and pg_mbcharcliplen().
> What do you think the changes? It requires re-cou
2010/7/21 Itagaki Takahiro :
> 2010/7/20 Pavel Stehule :
>> here is a new version - new these functions are not a strict and
>> function to_string is marked as stable.
>
> We have array_to_string(anyarray, text) and string_to_array(text, text),
> and you'll introduce to_string(anyarray, text, text)
(2010/07/20 2:19), Heikki Linnakangas wrote:
> On 19/07/10 20:08, Robert Haas wrote:
>> 2010/7/8 KaiGai Kohei:
>>> (2010/07/08 22:08), Robert Haas wrote:
I think we pretty much have conceptual agreement on the shape of the
solution to this problem: when a view is created with CREATE SECUR
On Tue, Jul 20, 2010 at 11:14 PM, Robert Haas wrote:
> OK, committed.
When I specify the path of the directory for the Unix-domain socket
as the host, \conninfo doesn't mention that this connection is based
on the Unix-domain socket. Is this intentional?
$ psql -h"/tmp" -c"\conninfo"
You are con
(2010/07/20 2:13), Heikki Linnakangas wrote:
> On 09/07/10 06:47, KaiGai Kohei wrote:
>> When leaky and non-leaky functions are chained within a WHERE clause,
>> it will be ordered by the cost of functions. So, we have possibility
>> that leaky functions are executed earlier than non-leaky function
2010/7/20 Pavel Stehule :
> here is a new version - new these functions are not a strict and
> function to_string is marked as stable.
We have array_to_string(anyarray, text) and string_to_array(text, text),
and you'll introduce to_string(anyarray, text, text) and
to_array(text, text, text).
Do we
I reviewed the core changes of the patch. I don't think we need
mb_string_info() at all. Instead, we can just call pg_mbxxx() functions.
I rewrote the patch to use pg_mbstrlen_with_len() and pg_mbcharcliplen().
What do you think the changes? It requires re-counting lengths of multi-byte
strings in
On Sat, Jul 17, 2010 at 4:22 AM, Heikki Linnakangas
wrote:
>> The patch adds the document about the relationship between a restartpoint
>> and checkpoint_segments parameter.
>
> Thanks, committed with minor editorialization
Thanks.
> There will always be at least one WAL segment file, and w
Hi,
I am trying to build RPostgreSQL on Solaris 10u7 X64, but have problems
with pg_config, the configure script of RPostgreSQL checks for pg_config and
got “checking for pg_config... /usr/bin/pg_config”. In Solaris 10u7 X64,
three versions of PostgreSQL are installed, there are in
/usr/postgres/8
On Tue, Jul 20, 2010 at 3:37 AM, Itagaki Takahiro
wrote:
> 2010/7/13 Alexander Korotkov :
>> Anyway I think that overhead is not ignorable. That's why I have splited
>> levenshtein_internal into levenshtein_internal and levenshtein_internal_mb,
>> and levenshtein_less_equal_internal into levenshte
On Tue, Jul 20, 2010 at 3:33 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
>> wrote:
>>> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
>>> - WHERE (d1.ID=234409763) or (d2.ID=234409763)
>>> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
>
On Tue, Jul 20, 2010 at 3:13 PM, Bruce Momjian wrote:
> Someone at OSCON just asked if there is a way to find the _time_ delay
> between received and applied WAL. Right now
> pg_last_xlog_replay_location() only reports the information in WAL
> scale. It would be nice to report that in time, e.g.
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure wrote:
2. Use temp table instead of tuplestore list. Since we agreed we need
to execute each plan one by one starting and shutting down executor,
it now looks very simple strategy.
>>>
>>> I didn't look at this because I thought using
Robert Haas wrote:
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
Well, I had looked forward to actually putting the real author into the
author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
I think our cu
On Tue, Jul 20, 2010 at 6:00 PM, Kevin Grittner
wrote:
> What will make everyone happy here?
Nothing.
But on a more serious note, the basic dilemma with this patch is
whether it's useful enough to justify the extra code. I think it's
pretty clearly harmless (modulo the fact that it might have b
(2010/07/21 7:33), Kevin Grittner wrote:
> David Christensen wrote:
>> On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
>
>>> my shop has chosen to never touch the default postgresql.conf
>>> file any more, beyond adding one line to the bottom of it which
>>> is an include directive, to bring i
On Tue, Jul 20, 2010 at 5:46 PM, Alvaro Herrera
wrote:
> Excerpts from Markus Wanner's message of mar jul 20 14:54:42 -0400 2010:
>
>> > With respect to imessages specifically, what is the motivation for
>> > using shared memory rather than something like an SLRU? The new
>> > LISTEN implementati
David Christensen wrote:
> On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
>> my shop has chosen to never touch the default postgresql.conf
>> file any more, beyond adding one line to the bottom of it which
>> is an include directive, to bring in our overrides.
> So you'll now issue:
>
> $
Robert Haas wrote:
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to screw
On Jul 20, 2010, at 5:00 PM, Kevin Grittner wrote:
> Top posting. On purpose. :p
>
> This patch seems to be foundering in a sea of opinions. It seems
> that everybody wants to do *something* about this, but what?
>
> For one more opinion, my shop has chosen to never touch the default
> postg
Top posting. On purpose. :p
This patch seems to be foundering in a sea of opinions. It seems
that everybody wants to do *something* about this, but what?
For one more opinion, my shop has chosen to never touch the default
postgresql.conf file any more, beyond adding one line to the bottom
of
Excerpts from Markus Wanner's message of mar jul 20 14:54:42 -0400 2010:
> > With respect to imessages specifically, what is the motivation for
> > using shared memory rather than something like an SLRU? The new
> > LISTEN implementation uses an SLRU and handles variable-size messages,
> > so it
On Tue, Jul 20, 2010 at 3:12 PM, Peter Eisentraut wrote:
> Well, I had looked forward to actually putting the real author into the
> author field.
What if there's more than one? What if you make changes yourself?
How will you credit the reviewer?
--
Robert Haas
EnterpriseDB: http://www.enterpr
On Tue, Jul 20, 2010 at 2:42 PM, Magnus Hagander wrote:
> On Tue, Jul 20, 2010 at 20:34, Robert Haas wrote:
>> I have some concerns related to the upcoming conversion to git and how
>> we're going to avoid having things get messy as people start using the
>> new repository. git has a lot more fl
On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada wrote:
> 2010/7/17 Marko Tiikkaja :
>> On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>>>
>>> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
>>> is exsiting one that work with single tuplestore, it might be sane to
>>> modify
On Sat, Jul 17, 2010 at 01:15:22AM +0900, Hitoshi Harada wrote:
> 2010/7/17 Marko Tiikkaja :
> > On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
> >>
> >> 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode
> >> is exsiting one that work with single tuplestore, it might be sane to
Robert Haas wrote:
Tom and, I believe, also Andrew have expressed some concerns about the
space that will be taken up by having multiple copies of the git
repository on their systems. While most users can probably get by
with a single repository, committers will likely need one for each
back-b
On Jul 20, 2010, at 2:18 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
>
>>> That seems sub-optimal; I can see people wanting to use this feature to do
>>> something like:
>>>
>>> psql -c 'set work_mem = blah' -f script.sql
>>>
>>> and then
On tis, 2010-07-20 at 13:31 +0300, Marko Kreen wrote:
> > http://wiki.postgresql.org/wiki/Standard_conforming_strings
>
> There is two sorts of support:
>
> 1. Detect stdstr on startup and use that setting.
>
> 2. Detect online changes to stdstr and follow them.
>
> AFAICS psycopg does not sup
Robert Haas writes:
> On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
> wrote:
>> JOIN DocPrimary d2 ON d2.BasedOn=d1.ID
>> - WHERE (d1.ID=234409763) or (d2.ID=234409763)
>> + WHERE (d2.BasedOn=234409763) or (d2.ID=234409763)
>
> I was thinking of the equivalence class machinery as well. I
On tis, 2010-07-20 at 13:04 -0400, Robert Haas wrote:
> 2. Clone the origin n times. Use more disk space. Live with it. :-)
Well, I plan to use cp -a to avoid cloning over the network n times, but
other than that that was my plan. My .git directory currently takes 283
MB, so I think I can just
+On Tue, Jul 20, 2010 at 21:15, Peter Eisentraut wrote:
> On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote:
>> Working on the git conversion
>
> What's the tool that is being used now? Can you keep us up to date on
> the options etc. you plan to use?
I'm currently running tests with a bu
Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
> > That seems sub-optimal; I can see people wanting to use this feature to do
> > something like:
> >
> > psql -c 'set work_mem = blah' -f script.sql
> >
> > and then being surprised when it works differently than just `psql
On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote:
> Working on the git conversion
What's the tool that is being used now? Can you keep us up to date on
the options etc. you plan to use?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Hi,
On 07/20/2010 09:05 PM, Alvaro Herrera wrote:
Hmm, deriving code from a paper published by IBM sounds like bad news --
who knows what patents they hold on the techniques there?
Yeah, that might be an issue. Note, however, that the lock-based variant
differs substantially from what's been
On tis, 2010-07-20 at 20:46 +0200, Magnus Hagander wrote:
> For one thing, this showed up in a lot of .po files for 8.1.0RC1.
> Peter, can you comment on if this coincides with the tools you use to
> do those things?
There are/were some games being played with the key words, so this
effect sounds
Someone at OSCON just asked if there is a way to find the _time_ delay
between received and applied WAL. Right now
pg_last_xlog_replay_location() only reports the information in WAL
scale. It would be nice to report that in time, e.g. milliseconds.
Because an idle master will not generate WAL, I
On tis, 2010-07-20 at 14:34 -0400, Robert Haas wrote:
> Right now, it's easy to find all the commits by a particular
> committer, and it's easy to see who committed a particular patch, and
> the number of distinct committers is pretty small. I'd hate to give
> that up.
>
> git log | grep '^Author
Excerpts from Markus Wanner's message of mar jul 20 14:36:55 -0400 2010:
> > I'm also unconvinced that spinlocks are the best locking primitive here.
> > Why not lwlocks?
>
> It's derived from a completely lock-free algorithm, as proposed by Maged
> M. Michael in: Scalable Lock-Free Dynamic Memo
Hi,
On 07/20/2010 08:23 PM, Robert Haas wrote:
Well, you can't really fix that problem with this infrastructure,
No, but it would allow you to better use the existing amount of shared
memory. Possibly avoiding the problem is certain scenarios.
The failure might
manifest itself in a totally
On tis, 2010-06-29 at 12:22 +0100, Mike Fowler wrote:
> Mike Fowler wrote:
> > Thanks again for your help Robert, turns out the fault was in the
> > pg_proc entry (the 3 up there should've been a two!). Once I took the
> > grammar out it was quickly obvious where I'd gone wrong.
> >
> > Attache
Magnus Hagander wrote:
> > I have reproduced this by modifying just the CVS tag:
> >
> > ? ? ? ?$PostgreSQL: pgsql/src/backend/catalog/README,v 1.15 2010/07/20
> > ? ? ? ?18:38:53 momjian Exp $
>
> To clarify with what Bruce said on IM to me, the situation is when the
> workflow is to manually cop
On Tue, Jul 20, 2010 at 20:42, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Working on the git conversion with keywords, and I've noticed a couple of
>> strange things that don't come up the same way in git. All of these are in
>> non-code files, but they do defeat the "identical tarball" mode
On Tue, Jul 20, 2010 at 20:34, Robert Haas wrote:
> I have some concerns related to the upcoming conversion to git and how
> we're going to avoid having things get messy as people start using the
> new repository. git has a lot more flexibility and power than CVS,
> and I'm worried that it would
Magnus Hagander wrote:
> Working on the git conversion with keywords, and I've noticed a couple of
> strange things that don't come up the same way in git. All of these are in
> non-code files, but they do defeat the "identical tarball" mode.
>
> For example, a number of files have commits showing
Hello Alvaro,
thank you for looking through this code.
On 07/20/2010 07:50 PM, Alvaro Herrera wrote:
Interesting, thanks.
I gave it a skim and found that it badly needs a lot more code comments.
Hm.. yeah, the dynshmem stuff could probably need more comments. (The
bgworker stuff is probably
I have some concerns related to the upcoming conversion to git and how
we're going to avoid having things get messy as people start using the
new repository. git has a lot more flexibility and power than CVS,
and I'm worried that it would be easy, even accidentally, to screw up
our history.
1. In
On tis, 2010-07-20 at 13:28 -0400, Aidan Van Dyk wrote:
> But *all* dependancies need to be proper in the build system, or you
> end
> up needing a git-clean-type-cleanup between branch switches, forcing a
> new configure run too, which takes too much time...
This realization, while true, doesn't
On Tue, Jul 20, 2010 at 1:50 PM, Alvaro Herrera
wrote:
> I'm not sure what kind of resistance you'll see to the idea of a
> dynamically allocatable shmem area. Maybe we could use this in other
> areas such as allocating space for heavyweight lock objects. Right now
> the memory usage for them co
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > > The attached patch does as suggested. I added the recovery code to the
> > > create tablespace function so I didn't have to duplicate all the code
> > > that computes the path names.
> > >
> > > Attached.
> >
> > Uh, another question. Looking at
As part of a performance investigation for a customer I've noticed an
O(N^2) performance issue on COMMITs of transactions that contain many
SAVEPOINTs. I've consistently measured COMMIT times of around 9 seconds,
with 49% CPU, mostly in LockReassignCurrentOwner().
BEGIN;
INSERT...
SAVEPOINT ...
I
On Mon, Jul 19, 2010 at 4:08 PM, Hitoshi Harada wrote:
>
> 2010/7/19 Tom Lane :
> > I looked into the problem reported here:
> > http://archives.postgresql.org/pgsql-bugs/2010-07/msg00119.php
> >
[...]
>
> >
> > 2. Split the processing of aggregates with ORDER BY/DISTINCT so that the
> > sorting/
Robert Haas wrote:
> 2. Clone the origin n times. Use more disk space. Live with it.
:-)
But each copy uses almost 0.36% of the formatted space on my 150GB
drive!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Excerpts from Markus Wanner's message of vie jul 02 19:44:46 -0400 2010:
> Having written a very primitive kind of a dynamic memory allocator for
> imessages [1], I've always wanted a better alternative. So I've
> investigated a bit, refactored step-by-step, and finally came up with
> the attac
* Robert Haas [100720 13:04]:
> 3. Clone the origin once. Apply patches to multiple branches by
> switching branches. Playing around with it, this is probably a
> tolerable way to work when you're only going back one or two branches
> but it's certainly a big nuisance when you're going back 5-
Tom and, I believe, also Andrew have expressed some concerns about the
space that will be taken up by having multiple copies of the git
repository on their systems. While most users can probably get by
with a single repository, committers will likely need one for each
back-branch that they work wi
Magnus Hagander wrote:
On Tue, Jul 20, 2010 at 18:13, Robert Haas wrote:
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
wrote:
Andrew Dunstan wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to be broken version of fromcv
On Tue, Jul 20, 2010 at 18:32, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> It would result in a massive merge commit and the duplication of
>> the entire history.
>
> Ah, well, if the two repositories don't share the same IDs, it a
> clear no-go. Now that I think about it, it would be a bit
Robert Haas wrote:
> It would result in a massive merge commit and the duplication of
> the entire history.
Ah, well, if the two repositories don't share the same IDs, it a
clear no-go. Now that I think about it, it would be a bit much to
expect those to match on independent conversions from
On Tue, Jul 20, 2010 at 12:08 PM, Mark Wong wrote:
> On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas wrote:
>> On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
>>> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>>>
Since it has been over a month since this review was posted and no ne
Kevin Grittner wrote:
Andrew Dunstan wrote:
I despaired of this repo being anything like reliable months ago.
AFAIK it is using a known to be broken version of fromcvs.
Could we have it pull (using git) from the repo you have working
correctly? (Or would that be too Rube Goldber
On Tue, Jul 20, 2010 at 18:13, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
> wrote:
>> Andrew Dunstan wrote:
>>
>>> I despaired of this repo being anything like reliable months ago.
>>> AFAIK it is using a known to be broken version of fromcvs.
>>
>> Could we have it pu
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
wrote:
> Andrew Dunstan wrote:
>
>> I despaired of this repo being anything like reliable months ago.
>> AFAIK it is using a known to be broken version of fromcvs.
>
> Could we have it pull (using git) from the repo you have working
> correctly? (
On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
>> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>>
>>> Since it has been over a month since this review was posted and no new
>>> version of the patch has appeared, I think we should
On Tue, Jul 20, 2010 at 4:53 PM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 11:08 AM, Dave Page wrote:
>> Any ideas?
>
> Are you by any chance running off of the broken git mirror?
>
> http://archives.postgresql.org/pgsql-hackers/2010-07/msg00916.php
I might be, yes :-)
--
Dave Page
Enterpr
Andrew Dunstan wrote:
> I despaired of this repo being anything like reliable months ago.
> AFAIK it is using a known to be broken version of fromcvs.
Could we have it pull (using git) from the repo you have working
correctly? (Or would that be too Rube Goldbergesque?)
-Kevin
--
Sent via
On Tue, Jul 20, 2010 at 11:08 AM, Dave Page wrote:
> Any ideas?
Are you by any chance running off of the broken git mirror?
http://archives.postgresql.org/pgsql-hackers/2010-07/msg00916.php
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via p
On Tue, Jul 20, 2010 at 11:23 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> All that having been said, I think the issue here is that the query
>> planner isn't inferring that d1.ID= implies d2.ID=> constant>, even though there's a join clause d1.ID=d2.ID.
>
> I think that's what the Equiv
On Tue, Jul 20, 2010 at 11:23 AM, David Christensen wrote:
>> Well, IIRC, one of -c and -f suppresses psqlrc, and the other does
>> not. This doesn't seem very consistent to me, but I'm not sure
>> there's much to be done about it at this point. I guess if you use
>> whichever one suppresses psq
On 09/02/2010 4:09 PM, Etienne Dube wrote:
Magnus Hagander wrote:
IIRC, we've had zero reports on whether the patch worked at all on 8.2
in an environment where the problem actually existed. So yes, some
testing and feedback would be much apprecaited.
//Magnus
Thanks for your quick reply.
We
2010/7/20 David Fetter :
> On Tue, Jul 20, 2010 at 11:40:18AM +0200, Pavel Stehule wrote:
>> 2010/7/20 Itagaki Takahiro :
>> > 2010/7/14 Pavel Stehule :
>> >> please, can you refresh patch, please?
>> >
>> > Updated patch attached. The latest version is always in the git
>> > repo. http://repo.or.
On Fri, Jul 16, 2010 at 2:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm not entirely happy with the way I handled the variable-length
>> struct, although I don't think it's horrible, either. I'm willing to
>> rework it if someone has a better idea.
>
> I don't like the way you did that eith
On Jul 20, 2010, at 9:05 AM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 10:00 AM, David Christensen
> wrote:
>> Sorry for the delays in response. This is fine; I think there are some
>> semantic questions that should still be resolved at this point, particularly
>> if we're moving toward s
Robert Haas writes:
> All that having been said, I think the issue here is that the query
> planner isn't inferring that d1.ID= implies d2.ID= constant>, even though there's a join clause d1.ID=d2.ID.
I think that's what the Equivalence Classes are for. Or at least that's
what they do in my hea
Continuing my fun setting up some new Solaris buildfarm critters, I'm
seeing this failure in the dblink test, on 9.0 and 9.1:
gmake[1]: Leaving directory `/export/home/dpage/postgresql/contrib/cube'
gmake[1]: Entering directory `/export/home/dpage/postgresql/contrib/dblink'
gmake -C ../../src/test
On Tue, Jul 20, 2010 at 11:40:18AM +0200, Pavel Stehule wrote:
> 2010/7/20 Itagaki Takahiro :
> > 2010/7/14 Pavel Stehule :
> >> please, can you refresh patch, please?
> >
> > Updated patch attached. The latest version is always in the git
> > repo. http://repo.or.cz/w/pgsql-fdw.git (branch: fdw
On Tue, Jul 20, 2010 at 1:57 AM, Zotov wrote:
> i wrote to
> pgsql-b...@postgresql.org
> they tell me write to
> pgsql-performa...@postgresql.org
> they tell me write here
>
> I don`t whant know how optimize query myself (i know it), and i think it
> must do planner.
According to the EXPLAIN
On Tue, Jul 20, 2010 at 5:41 AM, Artur Dabrowski wrote:
> I have been redirected here from pg-general.
>
> I tested full text search using GIN index and it turned out that the results
> depend on operating system. Not all the rows are found when executing some
> of queries on pg server installed o
On Tue, Jul 20, 2010 at 12:16 AM, David Christensen wrote:
> On Jul 19, 2010, at 11:10 PM, Robert Haas wrote:
>
>> On Tue, Jul 20, 2010 at 12:07 AM, Robert Haas wrote:
>>> On Tue, Jul 20, 2010 at 12:02 AM, David Christensen
>>> wrote:
> I would propose to print instead:
>
> You are
On Tue, Jul 20, 2010 at 10:00 AM, David Christensen wrote:
> Sorry for the delays in response. This is fine; I think there are some
> semantic questions that should still be resolved at this point, particularly
> if we're moving toward supporting multiple -c and -f lines as expressed (an
> ide
Magnus Hagander wrote:
>> I believe revision 1.1.1.1 is normally seen only for file brought
>> in through the "cvs import" command. "vendor branch" would make
>> some sense as a commit message for an import.
>
> Yeah, something like that. But why do we for the file above have
> one "initial re
On Jul 19, 2010, at 10:40 PM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 9:22 AM, Robert Haas wrote:
>> On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
>>> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
Well, that might be a good idea, too, but my expectation is that:
On Tue, Jul 20, 2010 at 9:23 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> we gain something quite specific and tangible, namely, the
>> expectation that patch authors will stay on top of their patches
>> if they want them reviewed by the community.
>
> Barring some operational emergency he
On Tue, Jul 20, 2010 at 15:31, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> I'm also seeing some entries tagged with "vendor branch", such as:
>>
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README
>> revision 1.1.1.1
>>
>> Same issue there, the file comes out
Simon Riggs wrote:
> I don't think so. We can assume people wrote a patch because they
> want it included in Postgres. Bumping them doesn't help them or
> us, since there is always an issue other than wish-to-complete.
> Not everybody is able to commit time in the way we do and we
> should respe
On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote:
> > On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> >> A further point is that it's very difficult to
> >> keep track of progress if the CF page reflects a whole bunch of
> >> suppos
Magnus Hagander wrote:
> I'm also seeing some entries tagged with "vendor branch", such as:
>
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README
> revision 1.1.1.1
>
> Same issue there, the file comes out on the other end with the
> wrong keyword (in this case, list
Robert Haas wrote:
> we gain something quite specific and tangible, namely, the
> expectation that patch authors will stay on top of their patches
> if they want them reviewed by the community.
Barring some operational emergency here, I'll be reviewing the
status of all the open patches in the
Working on the git conversion with keywords, and I've noticed a couple of
strange things that don't come up the same way in git. All of these are in
non-code files, but they do defeat the "identical tarball" mode.
For example, a number of files have commits showing up in cvs with nothing at
all ch
On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote:
> On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
>> A further point is that it's very difficult to
>> keep track of progress if the CF page reflects a whole bunch of
>> supposedly "Waiting on Author" patches that are really quite
>> thorou
Hello
2010/7/16 Jan Urbański :
> Hi,
>
> here's a review of the \sf and \ef [num] patch from
> http://archives.postgresql.org/message-id/162867791003290927y3ca44051p80e697bc6b19d...@mail.gmail.com
>
> == Formatting ==
>
> The patch has some small tabs/spaces and whitespace issues and it applies
>
On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> A further point is that it's very difficult to
> keep track of progress if the CF page reflects a whole bunch of
> supposedly "Waiting on Author" patches that are really quite
> thoroughly dead.
True, but the point under discussion is what t
On Tue, Jul 20, 2010 at 7:41 AM, Simon Riggs wrote:
> So focus your effort by leaving this alone until the end of the CF.
> Actively terminating things early doesn't help at all with the review
> work you mention above, but it looks good if we are measuring "cases
> resolved per day". Are we measu
Hi, I've been reviewing this patch for the last few days. Here it is :
* Submission review
* Is the patch in context diff format?
Yes
* Does it apply cleanly to the current CVS HEAD?
Yes
* Does it include reasonable tests, necessary doc patches, etc?
Doc patches are there.
There are no reg
Hello
here is a new version - new these functions are not a strict and
function to_string is marked as stable.
both functions share code with older version.
Regards
Pavel
2010/7/16 Brendan Jurd :
> On 17 July 2010 04:52, Pavel Stehule wrote:
>> 2010/7/16 Brendan Jurd :
>>> Also, if we're goin
On Tue, 2010-07-20 at 07:06 -0400, Robert Haas wrote:
> To me, the definition of a fair shake is that people get 4-5 days to
> respond to review comments. This patch has had 33. It's not unfair
> to anyone to say, you know, since you didn't get around to updating
> this patch for over a month, yo
Hello
2010/7/20 Itagaki Takahiro :
> 2010/7/14 Pavel Stehule :
>> this patch is significantly reduced original patch. It doesn't propose
>> a simple allocator - just eliminate a high memory usage for ispell
>> dictionary.
>
> I don't think introducing new methods is a good idea. If you want a
> si
On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>
>> Since it has been over a month since this review was posted and no new
>> version of the patch has appeared, I think we should mark this patch
>> as Returned with Feedback.
>
> Mark pos
On 7/20/10, Peter Eisentraut wrote:
> On sön, 2010-07-18 at 09:42 -0700, David E. Wheeler wrote:
> > On Jul 18, 2010, at 1:35 AM, Peter Eisentraut wrote:
> >
> > > I think there are two ways we can do this, seeing that most appear to be
> > > in favor of doing it in the first place: Either we
1 - 100 of 111 matches
Mail list logo
