Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On 2017-03-23 20:35:09 +1300, Thomas Munro wrote: > Here is a new patch series responding to feedback from Peter and Andres: Here's a review of 0007 & 0010 together - they're going to have to be applied together anyway... diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index

Re: [HACKERS] Speedup twophase transactions

Please ignore reports about errors in other tests. Seem spurious.. Regards, Nikhils On 28 March 2017 at 10:40, Nikhil Sontakke wrote: > Hi Micheal, > > The latest patch looks good. By now doing a single scan of shmem two phase > data, we have removed the double loops

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Okay. I got the message, and I agree with what you say here. You are right > by the way, the error messages just use "two-phase file" and not "two-phase > STATE file", missed that previously. > -- Thanks, marked as ready for committer, as

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Mon, Mar 27, 2017 at 11:21 AM, Amit Kapila wrote: > I think we can't change the number of buckets to be created or lowmask > and highmask calculation here without modifying _h_spoolinit() because > it sorts the data to be inserted based on hashkey which in turn >

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Tue, Mar 28, 2017 at 1:33 PM, Tsunakawa, Takayuki wrote: > I get the impression that DATA_CORRUPTED means the table data is corrupted, > because there's an error code named INDEX_CORRUPTED. I have interpreted that as the other way around, aka DATA_CORRUPTED

Re: [HACKERS] Speedup twophase transactions

Hi Micheal, The latest patch looks good. By now doing a single scan of shmem two phase data, we have removed the double loops in all the affected functions which is good. My only question is if the added call to restoreTwoPhaseData() is good enough to handle all the 3 functions

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Thanks Craig and Michael for confirming that "PQsetSingleRowMode" should be called right after "PQbatchQueueProcess". Michael Paquier wrote: > It seems to me that >this should also be effective only during the fetching of one single >result set. When the client moves on to the next item in the

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Mar 28, 2017 at 3:40 PM, Haribabu Kommi wrote: > > update patch attached. > Forgot to execute git commit, new patch attached. Regards, Hari Babu Fujitsu Australia pg_stat_walwrites_view_4.patch Description: Binary data -- Sent via pgsql-hackers mailing

Re: [HACKERS] pg_stat_wal_write statistics view

