Re: [PoC PATCH] Parallel dump to /dev/null

strdup -> pg_strdup() I wonder if, instead of doing strcmp() all over the place, we should give this behavior a separate boolean flag in lclContext. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Mar 1, 2018 at 4:33 AM, Pavan Deolasee wrote: > What if the updated tuple fails the join qual with respect to the current > tuple from the source relation but it now matches some other tuple from the > source relation? I described this case in one of the earlier emails too. In > this case,

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Jing Wang writes: > [ support_CURRENT_DATABASE_keyword_v4.7.patch ] TBH, I think we should reject this patch. While it's not huge, it's not trivial either, and I find the grammar changes rather ugly. The argument for using the feature to fix pg_dump issues has evaporated, but I don't see anythin

Re: [HACKERS] path toward faster partition pruning

On Wed, Feb 28, 2018 at 11:53 PM, Amit Langote wrote: > Attached updated patches. + memcpy(part_scheme->partsupfunc, partkey->partsupfunc, + sizeof(FmgrInfo) * partnatts); You can't copy an FmgrInfo by just applying memcpy() to it. Use fmgr_info_copy. I don't like the co

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

On 12/15/17 5:31 PM, Peter Geoghegan wrote: > Commit d70cf811, from 2014, promoted an Assert() within > IndexBuildHeapScan() to a "can't happen" elog() error, in order to > detect when a parent tuple cannot be found for some heap-only tuple -- > if this happens, then it indicates corruption. I thin

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Hi, On 2018-01-04 11:39:40 -0500, Robert Haas wrote: > On Tue, Jan 2, 2018 at 1:09 AM, Mithun Cy wrote: > > So in case of N_RELEXTLOCK_ENTS = 1 we can see regression as high 25%. ? > > So now the question is: what do these results mean for this patch? > I think that the chances of someone simu

Re: Failed to request an autovacuum work-item in silence

Masahiko Sawada wrote: > While reading the code, I realized that the requesting an autovacuum > work-item could fail in silence if work-item array is full. So the > users cannot realize that work-item is never performed. > AutoVacuumRequestWork() seems to behave so from the initial > implementatio

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

On Thu, Mar 1, 2018 at 11:15 AM, David Steele wrote: > On 12/15/17 5:31 PM, Peter Geoghegan wrote: >> Commit d70cf811, from 2014, promoted an Assert() within >> IndexBuildHeapScan() to a "can't happen" elog() error, in order to >> detect when a parent tuple cannot be found for some heap-only tuple

Re: [HACKERS] Small improvement to compactify_tuples

