On Tue, Dec 29, 2015 at 10:46 AM, Grzegorz Sampolski wrote:
> Hi.
> I thought link on commitfest to github url was sufficient.
> Sorry. Attached new patch.
I reviewed and tested the patch. With the addition of
new RHOST member to the passed items in the PAM
authentication doesn't have any impact
On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
> FWIW I'm considering implementing elog/ereport properly for the
> frontend. We've grown several hacks around that not being present, and
> I think those by now have a higher aggregate complexity than a proper
> implementation would have.
Th
On 2016-03-08 13:45:25 +0900, Michael Paquier wrote:
> On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
> > FWIW I'm considering implementing elog/ereport properly for the
> > frontend. We've grown several hacks around that not being present, and
> > I think those by now have a higher aggreg
On Tue, Mar 8, 2016 at 1:51 PM, Andres Freund wrote:
> On 2016-03-08 13:45:25 +0900, Michael Paquier wrote:
>> On Mon, Mar 7, 2016 at 10:26 AM, Andres Freund wrote:
>> > FWIW I'm considering implementing elog/ereport properly for the
>> > frontend. We've grown several hacks around that not being
Hello, Josh,
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh berkus>
> Crossing this over to pgsql-advocacy list where it really belongs.
> That's what that list is *for*.
>
> Especially since the discussion on -hackers has focused on ne
On Wed, Mar 2, 2016 at 2:04 PM, Michael Paquier
wrote:
> Here are a couple of ways to address this problem:
> 1) Remove the check before applying the delay
> 2) Increase recovery_min_apply_delay to a time that will allow even
> slow machines to see a difference. By experience with the other tests
On 2016-03-08 12:26:34 +0900, Michael Paquier wrote:
> On Tue, Mar 8, 2016 at 12:18 PM, Andres Freund wrote:
> > On 2016-03-08 12:01:18 +0900, Michael Paquier wrote:
> >> I have spent a couple of hours looking at that in details, and the
> >> patch is neat.
> >
> > Cool. Doing some more polishing
Hi,
On 2016-03-07 17:39:30 -0800, Andres Freund wrote:
> I'm setting up a buildfarm animal that runs under valgrind.
Which is now running as 'skink'. The first failed due to a missing trick
in the wrapper script, but the second one looks like it had a legit
issue:
http://pgbuildfarm.org/cgi-bin/s
Hi,
Per the new valgrind animal we get:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=skink&dt=2016-03-08%2004%3A22%3A00
2016-03-08 05:56:05.566 UTC [56de6971.723:5] LOG: statement: select
plperl_sum_array('{}');
==1827== Invalid write of size 4
==1827==at 0x14E35DD1: plperl_ref_from_pg_arr
On Mon, Feb 15, 2016 at 3:45 PM, Greg Stark wrote:
> I was thinking about this over the past couple weeks. I'm starting to
> think the quicksort runs gives at least the beginnings of a way
> forward on this front.
As I've already pointed out several times, I wrote a tool that makes
it easy to loa
On Tue, Mar 8, 2016 at 2:55 PM, Andres Freund wrote:
> On 2016-03-08 12:26:34 +0900, Michael Paquier wrote:
>> On Tue, Mar 8, 2016 at 12:18 PM, Andres Freund wrote:
>> > On 2016-03-08 12:01:18 +0900, Michael Paquier wrote:
>> >> I have spent a couple of hours looking at that in details, and the
>
Hi,
On 2016-03-08 16:21:45 +0900, Michael Paquier wrote:
> + durable_link_or_rename(tmppath, path, ERROR);
> + durable_rename(path, xlogfpath, ERROR);
> You may want to add a (void) cast in front of those calls for correctness.
"correctness"? This is neatnikism, not correctness. I've actual
Hello Andres,
Now I cannot see how having one context per table space would have a
significant negative performance impact.
The 'dirty data' etc. limits are global, not per block device. By having
several contexts with unflushed dirty data the total amount of dirty
data in the kernel increase
101 - 113 of 113 matches
Mail list logo