On Mon, Mar 27, 2017 at 1:27 PM, Haribabu Kommi wrote: > > > On Sat, Mar 25, 2017 at 6:40 AM, Fujii Masao > wrote: > >> On Wed, Feb 15, 2017 at 12:53 PM, Haribabu Kommi >> wrote: >> > >> > >> > On Wed, Feb 8, 2017 at

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > While I agree with that in general, we are taking about 2PC files that are > on disk in patch 0001, so I would think that in this case > ERRCODE_DATA_CORRUPTED is the most adapted

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 03/27/2017 01:40 PM, Rushabh Lathia wrote: ... I was doing more testing with the patch and I found one more server crash with the patch around same area, when we forced the gather merge for the scan having zero rows. create table dept ( deptno numeric, dname varchar(20); set

Re: [HACKERS] free space map and visibility map

I'd like to have a comment from Heikki or Tom. At Mon, 27 Mar 2017 16:49:08 +0900, Masahiko Sawada wrote in > On Mon, Mar 27, 2017 at 2:38 PM, Kyotaro HORIGUCHI > wrote:

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 03/27/2017 05:51 PM, Robert Haas wrote: On Mon, Mar 27, 2017 at 9:54 AM, Tom Lane wrote: Robert Haas writes: On Mon, Mar 27, 2017 at 1:29 AM, Rushabh Lathia wrote: But it seems a bit futile to produce the parallel

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

On Mon, Mar 27, 2017 at 5:54 PM, Robert Haas wrote: > > If it's just that they are relying on unsynchronized global variables, > then it's sufficient to mark them parallel-restricted ('r'). Do we > really need to go all the way to parallel-unsafe ('u')? > Done. --

Re: [HACKERS] O(1) DSM handle operations

On Tue, Mar 28, 2017 at 3:52 PM, Robert Haas wrote: > On Mon, Mar 27, 2017 at 5:13 PM, Thomas Munro > wrote: >> This is just a thought for discussion, no patch attached... >> >> DSM operations dsm_create(), dsm_attach(), dsm_unpin_segment()

Re: [HACKERS] logical decoding of two-phase transactions

On 28 March 2017 at 10:53, Craig Ringer wrote: > However, even once I add an option to force decoding of 2pc xacts with > catalog changes to test_decoding, I cannot reproduce the expected > locking issues so far. See tests in attached updated version, in >

Re: [HACKERS] logical replication launcher crash on buildfarm

On 28/03/17 04:46, Robert Haas wrote: > On Mon, Mar 27, 2017 at 10:04 PM, Andres Freund wrote: >>> Btw now that I look at the code, I guess we'll want to get rid of >>> bgw_main completely in HEAD given that we can't guarantee it will be >>> valid even for

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Mon, Mar 27, 2017 at 4:45 PM, Amit Kapila wrote: > On Sat, Mar 25, 2017 at 1:24 PM, Amit Kapila > wrote: > > On Fri, Mar 24, 2017 at 11:49 PM, Pavan Deolasee > > wrote: > >> > >> On Fri, Mar 24, 2017 at 6:46 PM,

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kang Yuzhe > 1. Prepare Hands-on with PG internals > > > For example, a complete Hands-on with SELECT/INSERT SQL Standard PG > internals. The point is the experts can pick one fairly complex

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 28, 2017 at 08:04:34AM +0530, Pavan Deolasee wrote: > And I've answered it so many times by now :-)  LOL > Just to add more to what I just said in another email, note that HOT/WARM > chains are created when a new root line pointer is created in the heap (a line > pointer that has an

Re: [HACKERS] logical decoding of two-phase transactions

On 28 March 2017 at 09:25, Andres Freund wrote: > If you actually need separate decoding of 2PC, then you want to wait for > the PREPARE to be replicated. If that replication has to wait for the > to-be-replicated prepared transaction to commit prepared, and commit > prepare

Re: [HACKERS] logical replication launcher crash on buildfarm

Robert Haas writes: > I wasn't thinking of introducing bgw_builtin_id. My idea was just > along the lines of > if (bgw_library_name == NULL && bgw_function_name != NULL) > { > if (strcmp(bgw_function_name, "ParallelQueryMain") == 0) >ParallelQueryMain(blah); >

Re: [HACKERS] O(1) DSM handle operations

On Mon, Mar 27, 2017 at 5:13 PM, Thomas Munro wrote: > This is just a thought for discussion, no patch attached... > > DSM operations dsm_create(), dsm_attach(), dsm_unpin_segment() perform > linear searches of the dsm_control->item array for either a free slot > or

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Mon, Mar 27, 2017 at 11:20 PM, Tom Lane wrote: > Alexander Korotkov writes: >> On Mon, Mar 27, 2017 at 4:48 PM, Tom Lane wrote: >>> Actually, the *real* problem with that coding is it lacks a SQLSTATE >>> (errcode call). The

Re: [HACKERS] standardized backwards incompatibility tag for commits

On Sat, Mar 25, 2017 at 04:15:39PM -0400, Tom Lane wrote: > Andres Freund writes: > > Seems like it'd be good to standardize how we're declaring that a commit > > contains backwards incompatible changes. I've seen > > - 'BACKWARDS INCOMPATIBLE CHANGE' > > - 'BACKWARD

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > "Tsunakawa, Takayuki" writes: > > All other places in twophase.c and most places in other files put ereport() > and errmsg() on separate lines. I think

Re: [HACKERS] logical replication launcher crash on buildfarm

On Mon, Mar 27, 2017 at 10:04 PM, Andres Freund wrote: >> Btw now that I look at the code, I guess we'll want to get rid of >> bgw_main completely in HEAD given that we can't guarantee it will be >> valid even for shared_preload_library libraries. For older branches I >> would

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 03:30:28 +0100, Simon Riggs wrote: > On 28 March 2017 at 02:25, Andres Freund wrote: > > On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: > >> > >> > On 28 Mar 2017, at 00:25, Andres Freund wrote: > >> > > >> > Hi, > >> > > >> > On

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 28, 2017 at 7:49 AM, Bruce Momjian wrote: > On Mon, Mar 27, 2017 at 04:29:56PM -0400, Robert Haas wrote: > > On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee > > wrote: > > > It's quite hard to say that until we see many more benchmarks. As

Re: [HACKERS] logical decoding of two-phase transactions

On 28 March 2017 at 02:25, Andres Freund wrote: > On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: >> >> > On 28 Mar 2017, at 00:25, Andres Freund wrote: >> > >> > Hi, >> > >> > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: >> >> Ok, here it is. >> >

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 28, 2017 at 1:59 AM, Robert Haas wrote: > On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee > wrote: > > It's quite hard to say that until we see many more benchmarks. As author > of > > the patch, I might have got repetitive with my

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Mon, Mar 27, 2017 at 04:29:56PM -0400, Robert Haas wrote: > On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee > wrote: > > It's quite hard to say that until we see many more benchmarks. As author of > > the patch, I might have got repetitive with my benchmarks. But I've

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 28, 2017 at 1:32 AM, Alvaro Herrera wrote: > Is the WARM tap test suite supposed to work when applied without all the > other patches? I just tried applied that one and running "make check -C > src/test/modules", and it seems to hang after giving "ok 5" for

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-28 03:47:50 +0200, Petr Jelinek wrote: > On 28/03/17 03:31, Petr Jelinek wrote: > > On 27/03/17 19:01, Robert Haas wrote: > >> On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund wrote: > >>> Robert, Petr, either of you planning to fix this (as outlined elsewhere > >>>

Re: [HACKERS] parallelize queries containing initplans

On Thu, Mar 16, 2017 at 2:34 AM, Kuntal Ghosh wrote: > On Tue, Mar 14, 2017 at 3:20 PM, Amit Kapila wrote: >> Based on that idea, I have modified the patch such that it will >> compute the set of initplans Params that are required below gather

Re: [HACKERS] logical replication launcher crash on buildfarm

On 28/03/17 03:31, Petr Jelinek wrote: > On 27/03/17 19:01, Robert Haas wrote: >> On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund wrote: >>> Robert, Petr, either of you planning to fix this (as outlined elsewhere >>> in the thred)? >> >> Oh, I didn't realize anybody was

Re: [HACKERS] Potential data loss of 2PC files

On Tue, Mar 28, 2017 at 9:37 AM, Michael Paquier wrote: > On Tue, Mar 28, 2017 at 8:38 AM, Tsunakawa, Takayuki > wrote: >> From: pgsql-hackers-ow...@postgresql.org >>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael

Re: [HACKERS] logical replication launcher crash on buildfarm

On 27/03/17 19:01, Robert Haas wrote: > On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund wrote: >> Robert, Petr, either of you planning to fix this (as outlined elsewhere >> in the thred)? > > Oh, I didn't realize anybody was looking to me to fix this. I sort of > thought

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: > > > On 28 Mar 2017, at 00:25, Andres Freund wrote: > > > > Hi, > > > > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: > >> Ok, here it is. > > > > On a very quick skim, this doesn't seem to solve the issues around > >

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

On Mar 28, 2017 00:00, "Andreas Seltenreich" wrote: Ashutosh Sharma writes: >> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*) (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397) > Thanks for reporting this problem. Could you please let me know on for > how long

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:25, Andres Freund wrote: > > Hi, > > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: >> Ok, here it is. > > On a very quick skim, this doesn't seem to solve the issues around > deadlocks of prepared transactions vs. catalog tables. What if the >

Re: [HACKERS] [POC] hash partitioning

> Please post an explanation for the delay and a schedule for the new > patch. If no patch or explanation is posted by 2017-03-17 AoE I will > mark this submission "Returned with Feedback". Depite the fact that Yugo has posted a new patch on 2017-03-17, this item had been marked as "Returned

Re: [HACKERS] segfault in hot standby for hash indexes

On Mar 27, 2017 22:25, "Robert Haas" wrote: On Fri, Mar 24, 2017 at 3:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma wrote: >>> >>> I think it would have been probably okay to use *int* for

Re: [HACKERS] Partitioned tables and relfilenode

Hi, On 2017/03/28 0:13, Maksim Milyutin wrote: > On 24.03.2017 03:54, Amit Langote wrote: >> >> And here is the updated patch. >> > > Perhaps you forgot my fix in the updated patch > > diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c > index 3999e6e..36917c8 100644 > ---

Re: [HACKERS] [COMMITTERS] pgsql: Clean up Perl code according to perlcritic

I wrote: > Peter Eisentraut writes: >> Clean up Perl code according to perlcritic > This seems to have broken the regression tests (specifically, dblink) > on at least some of the Windows buildfarm critters. I'm hardly a Perl expert, but it looks to me like the culprit is this

Re: [HACKERS] Bug in get_partition_for_tuple

On 2017/03/27 23:54, Robert Haas wrote: > On Wed, Mar 22, 2017 at 4:00 AM, Amit Langote > wrote: >>> You're right, fixed that in the attached updated patch. >> >> Added this to the partitioning open items list, to avoid being forgotten >> about. >> >>

Re: [HACKERS] Partitioning vs ON CONFLICT

On 2017/03/27 23:40, Robert Haas wrote: > On Thu, Mar 9, 2017 at 7:20 PM, Amit Langote > wrote: >> On 2017/03/10 9:10, Amit Langote wrote: >>> On 2017/03/09 23:25, Robert Haas wrote: On Fri, Feb 17, 2017 at 1:47 AM, Amit Langote wrote: > I updated the

Re: [HACKERS] logical decoding of two-phase transactions

On 28 March 2017 at 08:50, Stas Kelvich wrote: > >> On 28 Mar 2017, at 00:19, Stas Kelvich wrote: >> >> * It is actually doesn’t pass one of mine regression tests. I’ve added >> expected output >> as it should be. I’ll try to send follow up

Re: [HACKERS] logical decoding of two-phase transactions

On 28 March 2017 at 05:25, Andres Freund wrote: > On a very quick skim, this doesn't seem to solve the issues around > deadlocks of prepared transactions vs. catalog tables. What if the > prepared transaction contains something like LOCK pg_class; (there's a > lot more

Re: [HACKERS] logical decoding of two-phase transactions

> On 28 Mar 2017, at 00:19, Stas Kelvich wrote: > > * It is actually doesn’t pass one of mine regression tests. I’ve added > expected output > as it should be. I’ll try to send follow up message with fix, but right now > sending it > as is, as you asked. > >

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

On Mon, Mar 27, 2017 at 8:24 PM, Tom Lane wrote: > > Pushed with minor adjustments. > Excellent - thanks for your review and all the discussion here! > The main non-cosmetic thing I did was to replace the floor(log10()) > business with plain constant "10" as I suggested

Re: [HACKERS] Potential data loss of 2PC files

On Tue, Mar 28, 2017 at 8:38 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier >> Do you think that this qualifies as a bug fix for a backpatch? I would think >> so,

[HACKERS] Failed with build PostgreSQL in Windows ("--with-perl" option)

Hi, We have trying to build PostgreSQL in Windows Environment. When build with options "--with-perl" (by setting config.pl file), Builder not found "perl\d+.lib" file in "C:\Perl\lib\CORE\" folder, so it ended with the messages bellow. "could not identify perl library version: at

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Lukas Fittl writes: > On Sat, Mar 18, 2017 at 12:46 PM, Tom Lane wrote: >> So it turns out this discussion just reinvented the alternative that >> Lukas had in his 0002 proposal. Are there any remaining objections >> to proceeding with that approach? >

Re: [HACKERS] Potential data loss of 2PC files

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Do you think that this qualifies as a bug fix for a backpatch? I would think > so, but I would not mind waiting for some dust to be on it before considering > applying that on

Re: [HACKERS] Potential data loss of 2PC files

On Tue, Mar 28, 2017 at 1:34 AM, Teodor Sigaev wrote: > Thank you, pushed. Thanks! Do you think that this qualifies as a bug fix for a backpatch? I would think so, but I would not mind waiting for some dust to be on it before considering applying that on back-branches.

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

Pavel, Craig and Stas, Thank you for your responses and valuable comments! I have written draft proposal https://docs.google.com/document/d/1Y4mc_PCvRTjLsae-_fhevYfepv4sxaqwhOo4rlxvK1c/edit It seems that

Re: [HACKERS] [COMMITTERS] pgsql: Clean up Perl code according to perlcritic

Peter Eisentraut writes: > Clean up Perl code according to perlcritic This seems to have broken the regression tests (specifically, dblink) on at least some of the Windows buildfarm critters. It looks like something got changed in the behavior of build-tree path expansion: this

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

0001+0002 patch primarily for ease of review. will be following with a single v28 patch shortly. Applies cleanly. Make check ok. I think it behaves as committers required last. Let us try again with them... -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] logical decoding of two-phase transactions

