On Wed, Jan 27, 2016 at 11:56 AM, Fujii Masao wrote:
> On Mon, Jan 25, 2016 at 4:03 PM, Jeff Janes wrote:
>> In reviewing one of my patches[1], Fujii-san has pointed out that I
>> didn't include checks for being in recovery, or for working on another
>> backend's temporary index.
>>
>> I think th
On Tue, Apr 19, 2016 at 8:44 PM, Robert Haas wrote:
>
> On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner
wrote:
> > On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila
wrote:
>
> >> It seems that for read-only workloads, MaintainOldSnapshotTimeMapping()
> >> takes EXCLUSIVE LWLock which seems to be a p
On Sun, Apr 17, 2016 at 1:22 AM, Magnus Hagander wrote:
> On Wed, Apr 13, 2016 at 4:07 AM, Noah Misch wrote:
>>
>> On Tue, Apr 12, 2016 at 10:08:23PM +0200, Magnus Hagander wrote:
>> > On Tue, Apr 12, 2016 at 8:39 AM, Noah Misch wrote:
>> > > On Mon, Apr 11, 2016 at 11:22:27AM +0200, Magnus Haga
On Wed, Apr 20, 2016 at 1:39 PM, Noah Misch wrote:
> On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote:
>> Michael Paquier wrote:
>> > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> > wrote:
>> > > Now, I have produced two patches:
>> > > - 0001-Support-for-VS-2015-locale-hack.p
* Michael Paquier wrote:
On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote:
Both patches behave exactly the same in this test. Of the 102 remaining
locales, I get an unexpected codepage for just four:
- kk: Expected 1251, used 1252
- kk-KZ: Expected 1251, used 1252
- sr: Expected 1251,
On Tue, Apr 19, 2016 at 02:42:24AM -0300, Alvaro Herrera wrote:
> Michael Paquier wrote:
> > On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
> > wrote:
> > > Now, I have produced two patches:
> > > - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
> > > __crt_locale_data_public in
On Mon, Apr 18, 2016 at 2:15 PM, Kyotaro HORIGUCHI
wrote:
> At Fri, 15 Apr 2016 17:36:57 +0900, Masahiko Sawada
> wrote in
>> >> How about if we do all the parsing stuff in temporary context and then
>> >> copy
>> >> the results using TopMemoryContext? I don't think it will be a leak in
>> >>
On Tue, Apr 19, 2016 at 06:31:34PM +0300, Yury Zhuravlev wrote:
> Now we generate tests for plpython3 of plpython2 tests. I think we should
> write independently 2 test suite.
> Why is that bad:
> 1. Differences between python2 and python3 more than can be solved by
> regexps. And these differences
On Sun, Apr 17, 2016 at 11:02:28PM -0400, Noah Misch wrote:
> On Tue, Apr 05, 2016 at 05:50:18PM -0400, Stephen Frost wrote:
> > I'll be doing more testing, review and clean-up (there are some
> > whitespace only changes in the later patches that really should be
> > included in the earlier patches
On Sun, Apr 17, 2016 at 10:01:36PM +0800, Craig Ringer wrote:
> I made an unfortunate oversight in the logical decoding timeline following
> code: it doesn't work for logical decoding from the walsender, because I
> left the glue code required out of the final cut of the patch.
> Subject: [PATCH]
On Sun, Apr 17, 2016 at 10:22:24AM -0400, Tom Lane wrote:
> David Rowley writes:
> > On 16 April 2016 at 04:27, Tom Lane wrote:
> >> +1 for the latter, if we can do it conveniently. I think exposing
> >> the names of the aggregate implementation functions would be very
> >> user-unfriendly, as n
I had the possibility to perform tests on 9.5, and can confirm the
memory leak I was seeing is solved with the patch (and that's great :) )
Regards
Marc
On 18/04/2016 17:53, Julien Rouhaud wrote:
> On 18/04/2016 16:33, Tom Lane wrote:
>> I poked at this over the weekend, and got more unhappy t
On Tue, Apr 19, 2016 at 04:06:55PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > Peter Geoghegan wrote:
> >> I would have appreciated more scope to say how confident I am in
> >> my prediction, and how scary in absolute terms I consider the
> >> scariest patches to be.
>
> > It was purposef
On Sat, Apr 16, 2016 at 06:22:47PM +0200, Magnus Hagander wrote:
> > On Tue, Apr 12, 2016 at 10:08:23PM +0200, Magnus Hagander wrote:
> > > I won't have time to do the bigger rewrite/reordeirng by then, but I can
> > > certainly commit to having the smaller updates done to cover the new
> > > funct
On Wed, Apr 20, 2016 at 1:48 AM, Christian Ullrich wrote:
> Both patches behave exactly the same in this test. Of the 102 remaining
> locales, I get an unexpected codepage for just four:
>
> - kk: Expected 1251, used 1252
> - kk-KZ: Expected 1251, used 1252
> - sr: Expected 1251, used 1250
> - uk:
On Tue, Apr 19, 2016 at 12:37 PM, Alvaro Herrera
wrote:
> This guy reads my mind. Where's my tinfoil hat?
Heh. Well, I'm generally not in favor of communicating concerns
without an obligation to defend them, but it could work well in tiny
doses. Offering hackers a low-risk way to take a position
Dean Rasheed writes:
> On 19 April 2016 at 14:38, Tom Lane wrote:
>> Yeah, what I was thinking of printing is something like
>>
>> asind(x),
>> asind(x) IN (-90,-30,0,30,90) AS asind_exact,
>> ...
>>
>> with extra_float_digits=3.
> OK, that sounds like it would be a useful improvement to the t
Alvaro Herrera writes:
> Peter Geoghegan wrote:
>> I would have appreciated more scope to say how confident I am in my
>> prediction, and how scary in absolute terms I consider the scariest
>> patches to be.
> It was purposefully ambiguous. Maybe it should have been stated
> explicitely.
I was
Peter Geoghegan wrote:
> On Mon, Apr 18, 2016 at 1:22 PM, Josh berkus wrote:
> > We should send the owner of the scariest patch something as a prize.
> > Maybe a plastic skeleton or something ...
>
> I think it was a good idea to call it the scariest patch rather than
> something more severe soun
On Mon, Apr 18, 2016 at 1:22 PM, Josh berkus wrote:
> We should send the owner of the scariest patch something as a prize.
> Maybe a plastic skeleton or something ...
I think it was a good idea to call it the scariest patch rather than
something more severe sounding. Having the poll only be half-
Andres Freund wrote:
> I've actually changed course a bit and I'm trying something different: A
> two level structure. One hashtable that maps (RelFileNode, ForkNumber)
> to a 'open relation' data structure, and from there a radix tree over
> just the block number. To avoid having to look up in th
2016-04-19 12:49 GMT+02:00 Simon Riggs :
> On 12 April 2016 at 06:51, Tom Lane wrote:
>
>> Craig Ringer writes:
>> > The other area where there's room for extension without throwing out the
>> > whole thing and rebuilding is handling of new top-level statements. We
>> can
>> > probably dispatch
Kevin Grittner wrote:
> On Tue, Apr 19, 2016 at 11:02 AM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >
> >> That wouldn't have fixed my problem, which involved rebasing a patch.
> >
> > True. I note that it's possible to munge a patch mechanically to sort
> > out this situation.
>
> I adm
On Tue, Apr 19, 2016 at 11:02 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>> On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote:
>
Since this change to BufferGetPage() has caused severe back-patch
pain for at least two committers so far, I will revert that (very
recent) change
* Alvaro Herrera wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
hack, though I am co
Andres Freund wrote:
> On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote:
> > > Since this change to BufferGetPage() has caused severe back-patch
> > > pain for at least two committers so far, I will revert that (very
> > > recent) change to this patch later today unless I hear an
> > > objection
> On 12 Apr 2016, at 07:36, Arcadiy Ivanov wrote:
>
> [
> DISTRIBUTE BY { REPLICATION | ROUNDROBIN | { [HASH | MODULO ] ( column_name
> ) } } |
> DISTRIBUTED { { BY ( column_name ) } | { RANDOMLY } |
> DISTSTYLE { EVEN | KEY | ALL } DISTKEY ( column_name )
> ]
> [ TO { GROUP groupname | N
Hello.
Now we generate tests for plpython3 of plpython2 tests. I think we should
write independently 2 test suite.
Why is that bad:
1. Differences between python2 and python3 more than can be solved by
regexps. And these differences are growing.
2. We must be careful to write tests, so as not t
On 19 April 2016 at 14:38, Tom Lane wrote:
> Yeah, what I was thinking of printing is something like
>
> asind(x),
> asind(x) IN (-90,-30,0,30,90) AS asind_exact,
> ...
>
> with extra_float_digits=3. The point of this is not necessarily to give
> any extra information, tho
On Tue, Apr 19, 2016 at 10:14 AM, Robert Haas wrote:
> On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote:
>> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
>>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> That i
On Tue, Apr 19, 2016 at 11:11 AM, Kevin Grittner wrote:
> On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
>> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>>>
>>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
>>> > That is more controversial than the potential ~2% regression for
>>
On Tue, Apr 19, 2016 at 11:03 AM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote:
>>
>> > The right thing to do about that is just change it back to the
>> > way Kevin had it originally.
>>
>> Since this change to BufferGetPage() has caused sev
On Tue, Apr 19, 2016 at 9:57 AM, Amit Kapila wrote:
> On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>>
>> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
>> > That is more controversial than the potential ~2% regression for
>> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay
On 2016-04-19 12:03:22 -0300, Alvaro Herrera wrote:
> Kevin Grittner wrote:
> > On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote:
> >
> > > The right thing to do about that is just change it back to the
> > > way Kevin had it originally.
> >
> > Since this change to BufferGetPage() has caused
Kevin Grittner wrote:
> On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote:
>
> > The right thing to do about that is just change it back to the
> > way Kevin had it originally.
>
> Since this change to BufferGetPage() has caused severe back-patch
> pain for at least two committers so far, I wil
On Sun, Apr 17, 2016 at 2:26 AM, Andres Freund wrote:
>
> On 2016-04-16 16:44:52 -0400, Noah Misch wrote:
> > That is more controversial than the potential ~2% regression for
> > old_snapshot_threshold=-1. Alvaro[2] and Robert[3] are okay releasing
> > that way, and Andres[4] is not.
>
> FWIW, I
> On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote:
> > Can we guarantee that extensions don't conflict? In fact we can
> > since we already do it. If all tests pass there is no conflict.
>
> How does that follow? Even if you were to test all possible extensions
> together - obviously not p
Hi Idlar, Alexander,
On Tue, Apr 19, 2016 at 11:26 PM, Alexander Korotkov
wrote:
> On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote:
>>
>> Thanks for your new patch! I've tried it and discovered some strange
>> behavior for partitioning by composite key. Here is an example of my setup:
>>
>> c
On Tue, Apr 19, 2016 at 6:38 AM, Robert Haas wrote:
> The right thing to do about that is just change it back to the
> way Kevin had it originally.
Since this change to BufferGetPage() has caused severe back-patch
pain for at least two committers so far, I will revert that (very
recent) change t
On Tue, Apr 19, 2016 at 4:57 PM, Ildar Musin wrote:
> On 15.04.2016 07:35, Amit Langote wrote:
>
>> Thanks a lot for the comments. The patch set changed quite a bit since
>> the last version. Once the CF entry was marked returned with feedback on
>> March 22, I held off sending the new version at
Tests:
create table mytab(x int,x1 char(9),x2 varchar(9));
create table mytab1(y int,y1 char(9),y2 varchar(9));
insert into mytab values (generate_series(1,5),'aa','aaa');
insert into mytab1 values (generate_series(1,1),'aa','aaa');
insert into mytab values (generate_series(1,50),'aa','
On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote:
> Can we guarantee that extensions don't conflict? In fact we can since
> we already do it. If all tests pass there is no conflict.
How does that follow? Even if you were to test all possible extensions
together - obviously not possible - ho
On 2016-04-19 15:32:07 +0300, Aleksander Alekseev wrote:
> > As Tom says, we can't easily break it down into multiple co-operating
> > pieces, so lets forget that as unworkable.
>
> I'm sorry but didn't I just demonstrate the opposite?
I doubt it.
> If so it's very
> easy to prove - give a count
Hi Amit,
On 15.04.2016 07:35, Amit Langote wrote:
Thanks a lot for the comments. The patch set changed quite a bit since
the last version. Once the CF entry was marked returned with feedback
on March 22, I held off sending the new version at all. Perhaps, it
would have been OK. Anyway here it
Dean Rasheed writes:
> On 19 April 2016 at 05:16, Noah Misch wrote:
>> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>>> Hm? The expected answer is exact (30, 45, or whatever) in each case.
>>> If we get some residual low-order digits then it's a failure, so we don't
>>> need to worr
On 04/18/2016 04:22 PM, Josh berkus wrote:
>
> We should send the owner of the scariest patch something as a prize.
> Maybe a plastic skeleton or something ...
A mouse.
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
> As Tom says, we can't easily break it down into multiple co-operating
> pieces, so lets forget that as unworkable.
I'm sorry but didn't I just demonstrate the opposite? If so it's very
easy to prove - give a counterexample. As I understand approach I
described handles cases named by Tom just fin
On Tue, Apr 19, 2016 at 1:49 PM, Simon Riggs wrote:
> On 12 April 2016 at 06:51, Tom Lane wrote:
>
>> Craig Ringer writes:
>> > The other area where there's room for extension without throwing out the
>> > whole thing and rebuilding is handling of new top-level statements. We
>> can
>> > probab
On 04/19/2016 01:47 AM, Michael Paquier wrote:
On Tue, Apr 19, 2016 at 2:42 PM, Alvaro Herrera
wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
wrote:
Now, I have produced two patches:
- 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
__crt_loca
On Tue, Apr 19, 2016 at 1:23 AM, Michael Paquier
wrote:
> On Tue, Apr 19, 2016 at 3:14 AM, Tom Lane wrote:
>> Or in short: this is a whole lot further than I'm prepared to go to
>> satisfy one customer with a badly-designed application. And from what
>> I can tell from the Feb 2015 discussion, t
On 12 April 2016 at 06:51, Tom Lane wrote:
> Craig Ringer writes:
> > The other area where there's room for extension without throwing out the
> > whole thing and rebuilding is handling of new top-level statements. We
> can
> > probably dispatch the statement text to a sub-parser provided by an
Hello, Alvaro.
> Some people have already heard about this.
Yes, we did :) Nice job!
> * Should we run something other than "make check-world" As far as I
> know, that covers all or almost all the tests we have; are there
> things that we should have and are not running? If so, how do we go
>
Hi,
On 04/16/2016 04:15 PM, Kevin Grittner wrote:
There is a paper that any one interested in performance at high
concurrency, especially in Linux, should read[1]. While doing
other work, a group of researchers saw behavior that they suspected
was due to scheduler bugs in Linux. There were no
> no - it is not possible. Not with Bison parser - it cannot work with
> unknown syntax - so isn't possible implement one part by parser A, and
> second part by parser B.
>
> But we can parsers P1 and P2. P1 knows string XX, P2 knows YY. Buildin
> parser (BP) knows SQL
>
> We can have registered
On 19 April 2016 at 05:16, Noah Misch wrote:
> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
>> >> We could alternatively set extra_float_digits to its max value and hope
>> >> that off-by-one-in-the-
On Mon, Apr 18, 2016 at 4:48 PM, Michael Paquier
wrote:
> Another, perhaps, better idea is to add some more extra logic to
> pg_conn as follows:
> boolis_emergency;
> PGresult *emergency_result;
> boolis_emergency_consumed;
> So as when an OOM shows up, is_emergency is set to true. Then a
56 matches
Mail list logo