Hi, On 2018-02-25 21:39:46 +0300, Yura Sokolov wrote: > > If that's the case then does it really make sense to make this change..? > > I don't think it is really necessary to implement generic version > through templated. Why? > Updated numbers are (same benchmark on same notebook, but with new

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

On 3/1/18 2:19 PM, Peter Geoghegan wrote: > On Thu, Mar 1, 2018 at 11:15 AM, David Steele wrote: >> On 12/15/17 5:31 PM, Peter Geoghegan wrote: >>> Commit d70cf811, from 2014, promoted an Assert() within >>> IndexBuildHeapScan() to a "can't happen" elog() error, in order to >>> detect when a paren

Re: Protect syscache from bloating with negative cache entries

On Thu, Mar 1, 2018 at 1:54 PM, Andres Freund wrote: > So this is hardcoded, without any sort of cache pressure logic? Doesn't > that mean we'll often *severely* degrade performance if a backend is > idle for a while? Well, it is true that if we flush cache entries that haven't been used in a lon

Re: Protect syscache from bloating with negative cache entries

Hi, On 2018-03-01 14:24:56 -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 1:54 PM, Andres Freund wrote: > > So this is hardcoded, without any sort of cache pressure logic? Doesn't > > that mean we'll often *severely* degrade performance if a backend is > > idle for a while? > > Well, it is t

Re: [GSOC 18] Performance Farm Project

On Thu, Mar 1, 2018 at 4:56 AM, 马来酸 wrote: > Hi, my name is Hongyuan Ma. I am a junior student in software engineering in > Shanghai.I am interested in the idea "Develop Performance Farm Database and > Website".I started developing web applications since my sophomore year and > have experience in

Re: Parallel Aggregates for string_agg and array_agg

Hi David, On 12/17/17 9:30 AM, David Rowley wrote: > > I'm going to add this to PG11's final commitfest rather than the > January 'fest as it seems more like a final commitfest type of patch. This patch applies but no longer builds: $ make -C /home/vagrant/test/build <...> cd /postgres/src/incl

Re: Re: Suspicious call of initial_cost_hashjoin()

Hi Antonin, On 12/22/17 6:13 AM, Thomas Munro wrote: > On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska wrote: >> try_partial_hashjoin_path() passes constant true to for the parallel_hash >> argument of initial_cost_hashjoin(). Shouldn't it instead pass the >> parallel_hash argument that it recei

Re: [HACKERS] Surjective functional indexes

Hi, I still don't think, as commented upon by Tom and me upthread, that we want this feature in the current form. Your arguments about layering violations seem to be counteracted by the fact that ProjectionIsNotChanged() basically appears to do purely executor work inside inside heapam.c. Greeti

Re: Protect syscache from bloating with negative cache entries

On Thu, Mar 1, 2018 at 2:29 PM, Andres Freund wrote: > Right. Which might be very painful latency wise. And with poolers it's > pretty easy to get into situations like that, without the app > influencing it. Really? I'm not sure I believe that. You're talking perhaps a few milliseconds - maybe

Re: Protect syscache from bloating with negative cache entries

On 2018-03-01 14:49:26 -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 2:29 PM, Andres Freund wrote: > > Right. Which might be very painful latency wise. And with poolers it's > > pretty easy to get into situations like that, without the app > > influencing it. > > Really? I'm not sure I beli

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

On Thu, Mar 1, 2018 at 11:23 AM, David Steele wrote: > Yes, I agree. My thrust was more to discover if there is any testing > for these conditions being done in core. It sounds like no, but I don't > think it's the responsibility of this patch to add them. The only tests possible with stock Pos

Re: [PATCH] Opclass parameters

On Wed, Feb 28, 2018 at 5:46 PM, Nikolay Shaplov wrote: > Concerning the patch that you've provided. I've just have a short look. But I > already have some question. > > 1. I've seen you've added a new attribute into pg_index. Why??!! > As far as I can get, if have index built on several columns

Re: Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

Hi Alexander, On 1/4/18 4:25 PM, Alexander Korotkov wrote: > > I just found that patch apply is failed according to > commitfest.cputube.org .  I think it's > because I sent only second patch from patchset in last message. > Anyway I resend both patches rebased to c

Re: Re: [HACKERS] plpgsql - additional extra checks

Hi Pavel, On 1/7/18 3:31 AM, Pavel Stehule wrote: > > There, now it's in the correct Waiting for Author state. :) > > thank you for comments. All should be fixed in attached patch This patch no longer applies (and the conflicts do not look trivial). Can you provide a rebased patch? $ git a

Re: [HACKERS] Secondary index access optimizations

Hi, This patch seems like quite a good improvement. One thing I've not really looked at but am slightly concerned in passing: Are there cases where we now would do a lot of predicate pruning work even though the overhead of just evaluating the qual is trivial, e.g. because there's only one row du

Re: Protect syscache from bloating with negative cache entries

On Thu, Mar 1, 2018 at 3:01 PM, Andres Freund wrote: > On 2018-03-01 14:49:26 -0500, Robert Haas wrote: >> On Thu, Mar 1, 2018 at 2:29 PM, Andres Freund wrote: >> > Right. Which might be very painful latency wise. And with poolers it's >> > pretty easy to get into situations like that, without th

Re: Protect syscache from bloating with negative cache entries

Hi, On 2018-03-01 15:19:26 -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 3:01 PM, Andres Freund wrote: > > On 2018-03-01 14:49:26 -0500, Robert Haas wrote: > >> On Thu, Mar 1, 2018 at 2:29 PM, Andres Freund wrote: > >> > Right. Which might be very painful latency wise. And with poolers it's

Re: In reference to gsoc

On Thu, Mar 1, 2018 at 7:50 AM, Tanvi Dadu wrote: > It would be helpful if someone direct me to the repo I will be working and > sorting techniques used. Please give me a brief about the data structures > used and also the starting point for getting familiar repository and work > that needs to be

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Thu, Mar 1, 2018 at 2:17 PM, Andres Freund wrote: >> However, if we take the position that no hash collision probability is >> low enough and that we must eliminate all chance of false collisions, >> except perhaps when the table is full, then we have to make this >> locking mechanism a whole l

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Kyotaro HORIGUCHI writes: > At Wed, 24 Jan 2018 00:13:51 +0300, Sergei Kornilov wrote in > <348951516742...@web54j.yandex.ru> >> Should we also make backport to older versions? I test on REL_10_STABLE - >> patch builds and works ok, but "make check" fails on new testcase with error: > CREATE IN

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On 2018-03-01 15:37:17 -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 2:17 PM, Andres Freund wrote: > >> However, if we take the position that no hash collision probability is > >> low enough and that we must eliminate all chance of false collisions, > >> except perhaps when the table is full,

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2018-01-10 11:14:27 +1300, David Rowley wrote: > On 10 January 2018 at 08:44, Tom Lane wrote: > > I'll set the patch back to Waiting on Author. > > Many thanks for looking at this. I'll try to resolve the things you've > mentioned this coming weekend. This hasn't happened yet. As the last CF

Re: Re: [PATCH] Opclass parameters

On Thu, Mar 1, 2018 at 7:02 PM, David Steele wrote: > Hi Nikita, > > On 2/28/18 9:46 AM, Nikolay Shaplov wrote: >> В письме от 28 февраля 2018 00:46:36 пользователь Nikita Glukhov написал: >> >>> I would like to present patch set implementing opclass parameters. >>> >>> This feature was recently p

Re: [HACKERS] Removing useless DISTINCT clauses

Hi, On 2018-01-10 11:12:17 +1300, David Rowley wrote: > I'll do some more analysis on places that distinctClause is being used > to check what's safe. This patch has been waiting on author since 2018-01-09, the next & last CF has started. I'm inclined to mark this as returned with feedback. Gree

Re: [HACKERS] Removing useless DISTINCT clauses

On 2 March 2018 at 09:51, Andres Freund wrote: > This patch has been waiting on author since 2018-01-09, the next & last > CF has started. I'm inclined to mark this as returned with feedback. I'm planning on making the required changes at the weekend. -- David Rowley http://

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2 March 2018 at 09:49, Andres Freund wrote: > On 2018-01-10 11:14:27 +1300, David Rowley wrote: >> On 10 January 2018 at 08:44, Tom Lane wrote: >> > I'll set the patch back to Waiting on Author. >> >> Many thanks for looking at this. I'll try to resolve the things you've >> mentioned this comi

Re: [PATCH] Opclass parameters

On 3/1/18 3:50 PM, Oleg Bartunov wrote: > On Thu, Mar 1, 2018 at 7:02 PM, David Steele wrote: >> >> Any objections to marking this Returned with Feedback? Or, I can move it >> to the next CF as is. > > I think that Returned with Feedback would be good. We will continue > discussion in -hackers.

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2018-03-02 09:53:38 +1300, David Rowley wrote: > On 2 March 2018 at 09:49, Andres Freund wrote: > > On 2018-01-10 11:14:27 +1300, David Rowley wrote: > >> On 10 January 2018 at 08:44, Tom Lane wrote: > >> > I'll set the patch back to Waiting on Author. > >> > >> Many thanks for looking at this

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2 March 2018 at 09:56, Andres Freund wrote: > On 2018-03-02 09:53:38 +1300, David Rowley wrote: >> On 2 March 2018 at 09:49, Andres Freund wrote: >> > On 2018-01-10 11:14:27 +1300, David Rowley wrote: >> >> On 10 January 2018 at 08:44, Tom Lane wrote: >> >> > I'll set the patch back to Waitin

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2018-03-02 09:57:35 +1300, David Rowley wrote: > On 2 March 2018 at 09:56, Andres Freund wrote: > > On 2018-03-02 09:53:38 +1300, David Rowley wrote: > >> I'm planning on making the required changes at the weekend. > > > > Sorry if I'm grumpy, but why shouldn't this just mean it's slipped to >

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Thu, Mar 1, 2018 at 3:40 PM, Andres Freund wrote: >> You can't both store every lock at a fixed address and at the same >> time put locks at a different address if the one they would have used >> is already occupied. > > Right, but why does that require a lock? Maybe I'm being dense here but .

Re: MCV lists for highly skewed distributions

Hi Dean, On 2018-02-07 15:58:14 +, Dean Rasheed wrote: > On 7 February 2018 at 15:25, Robert Haas wrote: > > Do you plan to press forward with this, then, or what's > > the next step? > > > > Yes, I think the results are pretty good so far, especially for the > more non-uniform distributions

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

Peter Geoghegan writes: > On Thu, Mar 1, 2018 at 11:23 AM, David Steele wrote: >> Yes, I agree. My thrust was more to discover if there is any testing >> for these conditions being done in core. It sounds like no, but I don't >> think it's the responsibility of this patch to add them. > The on

Re: WIP Patch: Precalculate stable functions, infrastructure v1

Hi, On 2018-02-01 08:01:48 +0300, Marina Polyakova wrote: > > ISTM, there might be some value to consider all of them in the design of > > the new mechanism. > > I'm sorry, the other parts have occupied all the time, and I'll work on it.. That has, as far as I can see, not happened. And the patch

Re: zheap: a new storage format for PostgreSQL

On Thu, Mar 1, 2018 at 5:09 PM, Amit Kapila wrote: > Preliminary performance results > --- > > *We’ve shown the performance improvement of zheap over heap in a few > different pgbench scenarios. All of these tests were run with data that > fits in shared_b

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2 March 2018 at 09:59, Andres Freund wrote: > If a patch hasn't been updated after moved waiting-on-author from the > last CF, and the next CF started, that seems too late. Particularly in > the last CF. I understand that I should have resolved these issues before the commitfest, so please do

Re: [HACKERS] Removing LEFT JOINs in more cases

On 2018-03-02 10:14:52 +1300, David Rowley wrote: > One observation is that it appears you're already running damage > control to triage the patches that will certainly not make it. I don't > think this particular patch is overly complex, so is that really a > good thing to do on the first of the m

Re: row filtering for logical replication

On 2018-03-01 16:27, Erik Rijkers wrote: On 2018-03-01 00:03, Euler Taveira wrote: The attached patches add support for filtering rows in the publisher. 001-Refactor-function-create_estate_for_relation.patch 0002-Rename-a-WHERE-node.patch 0003-Row-filtering-for-logical-replication.patch Co

Re: Parallel Aggregates for string_agg and array_agg

Hi, On 2017-12-18 03:30:55 +1300, David Rowley wrote: > While working on partial aggregation a few years ago, I didn't really > think it was worthwhile allowing partial aggregation of string_agg and > array_agg. I soon realised that I was wrong about that and allowing > parallelisation of these ag

Re: Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

On Thu, Mar 1, 2018 at 11:05 PM, David Steele wrote: > On 1/4/18 4:25 PM, Alexander Korotkov wrote: > > > > I just found that patch apply is failed according to > > commitfest.cputube.org . I think it's > > because I sent only second patch from patchset in last mes

Re: Parallel Aggregates for string_agg and array_agg

Thanks for looking at the patch. On 2 March 2018 at 08:33, David Steele wrote: > This patch applies but no longer builds: ... > Looks like duplicate OIDs in pg_proc.h. Who stole my OIDs?! Updated patch attached. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Devel

Re: row filtering for logical replication

Hi, On 2018-03-01 16:27:11 +0100, Erik Rijkers wrote: > Very, very useful. I really do hope this patch survives the > late-arrival-cull. FWIW, I don't think it'd be fair or prudent. There's definitely some issues (see e.g. Craig's reply), and I don't see why this patch'd deserve an exemption fro

