Re: [HACKERS] Causal reads take II

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

Re: [HACKERS] Adding support for Default partition in partitioning

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

Re: [HACKERS] On Complex Source Code Reading Strategy

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

Re: [HACKERS] pl/perl extension fails on Windows

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: >> >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

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 >

Re: [HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

> 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

[HACKERS] 10 beta docs: different replication solutions

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 ---

Re: [HACKERS] [BUGS] BUG #14759: insert into foreign data partitions fail

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

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

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

[HACKERS] Re: [BUGS] BUG #14758: Segfault with logical replication on a function index

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

Re: [HACKERS] segfault in HEAD when too many nested functions call

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 --

Re: [HACKERS] segfault in HEAD when too many nested functions call

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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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,

Re: [HACKERS] pl/perl extension fails on Windows

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

Re: [HACKERS] pl/perl extension fails on Windows

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 > >

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

"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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

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

[HACKERS] PostgreSQL not setting OpenSSL session id context?

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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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

[HACKERS] [GSOC][weekly report 8] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

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

Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

"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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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.

Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?

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

Re: [HACKERS] Page Scan Mode in Hash Index

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 >