On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote:
> Jeff Janes writes:
>> When I compile now without cassert, I get the compiler warning:
>
>> syncrep.c: In function 'SyncRepUpdateConfig':
>> syncrep.c:878:6: warning: variable 'parse_rc' set but not used
>> [-Wunused-but-set-variable]
Thanks for
On Mon, Apr 11, 2016 at 6:03 AM, Petr Jelinek wrote:
> On 10/04/16 20:47, Christian Ullrich wrote:
>>> don't think we need to be too precious about saving a byte or two
>>> here. Can one or other of you please prepare a replacement patch based
>>> in this discussion?
So, I am finally back on the
On Sat, Apr 9, 2016 at 1:47 AM, Andrew Dunstan wrote:
>
>
> On 04/08/2016 12:24 PM, Christian Ullrich wrote:
>>
>> * Tom Lane wrote:
>>
>>> +several. Grepping for compiler warnings, for example, is really painful
>>> right now on any MSVC critter. I've resorted to grepping for "warning
>>> C",
>
On 2016-04-10 09:03:37 +0300, Alexander Korotkov wrote:
> On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
> > On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund wrote:
> >
> >>
> >>
> >> On April 9, 2016 12:43:03 PM PDT, Andres Freund
> >> wrote:
> >> >On
On Mon, Apr 11, 2016 at 10:58 AM, Masahiko Sawada wrote:
> On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote:
>> Jeff Janes writes:
>>> When I compile now without cassert, I get the compiler warning:
>>
>>> syncrep.c: In function 'SyncRepUpdateConfig':
>>> syncrep.c:878:6: warning: variable 'parse
On 2016-04-10 16:08:56 -0700, Andres Freund wrote:
> On 2016-04-05 15:48:22 -0400, Robert Haas wrote:
> > On Fri, Mar 25, 2016 at 12:47 PM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote:
> > >>> Robert Haas writes:
> > It's stupid that we
On Mon, Apr 11, 2016 at 11:30 AM, Etsuro Fujita
wrote:
> I agree with Rushabh. Thanks for updating the patch!
Yes, not using a PG_TRY/CATCH block is better. We are not doing
anything that need to clean up PGresult in case of an unplanned
failure.
> Another thing I'd like to propose to revise th
On 2016-04-08 11:52:45 -0400, Robert Haas wrote:
> On Fri, Apr 8, 2016 at 11:00 AM, Andres Freund wrote:
> > I've finished polishing the Pin/Unpin patch. But the final polishing
> > happened on an intercontential flight, after days spent preparing my
> > move to SF. I'd be glad if you would allow
Andres Freund writes:
> I downloaded the RHEL6 srpm, and it appears to be patched to
> automatically disable pymalloc when running under valgrind (via
> disable-pymalloc-on-valgrind-py26.patch). That explains why you're
> seing the problem, but skink isn't (it's running debian).
Hah. I suspecte
On 2016/04/08 22:21, Rushabh Lathia wrote:
On Fri, Apr 8, 2016 at 6:28 PM, Robert Haas mailto:robertmh...@gmail.com>> wrote:
The comment just before the second hunk in the patch says:
* We don't use a PG_TRY block here, so be careful not to
throw error
* withou
On 2016-04-10 22:03:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-04-10 17:55:25 -0400, Tom Lane wrote:
> >> Hmm. It's true that I don't have the python debuginfo RPM installed.
> >> But this is a live bug, so I suspect you were too generous about
> >> those suppressions.
>
> > C
Andres Freund writes:
> On 2016-04-10 17:55:25 -0400, Tom Lane wrote:
>> Hmm. It's true that I don't have the python debuginfo RPM installed.
>> But this is a live bug, so I suspect you were too generous about
>> those suppressions.
> Could be - I just used the ones (after adapting for 32 vs. 64
On Sat, Apr 9, 2016 at 12:32 PM, Tom Lane wrote:
> Jeff Janes writes:
>> When I compile now without cassert, I get the compiler warning:
>
>> syncrep.c: In function 'SyncRepUpdateConfig':
>> syncrep.c:878:6: warning: variable 'parse_rc' set but not used
>> [-Wunused-but-set-variable]
>
> If there
On 2016-04-05 15:48:22 -0400, Robert Haas wrote:
> On Fri, Mar 25, 2016 at 12:47 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Fri, Mar 25, 2016 at 9:48 AM, Tom Lane wrote:
> >>> Robert Haas writes:
> It's stupid that we keep spending time and energy figuring out which
> shared
On Sun, Apr 10, 2016 at 10:01 AM, Pavel Stehule
wrote:
>
>
> 2016-04-10 18:49 GMT+02:00 David G. Johnston :
>
>> On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> 2016-04-10 17:49 GMT+02:00 David G. Johnston >> >:
>>>
On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule >>>
On 2016-04-10 17:55:25 -0400, Tom Lane wrote:
> Hmm. It's true that I don't have the python debuginfo RPM installed.
> But this is a live bug, so I suspect you were too generous about
> those suppressions.
Could be - I just used the ones (after adapting for 32 vs. 64 bit
issues) provided by upstr
Andres Freund writes:
> On 2016-04-10 17:10:57 -0400, Tom Lane wrote:
>> ... I'll be fixing this one
>> shortly, but now we have another puzzle: why isn't buildfarm member
>> skink seeing the same failure? It is running the plpython tests.
> I possible that it's hidden by the broad python error
On 2016-04-10 17:10:57 -0400, Tom Lane wrote:
> After failing at that, it occurred to me to try it under valgrind,
> and kaboom! I found a *different* bug, which has apparently been
> there a long time. (I say different because I don't see how this
> one could produce tick's symptoms; it's a refe
Buildfarm member tick failed today with what appears to be a bug
introduced by (or at least exposed by) the recent plpython ereport
patch. Presumably the fact that it's failing and no other critters are
has to do with its use of -DCLOBBER_CACHE_ALWAYS and/or
-DRANDOMIZE_ALLOCATED_MEMORY. However,
On 10/04/16 20:47, Christian Ullrich wrote:
* Andrew Dunstan:
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
I don't think that's good to use malloc in those code paths, and I
Oh?
+#if (_MSC_VER >= 1900)
+uint32cp;
+
+if (GetLocaleInfoEx(ctype,
+
On Sun, Apr 10, 2016 at 6:15 PM, Amit Kapila
wrote:
> On Sun, Apr 10, 2016 at 11:10 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Sun, Apr 10, 2016 at 7:26 AM, Amit Kapila
>> wrote:
>>
>>> On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund
>>> wrote:
>>>
On 2016-04-09 22
* Andrew Dunstan:
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
I don't think that's good to use malloc in those code paths, and I
Oh?
+#if (_MSC_VER >= 1900)
+ uint32 cp;
+
+ if (GetLocaleInfoEx(ctype,
+ LOCALE_IDEFAULTANSICO
On 04/10/2016 10:25 AM, Simon Riggs wrote:
On 9 April 2016 at 18:37, Tatsuo Ishii mailto:is...@postgresql.org>> wrote:
> But I still think it wouldn't move the patch any closer to committable
> state, because what it really needs is review whether the catalog
> definition makes sense
Hello,
On 04/09/2016 07:37 PM, Tatsuo Ishii wrote:
But I still think it wouldn't move the patch any closer to committable
state, because what it really needs is review whether the catalog
definition makes sense, whether it should be more like pg_statistic,
and so on. Only then it makes sense to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> broken that way as rowsecurity.sql, which is (still) creating roles
> >> named "alice" and "bob", but it's not acceptable like this.
>
> > Attached is a patch to fix all of the role usag
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> broken that way as rowsecurity.sql, which is (still) creating roles
>> named "alice" and "bob", but it's not acceptable like this.
> Attached is a patch to fix all of the role usage in rowsecurity.sql
> (I believe, feel free to let
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> broken that way as rowsecurity.sql, which is (still) creating roles
> named "alice" and "bob", but it's not acceptable like this.
Attached is a patch to fix all of the role usage in rowsecurity.sql
(I believe, feel free to let me know if there's anyth
Noah Misch writes:
> On Sat, Apr 09, 2016 at 10:08:01PM -0400, Tom Lane wrote:
>> Still, we've reached the most coverage this test can give us at 1000
>> rows, which still means it's wasting the last 99% of its runtime.
> If dropping the row count to 1000 shaves >500ms on your primary machine, +1
2016-04-10 18:49 GMT+02:00 David G. Johnston :
> On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
> wrote:
>
>>
>>
>> 2016-04-10 17:49 GMT+02:00 David G. Johnston
>> :
>>
>>> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
>>> wrote:
>>>
Hi
2016-03-21 22:13 GMT+01:00 Pavel Stehule :
On Sun, Apr 10, 2016 at 9:16 AM, Pavel Stehule
wrote:
>
>
> 2016-04-10 17:49 GMT+02:00 David G. Johnston :
>
>> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
>> wrote:
>>
>>> Hi
>>>
>>> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>>>
Hi
2016-03-21 21:24 GMT+01:00 Merlin Moncure :
2016-04-10 17:49 GMT+02:00 David G. Johnston :
> On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
> wrote:
>
>> Hi
>>
>> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>>
>>> Hi
>>>
>>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>>
Patch is trivial (see below), discussion is not :-).
I
On Sun, Apr 10, 2016 at 1:13 AM, Pavel Stehule
wrote:
> Hi
>
> 2016-03-21 22:13 GMT+01:00 Pavel Stehule :
>
>> Hi
>>
>> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>>
>>> Patch is trivial (see below), discussion is not :-).
>>>
>>> I see no useful reason to require INTO when returning data with
>
Tom Lane wrote:
> So I looked into this, and found that persuading psql to let backslash
> commands cross line boundaries is a much bigger deal than just fixing the
> lexer. The problem is that MainLoop would need to grow an understanding
> of having received only a partial backslash command and n
On 04/09/2016 08:43 AM, Christian Ullrich wrote:
Michael Paquier wrote:
On Sat, Apr 9, 2016 at 7:41 AM, Michael Paquier
wrote:
On Sat, Apr 9, 2016 at 1:46 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/08/2016 11:02 AM, Christian Ullrich wrote:
src/port/chklocale.c(233): war
Hi,
I realised a few days ago that the parallel aggregate code does not
cost for the combine, serialisation and deserialisation functions at
all.
I've attached a patch which fixes this.
One small point which I was a little unsure of in the attached is,
should the "if (aggref->aggdirectargs)" par
On Sun, Apr 10, 2016 at 11:10 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Apr 10, 2016 at 7:26 AM, Amit Kapila
> wrote:
>
>> On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund
>> wrote:
>>
>>> On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
>>> > There are results wi
On Sun, Apr 10, 2016 at 11:33 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund
>> wrote:
>>
>>>
>>>
>>> On April 9, 2016 12:43:03 PM PDT, Andre
On 9 April 2016 at 18:37, Tatsuo Ishii wrote:
> > But I still think it wouldn't move the patch any closer to committable
> > state, because what it really needs is review whether the catalog
> > definition makes sense, whether it should be more like pg_statistic,
> > and so on. Only then it makes
Hi
2016-03-21 22:13 GMT+01:00 Pavel Stehule :
> Hi
>
> 2016-03-21 21:24 GMT+01:00 Merlin Moncure :
>
>> Patch is trivial (see below), discussion is not :-).
>>
>> I see no useful reason to require INTO when returning data with
>> SELECT. However, requiring queries to indicate not needing data vi
39 matches
Mail list logo