Re: Optimize Arm64 crc32c implementation in Postgresql

Hi, On 2018-01-10 05:58:19 +, Yuqi Gu wrote: > Currently PostgreSQL only implements hardware support for CRC32 checksums for > the x86_64 architecture. > Some ARMv8 (AArch64) CPUs implement the CRC32 extension which is implemented > by inline assembly, > so they can also benefit from hardwar

Re: Optimize Arm64 crc32c implementation in Postgresql

Hi, On 2018-01-10 15:09:16 +0900, Michael Paquier wrote: > There are not enough patches for ARM. Nah, not needing arch specific patches is good ;) Greetings, Andres Freund

Re: jsonpath

On 28.02.2018 06:55, Robert Haas wrote: On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov wrote: Attached 10th version of the jsonpath patches. 1. Fixed error handling in arithmetic operators. Now run-time errors in arithmetic operators are catched (added PG_TRY/PG_CATCH around operat

Re: row filtering for logical replication

Hi, On 3/1/18 4:27 PM, Andres Freund wrote: > On 2018-03-01 16:27:11 +0100, Erik Rijkers wrote: >> Very, very useful. I really do hope this patch survives the >> late-arrival-cull. > > FWIW, I don't think it'd be fair or prudent. There's definitely some > issues (see e.g. Craig's reply), and I d

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 1, 2018 at 5:34 AM, Jeevan Chalke wrote: > Attached new patchset after rebasing my changes over these changes and on > latest HEAD. +* We have already created a Gather or Gather Merge path atop cheapest +* partial path. Thus the partial path referenced by the Gather no