Hi, On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: > Ok, here it is. On a very quick skim, this doesn't seem to solve the issues around deadlocks of prepared transactions vs. catalog tables. What if the prepared transaction contains something like LOCK pg_class; (there's a lot more realistic

Re: [HACKERS] logical decoding of two-phase transactions

> On 27 Mar 2017, at 16:29, Craig Ringer wrote: > > On 27 March 2017 at 17:53, Stas Kelvich wrote: > >> I’m heavily underestimated amount of changes there, but almost finished >> and will send updated patch in several hours. > > Oh, brilliant!

[HACKERS] O(1) DSM handle operations

Hi hackers, This is just a thought for discussion, no patch attached... DSM operations dsm_create(), dsm_attach(), dsm_unpin_segment() perform linear searches of the dsm_control->item array for either a free slot or a slot matching a given handle. Maybe no one thinks this is a problem, because

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Thu, Mar 23, 2017 at 2:47 PM, Pavan Deolasee wrote: > It's quite hard to say that until we see many more benchmarks. As author of > the patch, I might have got repetitive with my benchmarks. But I've seen > over 50% improvement in TPS even without chain conversion (6

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Is the WARM tap test suite supposed to work when applied without all the other patches? I just tried applied that one and running "make check -C src/test/modules", and it seems to hang after giving "ok 5" for t/002_warm_stress.pl. (I had to add a Makefile too, attached.) -- Álvaro Herrera

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > 0001+0002 patch primarily for ease of review. will be following with a > single v28 patch shortly. > 0001-psql-if-v28.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

On Mon, Mar 27, 2017 at 3:25 PM, Fabien COELHO wrote: > > And here you go >> > > Patch applies cleany, make check ok. Looks pretty good. > > A minor detail I have just noticed, sorry: now that options are discarded > by functions, some string variable declarations should be

Re: [HACKERS] increasing the default WAL segment size

Hello, On Sat, Mar 25, 2017 at 10:32 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > At this point, I suggest splitting this patch up into several > potentially less controversial pieces. > > One big piece is that we currently don't support segment sizes larger > than 64 GB,

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

And here you go Patch applies cleany, make check ok. Looks pretty good. A minor detail I have just noticed, sorry: now that options are discarded by functions, some string variable declarations should be moved back inside the active branch. You moved them out because you where sharing the

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

Ashutosh Sharma writes: >> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*) >> (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397) > Thanks for reporting this problem. Could you please let me know on for > how long did you run sqlsmith to get this crash. I got about one TRAP per hour

