On Sun, Jul 30, 2017 at 8:07 AM, Jeevan Ladhe
wrote:
> Hi Ashutosh,
>
> 0003 patch
>>
>> +parentRel = heap_open(parentOid, AccessExclusiveLock);
>> In [2], Amit Langote has given a reason as to why heap_drop_with_catalog()
>> should not heap_open() the parent relation. But this patch still
Hi Christoph,
On Mon, Jul 31, 2017 at 9:18 AM, Ashutosh Sharma wrote:
> Hi Christoph,
>
> On Mon, Jul 31, 2017 at 2:44 AM, Christoph Berg wrote:
>> Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
>>> Christoph Berg writes:
>>> > The plperl segfault on Debian's kfreebsd port I reported b
Hi all
I've been looking into the wait event set interface added in 9.6 with an
eye to using it in an extension that maintains a set of non-blocking libpq
connections to other PostgreSQL instances.
In the process I've been surprised to find that there does not appear to be
any interface to remove
On Sun, Jul 30, 2017 at 7:07 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I looked through the code of `synchronous-replay-v1.patch` a bit and ran a
> few
> tests. I didn't manage to break anything, except one mysterious error that
> I've
> got only once on one of my replicas, but I couldn't
On Sat, Jul 29, 2017 at 2:55 AM, Robert Haas wrote:
> On Fri, Jul 28, 2017 at 9:30 AM, Ashutosh Bapat
> wrote:
>> 0004 patch
>> The patch adds another column partdefid to catalog pg_partitioned_table. The
>> column gives OID of the default partition for a given partitioned table. This
>> means th
On Fri, Jul 28, 2017 at 6:23 AM, Craig Ringer wrote:
> On 28 July 2017 at 07:45, Tom Lane wrote:
>>
>> Peter Geoghegan writes:
>> > 2. Start somewhere. I have no idea where that should be, but it has to
>> > be some particular place that seems interesting to you.
>>
>> Don't forget to start with
Hi Christoph,
On Mon, Jul 31, 2017 at 2:44 AM, Christoph Berg wrote:
> Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
>> Christoph Berg writes:
>> > The plperl segfault on Debian's kfreebsd port I reported back in 2013
>> > is also still present:
>> > https://www.postgresql.org/message-
On Fri, Jul 14, 2017 at 3:02 AM, Ashutosh Bapat
wrote:
> Here's revised patch set with only 0004 revised. That patch deals with
> creating multi-level inheritance hierarchy from multi-level partition
> hierarchy. The original logic of recursively calling
> inheritance_planner()'s guts over the inh
> Attached patch looks good except the excessive tab stops:
> +
> # (change requires restart)
>
> I will commit/push this with removing the excessive tab stops if
> there's no objection.
Done. Each fix were pushed in sep
We don't seem to describe logical replication on
https://www.postgresql.org/docs/10/static/different-replication-solutions.html
The attached patch adds a section.
Steve
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 138bdf2..1329d1f 100644
--- a/
Thank you for weighing in and reviewing the patch.
On 2017/07/28 20:55, Etsuro Fujita wrote:
> On 2017/07/26 15:29, Amit Langote wrote:
>> On 2017/07/25 9:43, David G. Johnston wrote:
>>> On Mon, Jul 24, 2017 at 5:19 PM, Amit Langote wrote:
>>> I'm curious what the other limitations are...
>
> I
On Fri, Jul 28, 2017 at 1:13 PM, Masahiko Sawada wrote:
> On Thu, Jul 27, 2017 at 9:31 AM, Masahiko Sawada
> wrote:
>> On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote:
>>> On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada
>>> wrote:
> I think that either of the options you suggested no
Moved to -hackers.
On Sat, Jul 29, 2017 at 4:35 AM, Scott Milliken wrote:
> Thank you Masahiko! I've tested and confirmed that this patch fixes the
> problem.
>
Thank you for the testing. This issue should be added to the open item
since this cause of the server crash. I'll add it.
> On Fri, Ju
On 31/07/2017 01:47, Andres Freund wrote:
> Julien, could you quickly verify that everything's good for you now too?
>
I just checked on current HEAD
(cc9f08b6b813e30789100b6b34110d8be1090ba0) and everything's good for me.
Thanks!
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
--
S
Hi,
On 2017-07-29 16:14:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > [ 0002-Move-ExecProcNode-from-dispatch-to-function-pointer-.patch ]
>
> Here's a reviewed version of this patch.
Thanks! I pushed both now.
> I added dummy ExecProcNodeMtd functions to the various node types that
>
Just to continue the above, I can confirm that adding a simple call
to SSL_CTX_set_session_id_context() to be_tls_init() with some arbitrary
const value fixes the error for me. Attached is a patch (ideally a test
should be done for this, but that's beyond what I can invest at the moment,
let me kno
Hi Tom.
Again, I know little about this, but from what I understand PostgreSQL
wouldn't actually need to do/implement anything here - the session ticket
might be used only to abbreviate the SSL handshake (this would explain why
it's on by default without any application support). In other words, s
Christoph Berg writes:
> Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
>> Christoph Berg writes:
>>> The plperl segfault on Debian's kfreebsd port I reported back in 2013
>>> is also still present:
>> So it'd be interesting to know if it's any better with HEAD ...
> Unfortunately not:
Re: Tom Lane 2017-07-28 <3254.1501276...@sss.pgh.pa.us>
> Christoph Berg writes:
> > The plperl segfault on Debian's kfreebsd port I reported back in 2013
> > is also still present:
> > https://www.postgresql.org/message-id/20130515064201.GC704%40msgid.df7cb.de
> > https://buildd.debian.org/status
"Tels" writes:
> On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
>> Yeah, I looked into that. The closest candidate I can find is that
>> perl 5.10.1 contains Test::More 0.92. However, it's not real clear
>> to me exactly which files I'd need to pull out of 5.10.1 and inject into
>> an older tar
I wrote:
> I think what you need to do is tell SslStream not to expect that PG
> servers will do session resumption. (I'm a bit astonished that that
> would be its default assumption in the first place, but whatever.)
Actually, after a bit of further googling, it seems that the brain
damage here
Shay Rojansky writes:
> When trying to connect with Npgsql to PostgreSQL with client authentication
> (PG has ssl_ca_file set), the first connection works just fine. The second
> connection, however, fails and the PostgreSQL logs contain the message
> session id context uninitialized". This occurs
Dear hackers, a long-standing issue reported by users of the Npgsql .NET
driver for PostgreSQL may have its roots on the PostgreSQL side. I'm far
from being an SSL/OpenSSL expert so please be patient if the terms/analysis
are incorrect.
When trying to connect with Npgsql to PostgreSQL with client
Moin,
On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
> "Tels" writes:
>> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
So the question is, does anyone care? I wouldn't except that our
documentation appears to claim that we work with Perl "5.8 or later".
>
>> Not sure how often People
In the last week, I focused on tuning the performance of skip list and fixed
several bugs.
1. As only out-conflicts are checked in RWConflictExists, I removed all
modification concerned with in-conflicts;
2. If the conflict list is too short, I inserted an item just like inserting
into an ordere
Thanks for your reply.
Actually, the result of without "rdtsc" is reasonable. I used perf to analyze
the performance and found that
even thought the function tracking conflicts (RWConflictExists) was faster, the
function inserting conflicts (SetRWConflict)
was too slower. According to your sug
Noah Misch writes:
> On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
>> Well, OK, but I'd still like to tweak configure so that it records
>> an absolute path for prove rather than just setting PROVE=prove.
>> That way you'd at least be able to tell from the configure log
>> whether you
On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
> >> I think it'd be a good idea to insist that "prove" be in
> >> the same directory we found "perl" in.
>
> > Nah; on my machines, I use /usr/bin/perl and
"Tels" writes:
> On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
>>> So the question is, does anyone care? I wouldn't except that our
>>> documentation appears to claim that we work with Perl "5.8 or later".
> Not sure how often People use old Perl versions out in the field. I'd
> venture this is
Noah Misch writes:
> On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
>> I think it'd be a good idea to insist that "prove" be in
>> the same directory we found "perl" in.
> Nah; on my machines, I use /usr/bin/perl and ~/sw/cpan/bin/prove. The latter
> is built against the former, so th
On Sun, Jul 30, 2017 at 01:21:28AM -0400, Tom Lane wrote:
> I wrote:
> > So the question is, does anyone care? I wouldn't except that our
> > documentation appears to claim that we work with Perl "5.8 or later".
> > And the lack of field complaints suggests strongly that nobody else
> > cares. So
Moin Tom,
On Sun, July 30, 2017 1:21 am, Tom Lane wrote:
> I wrote:
>> So the question is, does anyone care? I wouldn't except that our
>> documentation appears to claim that we work with Perl "5.8 or later".
>> And the lack of field complaints suggests strongly that nobody else
>> cares. So I'm
Hi,
On Wed, May 10, 2017 at 2:28 PM, Ashutosh Sharma wrote:
> While doing the code coverage testing of v7 patch shared with - [1], I
> found that there are few lines of code in _hash_next() that are
> redundant and needs to be removed. I basically came to know this while
> testing the scenario wh
33 matches
Mail list logo
