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

On Tue, Mar 28, 2017 at 10:43 AM, Mithun Cy wrote: > On Mon, Mar 27, 2017 at 11:21 AM, Amit Kapila wrote: > > > As you have said we can solve it if we allocate buckets always in > power-of-2 when we do hash index meta page init. But on other > occasions, when we try to double the existing buckets

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

This conflicts with 6912acc (replication lag tracker) so just rebased on a6f22e8. At Fri, 17 Mar 2017 16:48:27 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170317.164827.46663014.horiguchi.kyot...@lab.ntt.co.jp> > Hello, > > At Mon, 13 Mar 2017 11:06:00 +1100, Venkata B Nagothi

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

Thanks Tsunakawa for such an informative reply. Almost all of the docs related to the internals of PG are of introductory concepts only. There is even more useful PG internals site entitled "The Internals of PostgreSQL" in http://www.interdb.jp/pg/ translation of the Japanese PG Internals. The qu

Re: [HACKERS] Proposal for changes to recovery.conf API

On Mon, Mar 27, 2017 at 5:27 PM, Simon Riggs wrote: > I share your pain, but there are various things about this patch that > make me uncomfortable. I believe we are looking for an improved design > not just a different design. > > I think the best time to commit such a patch is at the beginning o

Re: [HACKERS] Speedup twophase transactions

On Tue, Mar 28, 2017 at 3:08 PM, Nikhil Sontakke wrote: >> >> I don't have anything else to say about this patch, so should we mark >> that as ready for committer? There are still a couple of days left >> until the end of the CF, and quite a lot has happened, so this could >> get on time into PG10

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 > t/002_warm_stress.pl. (

Re: [HACKERS] Speedup twophase transactions

> > > I don't have anything else to say about this patch, so should we mark > that as ready for committer? There are still a couple of days left > until the end of the CF, and quite a lot has happened, so this could > get on time into PG10. > Yes, let's mark it "ready for committer". This patch/fe

Re: [HACKERS] Speedup twophase transactions

On Tue, Mar 28, 2017 at 2:10 PM, Nikhil Sontakke wrote: > 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. Yup. > My only question is if the added call to restoreTwoPhaseData() is go

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 ac3

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 in all the affected functio

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 t

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 > depends on the number of bucke

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 could be used as well to 2PC files

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 PrescanPreparedTra

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 qu

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 list (pgsql-hackers@postgresql

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 9:36 PM, Amit Kapila >> wrote: >> >> >> >> On Tue, Feb 7, 2017 at 11:47 AM, H

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 parallel_tuple

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: > > Other than by FPI, FSM update is omitted when record LSN is older > > than page LSN. If heap page is evicted but FSM pag

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 plan in the first place, because with max_parallel_workers=0 we can't po

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. -- Regards, Rafia Sabih Enterpris

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() perform >> linear searches of the dsm_control->item arra

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 > contrib/test_decoding/sql/prepare.sql .

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 shared_preload_library libraries. For old

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, Amit Kapila > >> wrote: > >>> > > > >> While looking at this problem, it occurr

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 fea

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 i

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 will only happen onc

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); > else if (strcmp(bgw

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 a slot matching a given handle.

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 only places where it's acceptable to leave that >>> out are for int

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 INCOMPATIBILITY' > > - a lot

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 it would be better to align with >

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 leave things as they

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 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: > >

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 > author of > > > the patch, I might have go

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. >> > >> > On a very quick skim, this doesn't s

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 benchmarks. But I've seen > > over 50% improvement i

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 seen > > over 50% improvem

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 > t/002_warm_stress.pl. (

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 > >>> in the thred)? > >> >

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 >> node and store them as bitmap of initplan params a

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 looking to me to fix this.

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 Paquier >>> Do you think that this qualifies as a bug fix for a

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 that it was fallout from

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 > > deadlocks of prepared

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 did you run sqlsmith t

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

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 with

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 ntuples as >>> that matches with what you are actually assigning in the fu

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 > --- a/sr

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 hunk in vcregress.

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. >> >> https://wiki.postgresql.org/wiki/PostgreSQL_10

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 patch. Now it's reduced to simply re

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 message with fix, but right now >> sending it >> as is

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 realistic examples)? Then

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. > > Fixed. I forgot to postpone Reor

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 before. That's > what w

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, but I would not mind waiting for

[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 src/tools/ms

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? > Thanks for reviewing - updated patch attac

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

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. Thoughts from others? --

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 CO

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 in the input/path

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

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! Please post whatever you have before you knock of

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

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 indexes on a 12 > column ta

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: http://www.postgresql.org/mailpr

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 moved back inside > th

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

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 w

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 assumptions in code which

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 > (48354581a49c30f5757c203415aa8412d8

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. This seems like no time to

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:tested, passed > > H

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 version check that r

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 measurements it's st

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 borked in 9.6. I'm

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 patch and that Petr or

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 the function. >> >> okay, corrected it. Attached

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 afterwards. >> What bugs me a l

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 > >> wrote: > >>> About the original issue reported by Tomas, I did more debuggi

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 intentionally ignoring max_parallel_workers. > >> Good idea. How about t

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 another dist and le

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 f

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? WFM ... but seems like there should be some

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

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 did more debugging and >>> found that - problem was gather_merge_clear_slots() was

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: Aleksander Alekseev > Review

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 disp

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 few new issues came to mind readin

  1   2   >