Re: jsonpath

On Fri, Mar 2, 2018 at 12:40 AM, Nikita Glukhov wrote: > On 28.02.2018 06:55, Robert Haas wrote: > > On Mon, Feb 26, 2018 at 10:34 AM, Nikita Glukhov >> wrote: >> >>> Attached 10th version of the jsonpath patches. >>> >>> 1. Fixed error handling in arithmetic operators. >>> >>> Now run-time

Re: Hash Joins vs. Bloom Filters / take 2

Hi, On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote: > So I've decided to revive the old patch, rebase it to current master, > and see if we can resolve the issues that killed it in 2016. There seems to be some good discussion in the thread. But the patch arrived just before the last commitfest

Re: "failed to find parent tuple for heap-only tuple" error as an ERRCODE_DATA_CORRUPTION ereport()

On Thu, Mar 1, 2018 at 1:04 PM, Tom Lane wrote: > Patch looks fine to me, will push. Thank you. -- Peter Geoghegan

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 2018-01-23 17:08:56 +0100, Pavel Stehule wrote: > 2018-01-22 23:15 GMT+01:00 Stephen Frost : > > This really could use a new thread, imv. This thread is a year old and > > about a completely different feature than what you've implemented here. > > > > true, but now it is too late At the very

Re: [HACKERS] MERGE SQL Statement for PG11

