On Tue, Jun 25, 2013 at 12:03 PM, Craig Ringer wrote:
> On 06/25/2013 01:14 PM, Ashutosh Bapat wrote:
> > Hi,
> > I am observing a strange problem when I build latest PostgreSQL head on
> > Ubuntu 12.04. I am running Ubuntu 12.04 as VM on Mac 10.7. The build
> > directory points to a sub-directory
Hello
2013/6/25 Szymon Guz :
> Hi,
> I've got a couple of questions.
>
> I was using numeric_out like this:
>
> DatumGetCString(DirectFunctionCall1(numeric_out, d));
>
> Why do I have to use DirectFunctionCall1 instead of calling numeric_out?
numeric_out functions doesn't use C calling convention
On 06/25/2013 01:14 PM, Ashutosh Bapat wrote:
> Hi,
> I am observing a strange problem when I build latest PostgreSQL head on
> Ubuntu 12.04. I am running Ubuntu 12.04 as VM on Mac 10.7. The build
> directory points to a sub-directory of host directory shared from Mac to
> Ubuntu 12.04.
"shared" h
On 25 June 2013 00:51, Bruce Momjian wrote:
> On Sat, Jun 15, 2013 at 11:39:23AM -0400, Tom Lane wrote:
> > Simon Riggs writes:
> > > On 15 June 2013 00:01, Josh Berkus wrote:
> > >> If we're going to start adding reloptions for specific table behavior,
> > >> I'd rather think of all of the opt
Hi,
I've got a couple of questions.
I was using numeric_out like this:
DatumGetCString(DirectFunctionCall1(numeric_out, d));
Why do I have to use DirectFunctionCall1 instead of calling numeric_out?
I was suggested to use numeric_send instead of numeric_out, however when
changing the function n
On January 23, 2013 9:13 AM Josh Kupershmidt wrote:
>There have been some complaints[1][2] in the past about pg_ctl not playing
nice with relative path specifications for the datadir. Here's a concise
illustration:
>
> $ mkdir /tmp/mydata/ && initdb /tmp/mydata/
> $ cd /tmp/
> $ pg_ctl -D ./myda
On 25/06/13 15:56, Tom Lane wrote:
Mark Kirkwood writes:
One of the reasons for fewer reviewers than submitters, is that it is a
fundamentally more difficult job. I've submitted a few patches in a few
different areas over the years - however if I grab a patch on the queue
that is not in exactly
Hi David,
I hope this is the latest patch to review, right ?
I am going to review it.
I have gone through the discussion on this thread and I agree with Stephen
Frost that it don't add much improvements as such but definitely it is
going to be easy for contributors in this area as they don't nee
On 06/25/2013 01:36 PM, james wrote:
> On 25/06/2013 05:16, Tom Lane wrote:
>> It might be time to reconsider whether we should move the baseline
>> portability requirement up to C99.
>
> My understanding was that you picked up a lot of users when the Win32
> port became useful. While you can bui
2013/6/25 Rushabh Lathia :
>
>
>
> On Tue, Jun 25, 2013 at 1:47 AM, Pavel Stehule
> wrote:
>>
>> Hello
>>
>> This is fragment ofmy old code from orafce package - it is functional,
>> but it is written little bit more generic due impossible access to
>> static variables (in elog.c)
>>
>> static cha
On 25/06/2013 05:16, Tom Lane wrote:
It might be time to reconsider whether we should move the baseline
portability requirement up to C99.
My understanding was that you picked up a lot of users when the Win32
port became useful. While you can build with msys, I would think that
leaving Micro
Hi,
I am observing a strange problem when I build latest PostgreSQL head on
Ubuntu 12.04. I am running Ubuntu 12.04 as VM on Mac 10.7. The build
directory points to a sub-directory of host directory shared from Mac to
Ubuntu 12.04. The source is also located in a sub-directory of the shared
directo
On Tue, Jun 25, 2013 at 1:47 AM, Pavel Stehule wrote:
> Hello
>
> This is fragment ofmy old code from orafce package - it is functional,
> but it is written little bit more generic due impossible access to
> static variables (in elog.c)
>
> static char*
> dbms_utility_format_call_stack(char mode)
On Monday, June 24, 2013 11:00 PM Robert Haas wrote:
> On Thu, Jun 6, 2013 at 3:01 AM, Amit Kapila
> wrote:
> > To avoid above 3 factors in test readings, I used below steps:
> > 1. Initialize the database with scale factor such that database size
> +
> > shared_buffers = RAM (shared_buffers = 1/4
Hi,
>
>> So our proposal on this problem is that we must ensure that master should
> not make any file system level changes without confirming that the
>> corresponding WAL record is replicated to the standby.
>
> How will you take care of extra WAL on old master during recovery. If it
> plays t
Josh Kupershmidt writes:
> This patch is in the current CommitFest, does it still need to be
> reviewed? If so, I notice that the version in pgfoundry's CVS is
> rather different than the version the patch seems to have been built
> against (presumably the pg_filedump-9.2.0.tar.gz release), and
>
Bruce Momjian writes:
> Right. I don't think there are any C features we want to avoid; are
> there any?
We're avoiding C99-and-later features that are not in C89, such as //
for comments, as well as more useful things. It might be time to
reconsider whether we should move the baseline portabil
Mark Kirkwood writes:
> One of the reasons for fewer reviewers than submitters, is that it is a
> fundamentally more difficult job. I've submitted a few patches in a few
> different areas over the years - however if I grab a patch on the queue
> that is not in exactly one of the areas I know ab
On Mon, Jun 24, 2013 at 7:17 PM, Sawada Masahiko wrote:
>
>
>
> [Server]
> standby_name = 'slave1'
> synchronous_transfer = commit
> wal_sender_timeout = 30
> [Server]
> standby_name = 'slave2'
> synchronous_transfer = all
> wal_sender_timeout = 50
> ---
>
Wha
On 05/28/2013 04:41 PM, Szymon Guz wrote:
Hi,
I've got a patch.
This is for a plpython enhancement.
There is an item at the TODO list
http://wiki.postgresql.org/wiki/Todo#Server-Side_Languages
"Fix loss of information during conversion of numeric type to Python
float"
This patch uses a deci
On Tue, Jun 25, 2013 at 10:32:42AM +0800, Craig Ringer wrote:
> > Anything supported by C99 and not other versions I would say. However,
> > my point is if done correctly we would state which features ahead of
> > time we are willing to use and make them part of the developer faq?
>
> If C++ is se
On Mon, Jun 24, 2013 at 06:38:48PM -0700, Joshua D. Drake wrote:
>
> On 06/24/2013 05:37 PM, Bruce Momjian wrote:
> >
> >On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote:
> >>On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake
> >>wrote:
>
> I think the big question is whethe
Hi,
> parameter improvement idea is which we extend ini file for to set
> parameter each standby. For example :
>
>
> [Server]
> standby_name = 'slave1'
> synchronous_transfer = commit
> wal_sender_timeout = 30
> [Server]
> standby_name = 'slave2'
> synchronous_transfer = all
On 06/25/2013 09:38 AM, Joshua D. Drake wrote:
>
> On 06/24/2013 05:37 PM, Bruce Momjian wrote:
>>
>> On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote:
>>> On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake
>>> wrote:
>
> I think the big question is whether you can _control_ w
On Mon, Jun 24, 2013 at 01:32:41PM -0700, Josh Berkus wrote:
> Do we really have ironclad numbers which show that the patch affects
> performance negatively? I didn't think the previous performance test
> was comprehensive; I was planning to develop one myself this week.
Not ironclad, no:
http://
On Tue, Jun 25, 2013 at 11:06 AM, Noah Misch wrote:
> On Mon, Jun 24, 2013 at 10:10:11AM -0700, Josh Berkus wrote:
>> On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
>> > Josh Berkus writes:
>> >> patch. The vast majority chose not to respond to my email to them at
>> >> all. When private email
On Mon, Jun 24, 2013 at 10:10:11AM -0700, Josh Berkus wrote:
> On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
> > Josh Berkus writes:
> >> patch. The vast majority chose not to respond to my email to them at
> >> all. When private email fails, the next step is public email.
> >
> > The only pr
On 06/24/2013 05:37 PM, Bruce Momjian wrote:
On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote:
On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake wrote:
I think the big question is whether you can _control_ what C++ features
are used, or whether you are perpetually instructing u
On Sat, Jun 22, 2013 at 04:54:50PM +0200, Andres Freund wrote:
> On 2013-06-21 16:45:28 +0200, Andres Freund wrote:
> > On 2013-06-21 09:51:05 -0400, Noah Misch wrote:
> > > That being said, if we discover a simple-enough fix that performs well,
> > > we may
> > > as well incorporate it.
> >
> >
On Mon, Jun 24, 2013 at 4:50 PM, Tom Lane wrote:
> The point of what I was suggesting isn't to conserve storage, but to
> reduce downtime during a schema change. Remember that a rewriting ALTER
> TABLE locks everyone out of that table for a long time.
Sure, I understand. As Josh says, though, i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/2013 12:08 PM, Liming Hu wrote:
>>> I have implemented the code according to Joe's
>>> suggestion, and put the code at:
>>> https://github.com/liminghu/fuzzystrmatch/tree/fuzzystrmatchv1.1
>>>
>
>>>
Please submit a proper
On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote:
> On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake
> wrote:
> >>
> >> I think the big question is whether you can _control_ what C++ features
> >> are used, or whether you are perpetually instructing users what C++
> >> features not
On Tue, Jun 18, 2013 at 12:42 PM, Jeff Davis wrote:
> Attached a new diff for pg_filedump that makes use of the above change.
>
> I'm not sure what the resolution of Alvaro's concern was, so I left the
> flag reporting the same as the previous patch.
This patch is in the current CommitFest, does
On 12.6.2013 07:03, Pavel Stehule wrote:
> Hello
>
> I worked with gdc' _Decimal* types last week
>
> https://github.com/okbob/pgDecimal
>
> I tested it, and should to say, so implementation in gcc is not good
> - lack of lot of functionality, and our Money type is little bit
> faster :( Tomas V
On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake wrote:
>>
>> I think the big question is whether you can _control_ what C++ features
>> are used, or whether you are perpetually instructing users what C++
>> features not to use.
>
>
> How is that different than us having to do the same with C?
P
On 06/24/2013 04:59 PM, Bruce Momjian wrote:
On Thu, Jun 20, 2013 at 12:45:48PM +0800, Craig Ringer wrote:
I see value in making the codebase compileable with g++... and down the
track I can see being able to use basic class features as quite useful
given Pg's fairly OO internal design. Inline
On Thu, Jun 20, 2013 at 12:45:48PM +0800, Craig Ringer wrote:
> I see value in making the codebase compileable with g++... and down the
> track I can see being able to use basic class features as quite useful
> given Pg's fairly OO internal design. Inline template functions instead
> of macros woul
On Sat, Jun 15, 2013 at 11:39:23AM -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On 15 June 2013 00:01, Josh Berkus wrote:
> >> If we're going to start adding reloptions for specific table behavior,
> >> I'd rather think of all of the optimizations we might have for a
> >> prospective "append-
Le mardi 25 juin 2013 00:18:26, Andrew Dunstan a écrit :
> On 06/24/2013 04:02 PM, Cédric Villemain wrote:
> > WIth extension, we do have to set VPATH explicitely if we want to use
> > VPATH (note that contribs/extensions must not care that postgresql has
> > been built with or without VPATH set).
On Mon, Jun 24, 2013 at 04:00:00PM +0400, Alexander Law wrote:
> 23.06.2013 20:53, Noah Misch wrote:
>> The attached revision fixes all above points. Would you look it over? The
>> area was painfully light on comments, so I added some. I renamed
>> pgwin32_toUTF16(), which ceases to be a good na
On 06/24/2013 02:21 PM, Tom Lane wrote:
>> Right, but I'm worried about the "surprise!" factor. That is, if we
>> make the first default "free" by using a magic value, then a SET DEFAULT
>> on that column is going to have some very surprising results as suddenly
>> the whole table needs to get wri
Etsuro Fujita escribió:
> > From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
>
> > I tried several ways but I couldn't find big problems. Small typo:
> > s/rejunk/resjunk/
>
> Thank you for the review. Attached is an updated version of the patch.
Thanks. I gave this a look, and made it some
On Wed, Jun 19, 2013 at 1:21 AM, Alexander Korotkov wrote:
> On Mon, Jun 17, 2013 at 10:27 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 17.06.2013 15:56, Alexander Korotkov wrote:
>>
>>> On Sat, Jun 15, 2013 at 3:02 AM, Alexander Korotkov>> >**wrote:
>>>
>>> This patch intro
On 25/06/13 03:54, Joshua D. Drake wrote:
It is mentioned. Of course now I can't find it but it is there.
However, I believe you are taking the wrong perspective on this. This is
not a shame wall. It is a transparent reminder of the policy and those
who have not assisted in reviewing a patch b
On Fri, Jun 21, 2013 at 11:43 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 19.06.2013 11:56, Alexander Korotkov wrote:
>
>> On Wed, Jun 19, 2013 at 12:49 PM, Heikki Linnakangas<
>> hlinnakan...@vmware.com> wrote:
>>
>> On 19.06.2013 11:30, Alexander Korotkov wrote:
>>>
>>> On W
On Mon, Jun 24, 2013 at 11:06 PM, Andres Freund wrote:
> On 2013-06-24 09:57:24 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > Otherwise I think there's not really much left to be done. Fujii?
>>
>> Well, other than the fact that we've not got MVCC catalog scans yet.
>
> That statement was
On 06/24/2013 04:02 PM, Cédric Villemain wrote:
WIth extension, we do have to set VPATH explicitely if we want to use VPATH
(note that contribs/extensions must not care that postgresql has been built
with or without VPATH set). My patches try to fix that.
No, this is exactly what I'm obje
On Wed, Jun 19, 2013 at 12:44 AM, Alexander Korotkov
wrote:
> On Mon, Jun 17, 2013 at 4:54 PM, Alexander Korotkov
> wrote:
>
>> On Fri, Jun 14, 2013 at 12:09 AM, Alexander Korotkov <
>> aekorot...@gmail.com> wrote:
>>
>>> Revised version of patch for additional information storage in GIN is
>>> a
On 06/24/2013 03:39 PM, Tom Lane wrote:
Robert Haas writes:
We probably do need to preserve attribute numbers across an upgrade,
even for foreign tables. I think those could make their way into
other places.
Hm ... this argument would also apply to composite types; do we get it
right for tho
2013/6/24 Pavel Stehule :
> Hello
>
> you can try fresh patch
>
> git format-patch -1 788bce13d3249ddbcdf3443ee078145f4888ab45
and git format-patch -1 bc61878682051678ade5f59da7bfd90ab72ce13b
>
> regards
>
> Pavel
>
> 2013/6/24 Szymon Guz :
>> On 14 March 2013 03:45, Peter Eisentraut wrote:
>>>
Hello
you can try fresh patch
git format-patch -1 788bce13d3249ddbcdf3443ee078145f4888ab45
regards
Pavel
2013/6/24 Szymon Guz :
> On 14 March 2013 03:45, Peter Eisentraut wrote:
>>
>> On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
>> > in this use case I am think so some regression t
Josh Berkus writes:
> On 06/24/2013 01:50 PM, Tom Lane wrote:
>> The point of what I was suggesting isn't to conserve storage, but to
>> reduce downtime during a schema change. Remember that a rewriting ALTER
>> TABLE locks everyone out of that table for a long time.
> Right, but I'm worried abo
On 24 June 2013 21:42, Jeff Janes wrote:
> On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen
> wrote:
>
>> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
>> >
>> > ALTER TABLE foo
>> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED INITIALLY IMMEDIATE;
>>
>> I read the patch (looks go
Greg Stark wrote:
> On Mon, Jun 24, 2013 at 3:50 AM, Tom Lane wrote:
>> Or maybe they really don't give a damn about breaking
>> applications every time they invent a new reserved word?
>
> I think this is the obvious conclusion. In the standard the reserved
> words are pretty explicitly reserved
OK - I've attached another iteration of the patch with Troels' grammar
changes. I think the only issue remaining is what the standard says about
lead semantics. Thanks -
lead-lag-ignore-nulls.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 14 March 2013 03:45, Peter Eisentraut wrote:
> On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
> > in this use case I am think so some regression test is important - It
> > should not be mine, but missing more explicit regression test is
> > reason, why this bug was not detected some y
On 06/24/2013 01:50 PM, Tom Lane wrote:
> The point of what I was suggesting isn't to conserve storage, but to
> reduce downtime during a schema change. Remember that a rewriting ALTER
> TABLE locks everyone out of that table for a long time.
Right, but I'm worried about the "surprise!" factor.
i believe the last submission of the patch had no negative performance impact
on any of the tested use cases, but you'd have to go back and see the last
exchange on that.
i think it was the concern about potentially regressing the codeline in
unforeseen ways without a clear benefit to all but
On 24 June 2013 21:50, Tom Lane wrote:
> > So, Tom, how's that pluggable storage format coming? :-)
>
> Well, actually, it's looking to me like heap_form_tuple will be
> underneath the API cut, because alternate storage managers will probably
> have other tuple storage formats --- column stores
Robert Haas writes:
> If there's an actual performance consequence of applying this patch,
> then I think that's a good reason for rejecting it. But if the best
> argument we can come up with is that we might someday try to do even
> more clever things with the tuple's natts value, I guess I'm no
On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen wrote:
> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote:
> >
> > ALTER TABLE foo
> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED INITIALLY IMMEDIATE;
>
> I read the patch (looks good), applied it on HEAD (fine), ran make check
> (fine)
Simon,
> I think its rather a shame that the proponents of this patch have
> tried so hard to push this through without working variations on the
> theme. Please guys, go away and get creative; rethink the approach so
> that you can have your lunch without anybody else losing theirs. I
> would add
On Mon, Jun 24, 2013 at 4:05 PM, Simon Riggs wrote:
> I think its rather a shame that the proponents of this patch have
> tried so hard to push this through without working variations on the
> theme. Please guys, go away and get creative; rethink the approach so
> that you can have your lunch with
Hello
This is fragment ofmy old code from orafce package - it is functional,
but it is written little bit more generic due impossible access to
static variables (in elog.c)
static char*
dbms_utility_format_call_stack(char mode)
{
MemoryContext oldcontext = CurrentMemoryContext;
ErrorData *e
On 24 June 2013 15:49, Tom Lane wrote:
> Amit Kapila writes:
>> I will summarize the results, and if most of us feel that they are not good
>> enough, then we can return this patch.
>
> Aside from the question of whether there's really any generally-useful
> performance improvement from this patc
Le lundi 24 juin 2013 19:40:19, Andrew Dunstan a écrit :
> On 06/18/2013 09:52 AM, Cédric Villemain wrote:
> > I've rebased the current set of pending patches I had, to fix pgxs and
> > added 2 new patches.
> >
> > Bugfixes have already been presented and sent in another thread, except
> > the las
> Not necessarily --- that's an optional feature. In fact, I am not eager
> to encourage third-party PLs to start installing pg_pltemplate entries
> anymore, because that's mostly vestigial in the extensions universe.
> We should be encouraging use of CREATE EXTENSION not CREATE LANGUAGE to
> ins
Josh Berkus writes:
> Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
> using the packages at yum.postgresql.org. Is the below an issue with
> PL/R, the packages, or PostgreSQL?
> Seems like if a language is actually *installed*, it needs to have
> templates ...
Not necessa
On 2013-06-24 12:24:29 -0700, Josh Berkus wrote:
> Joe, all:
>
> Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
> using the packages at yum.postgresql.org. Is the below an issue with
> PL/R, the packages, or PostgreSQL?
>
> Seems like if a language is actually *installed*,
Robert Haas writes:
> We probably do need to preserve attribute numbers across an upgrade,
> even for foreign tables. I think those could make their way into
> other places.
Hm ... this argument would also apply to composite types; do we get it
right for those?
regards,
MauMau escribió:
> From: "Alvaro Herrera"
> >Actually, in further testing I noticed that the fast-path you introduced
> >in BackendCleanup (or was it HandleChildCrash?) in the immediate
> >shutdown case caused postmaster to fail to clean up properly after
> >sending the SIGKILL signal, so I had t
Joe, all:
Ok, this is wierd. This is PostgreSQL 9.2.4, on Centos 6, installed
using the packages at yum.postgresql.org. Is the below an issue with
PL/R, the packages, or PostgreSQL?
Seems like if a language is actually *installed*, it needs to have
templates ...
analytics=# \dL
On Mon, Jun 24, 2013 at 10:40:48AM -0700, Josh Berkus wrote:
> More, on the slacker list are 6-8 people who I happen to know are paid
> by their employers to work on PostgreSQL. Those are the folks I'm
> particularly targeting with the Slacker list; I want to make it
> transparently clear to thos
Szymon,
> I've reviewed some patches, but only some easier ones, like pure regression
> tests.
Actually, you were one of the people I was thinking of when I said
"mostly the new submitters have been exemplary in claiming some review
work". You're helping a lot.
> Unfortunately my knowledge is n
On Sat, Jun 22, 2013 at 3:55 PM, Andrew Dunstan wrote:
>> Essentially, cross version upgrade testing runs pg_dumpall from the new
>> version on the old cluster, runs pg_upgrade, and then runs pg_dumpall on the
>> upgraded cluster, and compares the two outputs. This is what we get when the
>> new v
I'm just wondering about newbies...
I've created my first patch, so I'm one of them, I think.
I've reviewed some patches, but only some easier ones, like pure regression
tests. Unfortunately my knowledge is not enough to review patches making
very deep internal changes, or some efficiency tweaks.
On Fri, Jun 21, 2013 at 6:29 PM, Troels Nielsen wrote:
> The grammar conflict appears to be because of ambiguities in:
> 1. table_ref (used exclusively in FROM clauses)
> 2. index_elem (used exclusively in INDEX creation statements).
>
> Now, this doesn't seem to make much sense, as AFAICT window
On Mon, Jun 24, 2013 at 1:24 PM, Joshua D. Drake wrote:
> Leave your ego at the door. Josh is doing what could be considered one of
> the most thankless (public) jobs in this project. How about we support him
> in getting these patches taken care of instead of whining about the fact
> that he call
On 06/24/2013 10:59 AM, Andres Freund wrote:
On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell that "compiles & r
On 2013-06-22 14:32:46 +0300, Heikki Linnakangas wrote:
> Attached is a new version that fixes at least the problem I saw. Not sure if
> it fixes what you saw, but it's worth a try. How easily can you reproduce
> that?
Ok, I started to look at this:
* Could you document the way slots prevent chec
On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
>
> > The problem with that is that that HUGELY depends on the patch and the
> > review. There are patches where reviewers do a good percentage of the
> > work and others where they mostly tell that "compiles & runs".
>
> This project is enormously
> Because spending a year working on a feature isn't the same as spending
> an hour or day on it. And the proposal was to generally list them at the
> same level.
> At least the 9.3 release notes seem to list people that reviewed
> extensively prominently on the patches...
My proposal was to have
On 2013-06-24 14:48:32 -0300, Claudio Freire wrote:
> On Mon, Jun 24, 2013 at 2:41 PM, Andres Freund wrote:
> >> I don't like idea of sending gifts. I do like the idea of public thanks. We
> >> should put full recognition in the release notes for someone who reviews a
> >> patch. If they didn't re
On 06/24/2013 10:48 AM, Claudio Freire wrote:
Reviewer recognition should be on the same level as the submitter.
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell
> The problem with that is that that HUGELY depends on the patch and the
> review. There are patches where reviewers do a good percentage of the
> work and others where they mostly tell that "compiles & runs".
This project is enormously stingy with giving credit to people. It's
not like it costs
On Mon, Jun 24, 2013 at 2:41 PM, Andres Freund wrote:
>> I don't like idea of sending gifts. I do like the idea of public thanks. We
>> should put full recognition in the release notes for someone who reviews a
>> patch. If they didn't review the patch, the person that wrote the patch
>> would not
> Hrm, I'm on the slackers list, and I didn't see an email directed to
> me from JB in the last week about the CF.
Really? Hmmm. I'm going to send you a test email privately, please
verify whether or not you get it.
> Anyway, I am hoping to take at least one patch this CF, though the
> recent
On 24 June 2013 18:10, Josh Berkus wrote:
> I will be more than happy to resign as CFM and turn it over to someone
> else if people have a problem with it.
Please don't do that (until at least the end of the CF ;-) )
It's a difficult job and I'm happy you're doing it, though I suggest
an optima
On Mon, Jun 24, 2013 at 12:57 PM, Josh Berkus wrote:
> Actually, every submitter on that list -- including Maciej -- was sent a
> personal, private email a week ago. A few (3) chose to take the
> opportunity to review things, or promised to do so, including a brand
> new Chinese contributor who n
JD said:
> Leave your ego at the door. Josh is doing what could be considered one
> of the most thankless (public) jobs in this project. How about we
> support him in getting these patches taken care of instead of whining
> about the fact that he called us out for not doing our jobs (reviewing
> pa
On 06/18/2013 09:52 AM, Cédric Villemain wrote:
I've rebased the current set of pending patches I had, to fix pgxs and added 2
new patches.
Bugfixes have already been presented and sent in another thread, except the
last one which only fix comment in pgxs.mk.
The new feature consists in a new
On 2013-06-24 10:37:02 -0700, Joshua D. Drake wrote:
>
> On 06/24/2013 10:22 AM, Josh Berkus wrote:
>
> >Mind you, we wouldn't be able to reward a few reviewers, because they
> >live in countries to which it's impossible to ship from abroad.
> >
> >I have previously proposed that all of the revie
On Mon, Jun 24, 2013 at 2:22 PM, Josh Berkus wrote:
> I have previously proposed that all of the reviewers of a given
> PostgreSQL release be honored in the release notes as a positive
> incentive, and was denied on this from doing so. Not coincidentally, we
> don't seem to have any reviewers-at-
On 06/24/2013 10:22 AM, Josh Berkus wrote:
Mind you, we wouldn't be able to reward a few reviewers, because they
live in countries to which it's impossible to ship from abroad.
I have previously proposed that all of the reviewers of a given
PostgreSQL release be honored in the release notes as
On Thu, Jun 6, 2013 at 3:01 AM, Amit Kapila wrote:
> To avoid above 3 factors in test readings, I used below steps:
> 1. Initialize the database with scale factor such that database size +
> shared_buffers = RAM (shared_buffers = 1/4 of RAM).
>For example:
>Example -1
> if
On Mon, Jun 24, 2013 at 10:54 PM, Josh Berkus wrote:
>
>>> I will be more than happy to resign as CFM and turn it over to someone
>>> else if people have a problem with it.
>>
>> Heck, Josh. People have to be allowed to critize *a small part* of your
>> work without you understanding it as a funda
>> I will be more than happy to resign as CFM and turn it over to someone
>> else if people have a problem with it.
>
> Heck, Josh. People have to be allowed to critize *a small part* of your
> work without you understanding it as a fundamental request to step back
> from being CFM.
Criticize, y
On 06/24/2013 10:10 AM, Josh Berkus wrote:
On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
Josh Berkus writes:
patch. The vast majority chose not to respond to my email to them at
all. When private email fails, the next step is public email.
The only problem I have here is that I don't r
> Instead, I don't know, fetch some SPI money to offer a special poster or
> unique one-time-edition only hoodie or a signed mug or whatever to extra
> proficient contributors and turn that into a game people want to win.
I like that idea too. Provided that we allocate enough funding that I
can
On 2013-06-24 10:10:11 -0700, Josh Berkus wrote:
> On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
> > Josh Berkus writes:
> >> patch. The vast majority chose not to respond to my email to them at
> >> all. When private email fails, the next step is public email.
> >
> > The only problem I have
1 - 100 of 146 matches
Mail list logo