Re: [HACKERS] [POC] A better way to expand hash indexes.

Hi Mithun, On 03/26/2017 01:56 AM, Mithun Cy wrote: Thanks, Amit for the review. On Sat, Mar 25, 2017 at 7:03 PM, Amit Kapila wrote: I think one-dimensional patch has fewer places to touch, so that looks better to me. However, I think there is still hard coding and

Re: [HACKERS] Unused argument in PinBuffer function

On Thu, Aug 4, 2016 at 2:28 PM, Ildar Musin wrote: > I was looking through the buffer manager's code and have noticed that > function PinBuffer has an unused 'strategy' argument. It's seems that after > refactoring made by Alexander Korotkov and Andres Freund >

Re: [HACKERS] logical replication launcher crash on buildfarm

Robert Haas writes: > ... I don't have much > personal enthusiasm for trying to figure out how to make dynamic > loading on the postgres binary itself work everywhere, so if it falls > to me to fix, it's likely to get a hard-coded check for some > hard-coded name. +1.

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-03-23 17:26 GMT+01:00 Pierre Ducroquet : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 13:30:11 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-03-27 12:18:37 -0400, Tom Lane wrote: > >> My feeling at this point is that we might be better off disabling > >> the computed-goto case by default. At the very least, we're going > >> to need a

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-27 12:18:37 -0400, Tom Lane wrote: >> My feeling at this point is that we might be better off disabling >> the computed-goto case by default. At the very least, we're going >> to need a version check that restricts it to latest gcc. > In my

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-27 13:01:11 -0400, Robert Haas wrote: > On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund wrote: > > Robert, Petr, either of you planning to fix this (as outlined elsewhere > > in the thred)? > > Oh, I didn't realize anybody was looking to me to fix this. Well, it's