On 02/06/2018 03:40 PM, Tomas Vondra wrote: > > > I plan to go through the patch and this thread over the couple of > days, and summarize what the current status is (or my understanding > of it). That is (a) what are the missing pieces, (b) why are they > missing, (c) how we plan to address them

Re: MCV lists for highly skewed distributions

On 1 March 2018 at 21:01, Andres Freund wrote: > This sounds like the patch's status of "waiting on author" isn't right, > and it should more be ready for committer? > Yes, I'll take a look at it this weekend. Regards, Dean

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

On Thu, 1 Mar 2018 17:25:09 +0300 Alexander Kuzmenkov wrote: > Well, that sounds reasonable. But the problem with the moving average > calculation remains. Suppose you run vacuum and not analyze. If the > updates are random enough, vacuum won't be able to reclaim all the > pages, so the number

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

Hi, On 2018-01-11 11:03:26 +0900, Yugo Nagata wrote: > However, I don't inisist on this patch, so If anyone other don't need this > feature, I'll withdraw this. Given this is where the discussion dried up more than a month ago I'm inclined to mark this as rejected unless somebody wants to argue o

Re: Optimize Arm64 crc32c implementation in Postgresql

On Fri, Mar 2, 2018 at 10:36 AM, Andres Freund wrote: > On 2018-01-10 05:58:19 +, Yuqi Gu wrote: >> +#ifdef USE_ARMCE_CRC32C_WITH_RUNTIME_CHECK >> +#include >> +#include >> +#ifndef HWCAP_CRC32 >> +#define HWCAP_CRC32 (1 << 7) >> +#endif > >> +static bool >> +pg_crc32c_arm64ce_available(void

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Hi, On 2018-01-11 01:02:52 +0300, Alexander Korotkov wrote: > As I get from cputube, patchset doesn't compiles again. Please find > revised version attached. It'd be good if you could maintain the patches as commits with some description of why you're doing these changes. It's a bit hard to fig

Re: Optimize Arm64 crc32c implementation in Postgresql

On 2018-03-02 11:37:52 +1300, Thomas Munro wrote: > So... that stuff probably needs either a configure check for the > getauxval function and/or those headers, or an OS check? It'd probably be better to not rely on os specific headers, and instead directly access the capabilities. > While I'm lo

Re: 2018-03 Commitfest Summary (Andres #2)

On 2018-03-01 03:03:44 -0800, Andres Freund wrote: > Going through all non bugfix CF entries. Here's the summary for the > entries I could stomach tonight: > > RFC: ready for committer > NR: needs review > WOA: waiting on author. Second round. - Sample values for pg_stat_statements NR. Submitt

pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)

On Wed, Feb 28, 2018 at 9:44 AM, Andres Freund wrote: > Looks like we're not doing a pgstat_report_activity() in the workers? > Any argument for not doing so? No. Just an oversight. Looks like _bt_parallel_build_main() should call pgstat_report_activity(), just like ParallelQueryMain(). I'll com

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Hi! On Fri, Mar 2, 2018 at 1:41 AM, Andres Freund wrote: > On 2018-01-11 01:02:52 +0300, Alexander Korotkov wrote: > > As I get from cputube, patchset doesn't compiles again. Please find > > revised version attached. > > It'd be good if you could maintain the patches as commits with some > desc

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote: > Also, the last commitfest is already too late for such big changes. > So, I'm marking this RWF. Agreed. Perhaps extract the 64bit GUC patch and track that separately? Seems like something we should just do... Greetings, Andres Freund

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund wrote: > On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote: > > Also, the last commitfest is already too late for such big changes. > > So, I'm marking this RWF. > > Agreed. Perhaps extract the 64bit GUC patch and track that separately? > Seems

Re: row filtering for logical replication

2018-03-01 18:27 GMT-03:00 Andres Freund : > FWIW, I don't think it'd be fair or prudent. There's definitely some > issues (see e.g. Craig's reply), and I don't see why this patch'd > deserve an exemption from the "nontrivial patches shouldn't be submitted > to the last CF" policy? > I forgot to me

Re: row filtering for logical replication

2018-03-01 18:25 GMT-03:00 Erik Rijkers : > Attached is 'logrep_rowfilter.sh', a demonstration of above-described bug. > Thanks for testing. I will figure out what is happening. There are some leaks around. I'll post another version when I fix some of those bugs. -- Euler Taveira

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

On 2018-03-02 01:56:00 +0300, Alexander Korotkov wrote: > On Fri, Mar 2, 2018 at 1:51 AM, Andres Freund wrote: > > > On 2018-03-02 01:48:03 +0300, Alexander Korotkov wrote: > > > Also, the last commitfest is already too late for such big changes. > > > So, I'm marking this RWF. > > > > Agreed. P

Re: row filtering for logical replication

2018-02-28 21:54 GMT-03:00 Craig Ringer : > Good idea. I haven't read this yet, but one thing to make sure you've > handled is limiting the clause to referencing only the current tuple and the > catalogs. user-catalog tables are OK, too, anything that is > RelationIsAccessibleInLogicalDecoding(). >

Re: row filtering for logical replication

On 3/1/18 6:00 PM, Euler Taveira wrote: 2018-03-01 18:27 GMT-03:00 Andres Freund : FWIW, I don't think it'd be fair or prudent. There's definitely some issues (see e.g. Craig's reply), and I don't see why this patch'd deserve an exemption from the "nontrivial patches shouldn't be submitted to th