Re: [HACKERS] logical replication launcher crash on buildfarm

On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund wrote: > Robert, Petr, either of you planning to fix this (as outlined elsewhere > in the thred)? Oh, I didn't realize anybody was looking to me to fix this. I sort of thought that it was fallout from the logical replication

Re: [HACKERS] segfault in hot standby for hash indexes

On Fri, Mar 24, 2017 at 3:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma > wrote: >>> >>> I think it would have been probably okay to use *int* for ntuples as >>> that matches with what you are actually assigning in

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 10:13:37 +0100, Petr Jelinek wrote: > On 16/03/17 09:53, Andres Freund wrote: > > On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > >> On 16/03/17 04:42, Andres Freund wrote: > >>> On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > Hi, > > I just unstuck a bunch of

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Mon, Mar 27, 2017 at 12:36 PM, Rushabh Lathia wrote: > Hmm I agree that it's good idea, and I will work on that as separate patch. Maybe you want to start with what David already posted? >> Possibly we >> should fix the crash bug first, though, and then do that

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 12:18:37 -0400, Tom Lane wrote: > I wrote: > > As to the point of whether it actually helps or not ... > > on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of > > the dispatches getting routed through a common location, to *all* of them > > (except one; for some

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Mon, Mar 27, 2017 at 9:52 PM, Robert Haas wrote: > On Mon, Mar 27, 2017 at 12:11 PM, David Rowley > wrote: > > On 28 March 2017 at 04:57, Robert Haas wrote: > >> On Sat, Mar 25, 2017 at 12:18 PM, Rushabh Lathia > >>

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Mon, Mar 27, 2017 at 12:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Mar 27, 2017 at 9:54 AM, Tom Lane wrote: >>> Since this has now come up twice, I suggest adding a comment there >>> that explains why we're

Re: [HACKERS] Potential data loss of 2PC files

Thank you, pushed Michael Paquier wrote: On Fri, Mar 24, 2017 at 11:36 PM, Teodor Sigaev wrote: And the renaming of pg_clog to pg_xact is also my fault. Attached is an updated patch. Thank you. One more question: what about symlinks? If DBA moves, for example, pg_xact to

Re: [HACKERS] segfault in hot standby for hash indexes

>> >> >> >> I think it would have been probably okay to use *int* for ntuples as >> >> that matches with what you are actually assigning in the function. >> > >> > okay, corrected it. Attached is newer version of patch. >> > >> >> Thanks, this version looks good to me. > > > It solves the problem

Re: [HACKERS] crashes due to setting max_parallel_workers=0

Robert Haas writes: > On Mon, Mar 27, 2017 at 9:54 AM, Tom Lane wrote: >> Since this has now come up twice, I suggest adding a comment there >> that explains why we're intentionally ignoring max_parallel_workers. > Good idea. How about the attached?

Re: [HACKERS] Potential data loss of 2PC files

Thank you. One more question: what about symlinks? If DBA moves, for example, pg_xact to another dist and leaves the symlink in data directoty. Suppose, fsync on symlink will do nothing actually. I did not think of this case, but is that really common? There is even I saw a lot such cases.

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Mon, Mar 27, 2017 at 12:11 PM, David Rowley wrote: > On 28 March 2017 at 04:57, Robert Haas wrote: >> On Sat, Mar 25, 2017 at 12:18 PM, Rushabh Lathia >> wrote: >>> About the original issue reported by Tomas, I

Re: [HACKERS] [COMMITTERS] pgsql: Improve performance of find_all_inheritors()

On Mon, Mar 27, 2017 at 12:08 PM, Teodor Sigaev wrote: > Improve performance of find_all_inheritors() > > Previous coding uses three nested loops which obviously were a pain for > large number of table's children. Patch replaces inner loop with > a hashmap. > > Author:

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 11:52:05 -0400, Tom Lane wrote: > As to the point of whether it actually helps or not ... > > on gcc 6.3.1 (Fedora 25), yes it does. Seems to be one "jmp *something" > per EEO_NEXT or EEO_JUMP. > > on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of > the

Re: [HACKERS] WIP: Faster Expression Processing v4

I wrote: > As to the point of whether it actually helps or not ... > on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of > the dispatches getting routed through a common location, to *all* of them > (except one; for some odd reason the first EEO_NEXT in EEOP_NULLIF > survives

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Sat, Mar 25, 2017 at 9:24 PM, Mengxing Liu wrote: > I've updated the proposal according to your comments. > But I am still wondering that can you review it for a double-check > to make sure I've made everything clear? Additional comments added. I'm afraid a

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 28 March 2017 at 04:57, Robert Haas wrote: > On Sat, Mar 25, 2017 at 12:18 PM, Rushabh Lathia > wrote: >> About the original issue reported by Tomas, I did more debugging and >> found that - problem was gather_merge_clear_slots() was not

Re: [HACKERS] partitioned tables and contrib/sepgsql

On Mon, Mar 27, 2017 at 11:46 AM, Robert Haas wrote: > On Mon, Mar 27, 2017 at 11:22 AM, Mike Palmiotto > wrote: >> On Mon, Mar 27, 2017 at 10:47 AM, Robert Haas wrote: >>> On Thu, Mar 9, 2017 at 9:47 AM, Stephen

Re: [HACKERS] [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada wrote: > On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao wrote: >> On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada >> wrote: >>> On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs

Re: [HACKERS] logical replication worker and statistics

On Mon, Mar 27, 2017 at 11:14 AM, Fujii Masao wrote: > Logical replication worker should call pgstat_report_stat()? > Currently it doesn't seem to do that and no statistics about > table accesses by logical replication workers are collected. > For example, this can prevent

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Sat, Mar 25, 2017 at 12:18 PM, Rushabh Lathia wrote: > About the original issue reported by Tomas, I did more debugging and > found that - problem was gather_merge_clear_slots() was not returning > the clear slot when nreader is zero (means nworkers_launched = 0). >

Re: [HACKERS] segfault in hot standby for hash indexes

On Fri, Mar 24, 2017 at 12:49 AM, Amit Kapila wrote: > On Fri, Mar 24, 2017 at 12:25 PM, Ashutosh Sharma > wrote: > >> > >> I think it would have been probably okay to use *int* for ntuples as > >> that matches with what you are actually assigning

Re: [HACKERS] WIP: Faster Expression Processing v4

As to the point of whether it actually helps or not ... on gcc 6.3.1 (Fedora 25), yes it does. Seems to be one "jmp *something" per EEO_NEXT or EEO_JUMP. on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of the dispatches getting routed through a common location, to *all*

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Mon, Mar 27, 2017 at 9:54 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Mar 27, 2017 at 1:29 AM, Rushabh Lathia >> wrote: >>> But it seems a bit futile to produce the parallel plan in the first place, >>> because

  1   2   >