Re: 2018-03 Commitfest Summary (Andres #2)

() On Thu, Mar 1, 2018 at 2:45 PM, Andres Freund wrote: > - "failed to find parent tuple for heap-only tuple" error as an > ERRCODE_DATA_CORRUPTION ereport() > > NR. Should probably just get applied. Can't quite make myself care > enough to interrupt right now. Tom just committed this. > -

Re: Sample values for pg_stat_statements

On 03/01/2018 07:26 PM, Andres Freund wrote: > Hm. Isn't this going to blow up the size of the file in cases with a > number of parameters quite considerably, a file limit notwithstanding? > Wonder if the size limit wouldn't have to be across all params. It is across all params (per queryid). --

Re: Faster inserts with mostly-monotonically increasing values

On Sun, Dec 31, 2017 at 8:06 AM, Peter Geoghegan wrote: > I also have my > doubts about unique index enforcement remaining correct with the patch > when there are many physical duplicates, to the extent that more than > a single leaf page is needed for a single value. given... +if (P_ISL

Re: Hash Joins vs. Bloom Filters / take 2

On 03/01/2018 11:01 PM, Andres Freund wrote: > Hi, > > On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote: >> So I've decided to revive the old patch, rebase it to current master, >> and see if we can resolve the issues that killed it in 2016. > > There seems to be some good discussion in the thr

Re: Hash Joins vs. Bloom Filters / take 2

On March 1, 2018 3:22:44 PM PST, Tomas Vondra wrote: > > >On 03/01/2018 11:01 PM, Andres Freund wrote: >> Hi, >> >> On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote: >>> So I've decided to revive the old patch, rebase it to current >master, >>> and see if we can resolve the issues that killed

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

Alexander Kuzmenkov writes: > On 01.03.2018 18:09, Tom Lane wrote: >> Ideally, at least, the estimate would remain on-target. > The test shows that under this particular scenario the estimated number > of tuples grows after each ANALYZE. I tried to explain how this happens > in the attached pdf

Re: Hash Joins vs. Bloom Filters / take 2

On 03/02/2018 12:31 AM, Andres Freund wrote: > > > On March 1, 2018 3:22:44 PM PST, Tomas Vondra > wrote: >> >> >> On 03/01/2018 11:01 PM, Andres Freund wrote: >>> Hi, >>> >>> On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote: So I've decided to revive the old patch, rebase it to current >>

Re: [HACKERS] Bug in to_timestamp().

> On 18 February 2018 at 18:49, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On 17 February 2018 at 10:02, Arthur Zakirov wrote: > > > On Wed, Feb 14, 2018 at 05:23:53PM +0100, Dmitry Dolgov wrote: > > > > > > SELECT to_timestamp('2000 + JUN', ' /') FROM dual > > > ORA-01830: date format pictu

Re: Better Upgrades

On Tue, Feb 6, 2018 at 01:51:09PM +0100, Daniel Gustafsson wrote: > > On 06 Feb 2018, at 01:09, David Fetter wrote: > > > - pg_upgrade is very much a blocker for on-disk format changes. > > I wouldn’t call it a blocker, but pg_upgrade across an on-disk format change > would be a very different

Re: Hash Joins vs. Bloom Filters / take 2

On 3/1/18 6:52 PM, Tomas Vondra wrote: On 03/02/2018 12:31 AM, Andres Freund wrote: On March 1, 2018 3:22:44 PM PST, Tomas Vondra wrote: On 03/01/2018 11:01 PM, Andres Freund wrote: Hi, On 2018-02-20 22:23:54 +0100, Tomas Vondra wrote: So I've decided to revive the old patch, rebase it

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

Hi Alexander, On 3/1/18 4:26 PM, Alexander Korotkov wrote: On Thu, Mar 1, 2018 at 11:05 PM, David Steele > wrote: I agree with Teodor (upthread, not quoted here) that the documentation could use some editing. I started to do it myself, but quickly realiz

Re: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

Hi, On 2018-02-22 19:48:46 +0300, Nikolay Shaplov wrote: > This is part or my bigger patch > https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m > we've decided to > commit by smaller parts. I've not read that thread. Is this supposed to be a first step

Re: Rewrite of pg_dump TAP tests

Hi, On 2018-02-26 13:15:04 -0500, Stephen Frost wrote: > Attached is a patch (which applies cleaning against a2a2205, but not so > much anymore, obviously, but I will fix after the releases) which > greatly improves the big pg_dump TAP tests. There's probably more which > can be done, but I expec

Re: Removing shm_mq.c's volatile qualifiers

Hi, On 2018-02-12 12:52:32 +1300, Thomas Munro wrote: > From e584628bb846be11a137b5216e955284dfd646a5 Mon Sep 17 00:00:00 2001 > From: Thomas Munro > Date: Thu, 8 Feb 2018 18:50:32 +1300 > Subject: [PATCH] Remove volatile qualifiers from shm_mq.c. > > Since commit 0709b7ee, spinlock primitives i

Re: [HACKERS] Fix warnings and typo in dshash

On 2018-02-12 09:23:43 +1300, Thomas Munro wrote: > On Mon, Sep 4, 2017 at 2:18 PM, Amit Kapila wrote: > > On Sun, Sep 3, 2017 at 2:56 PM, Thomas Munro > > wrote: > >> I think it should be (size_t) 1, not UINT64CONST(1). See attached. > > > > Okay, that makes sense. Do you think we should also

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2018-02-02 19:41:37 +, Simon Riggs wrote: > On 2 February 2018 at 18:46, Robert Haas wrote: > > On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote: > >> In PG11, I propose the following command, sticking mostly to Ants' > >> syntax, and allowing to wait for multiple events before it returns

Re: Parallel Aggregates for string_agg and array_agg

On 2 March 2018 at 10:26, Andres Freund wrote: > On 2017-12-18 03:30:55 +1300, David Rowley wrote: >> Just a handful of aggregates now don't support partial aggregation; >> >> postgres=# select aggfnoid from pg_aggregate where aggcombinefn=0 and >> aggkind='n'; >> aggfnoid >>

Re: Parallel Aggregates for string_agg and array_agg

On 2018-03-02 13:48:00 +1300, David Rowley wrote: > On 2 March 2018 at 10:26, Andres Freund wrote: > > FWIW, I've heard numerous people yearn for json*agg > > I guess it'll need to be PG12 for now. I'd imagine string_agg and > array_agg are more important ones to tick off for now, but I bet many

Re: Documenting PROVE_TESTS in section of TAP tests

On Thu, Mar 01, 2018 at 01:52:09AM -0800, Andres Freund wrote: > Pushed, after replacing "a subset" with "the specified subset". Thanks, Andres. -- Michael signature.asc Description: PGP signature

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

Hi, On 2018-02-28 21:12:42 +0530, Nikhil Sontakke wrote: > Attached are 5 patches split up from the original patch that I had > submitted earlier. In the future you should number them. Right now they appear to be out of order in your email. I suggest using git format-patch, that does all the nec

Re: Optimize Arm64 crc32c implementation in Postgresql

On Thu, Mar 01, 2018 at 01:36:23PM -0800, Andres Freund wrote: > On 2018-01-10 15:09:16 +0900, Michael Paquier wrote: >> There are not enough patches for ARM. > > Nah, not needing arch specific patches is good ;) You know already that I am always impressed by your skills in normalizing things whe

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 2018-02-01 23:51:55 +0100, Tomas Vondra wrote: > On 02/01/2018 03:51 PM, Peter Eisentraut wrote: > > To close out this commit fest, I'm setting both of these patches as > > returned with feedback, as there are apparently significant issues to be > > addressed. Feel free to move them to the next

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

On 2 March 2018 at 08:53, Andres Freund wrote: > Hi, > > On 2018-02-28 21:12:42 +0530, Nikhil Sontakke wrote: > > Attached are 5 patches split up from the original patch that I had > > submitted earlier. > > In the future you should number them. Right now they appear to be out of > order in your

Re: [Patch] Checksums for SLRU files

On 2018-02-02 11:37:34 +1300, Thomas Munro wrote: > > 3. pg_upgrade isn't considered. This patch should provide upgrading SLRUs > > to adopt changed useful size of page. That seems to be hardest patch of > > this patch to be written. > > +1 > > I think we'd want pg_upgrade tests showing an exam

<    1   2   3   >