Re: WIP Patch: Precalculate stable functions, infrastructure v1

Ok! On 02-03-2018 22:56, Andres Freund wrote: Hi, On 2018-03-02 11:22:01 +0300, Marina Polyakova wrote: I fixed the failure that Thomas pointed out to me, and I'm finishing work on it, but it took me a while to study this part of the executor.. I unfortunately think that makes this too

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

Craig Ringer writes: > On 3 March 2018 at 13:08, Peter Eisentraut wrote: >> I think one thing to try would to define a special kind of exception >> that can safely be caught and ignored. Then, input functions can >> communicate benign

Re: psql tab completion for ALTER INDEX SET

On Sat, Mar 3, 2018 at 1:43 AM, Fujii Masao wrote: > On Fri, Mar 2, 2018 at 3:52 PM, Masahiko Sawada wrote: >> Hi, >> >> I found that tab completion for ALTER INDEX SET [tab] doesn't support >> the reloptions of brin and gist. Attached patch adds

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

On 3 March 2018 at 13:08, Peter Eisentraut wrote: > On 1/22/18 21:33, Craig Ringer wrote: > > We don't have much in the way of rules about what input functions can or > > cannot do, so you can't assume much about their behaviour and what must > > / must not be

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

On 2018-03-03 01:55, Tomas Vondra wrote: Hi there, attached is an updated patch fixing all the reported issues (a bit more about those below). Hi, 0007-Track-statistics-for-streaming-spilling.patch won't apply. All the other patches apply ok. patch complaints with: patching file

Re: GSOC 2018 ideas

Got it, Aleksander! Will study these documents carefully! 2018-02-26 4:21 GMT-08:00 Aleksander Alekseev : > Hello Charles, > > > I saw PostgreSQL is selected in GSOC 2018 and pretty interested in the > > ideas of thrift data types support that proposed by you. So, I

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

On 1/22/18 21:33, Craig Ringer wrote: > We don't have much in the way of rules about what input functions can or > cannot do, so you can't assume much about their behaviour and what must > / must not be cleaned up. Nor can you just reset the state in a heavy > handed manner like (say) plpgsql

Re: non-bulk inserts and tuple routing

On 2018-02-22 11:10:57 -0500, Robert Haas wrote: > On Tue, Feb 20, 2018 at 8:06 PM, Amit Langote > wrote: > >> Attached is an updated version for that. > > > > Thanks for updating the patch. > > Committed with a few changes. The big one was that I got rid of the >

Re: heap_lock_updated_tuple_rec can leak a buffer refcount

On Sat, Mar 3, 2018 at 3:26 AM, Tom Lane wrote: > Alexander Kuzmenkov writes: >> Looks like a leak indeed, the fix seems right. > > > Hence, I propose the attached patch. The test lobotomization > (the "if (1) //" change) isn't meant for commit

Re: non-bulk inserts and tuple routing

Hi, On 2018-02-22 11:10:57 -0500, Robert Haas wrote: > On Tue, Feb 20, 2018 at 8:06 PM, Amit Langote > wrote: > >> Attached is an updated version for that. > > > > Thanks for updating the patch. > > Committed with a few changes. The big one was that I got rid of

Re: zheap: a new storage format for PostgreSQL

On 03/03/18 05:03, Robert Haas wrote: On Fri, Mar 2, 2018 at 5:35 AM, Alexander Korotkov wrote: I would propose "zero-bloat heap" disambiguation of zheap. Seems like fair enough explanation for me without need to rename :) It will be possible to bloat a zheap

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 7:06 PM, Aleksander Alekseev wrote: > Hello Amit, > >> Sometime back Robert has proposed a solution to reduce the bloat in >> PostgreSQL [1] which has some other advantages of its own as well. To >> recap, in the existing heap, we always create a

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

On Fri, 02 Mar 2018 17:17:29 -0500 Tom Lane wrote: > But by the same token, analyze only looked at 0.0006 of the pages. It's > nice that for you, that's enough to get a robust estimate of the density > everywhere; but I have a nasty feeling that that won't hold good for >

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

On 3/2/18 8:54 PM, Tomas Vondra wrote: > On 03/03/2018 02:37 AM, David Steele wrote: >> On 3/2/18 8:01 PM, Andres Freund wrote: >>> On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: That is somewhat misleading, I think. You're right the last version was submitted on 2018-01-19, but the

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

On 03/03/2018 02:37 AM, David Steele wrote: > On 3/2/18 8:01 PM, Andres Freund wrote: >> On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: >>> That is somewhat misleading, I think. You're right the last version was >>> submitted on 2018-01-19, but the next review arrived on 2018-01-31, i.e. >>>

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

On 3/2/18 8:01 PM, Andres Freund wrote: > On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: >> That is somewhat misleading, I think. You're right the last version was >> submitted on 2018-01-19, but the next review arrived on 2018-01-31, i.e. >> right at the end of the CF. So it's not like the

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

On 2018-03-03 02:34:06 +0100, Tomas Vondra wrote: > On 03/03/2018 02:01 AM, Andres Freund wrote: > > On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: > >> That is somewhat misleading, I think. You're right the last version > >> was submitted on 2018-01-19, but the next review arrived on > >>

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

On 03/03/2018 02:01 AM, Andres Freund wrote: > On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: >> That is somewhat misleading, I think. You're right the last version >> was submitted on 2018-01-19, but the next review arrived on >> 2018-01-31, i.e. right at the end of the CF. So it's not like

Re: [COMMITTERS] pgsql: Add much-more-extensive TAP tests for pgbench.

Peter Eisentraut writes: > On 9/8/17 09:32, Tom Lane wrote: >> Add much-more-extensive TAP tests for pgbench. > The use of done_testing() raises the requirement of Test::More from 0.82 > to 0.87. That seems OK, but we should update the version requirement in >

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

On 03/03/2018 01:56 AM, Tom Lane wrote: > Tomas Vondra writes: >> OK, time to revive this old thread ... [ scalarineqsel may fall over when used by extension operators ] > >> Attached is a minimal fix adding a flag to convert_numeric_to_scalar, >> tracking

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

On 2018-03-03 02:00:46 +0100, Tomas Vondra wrote: > That is somewhat misleading, I think. You're right the last version was > submitted on 2018-01-19, but the next review arrived on 2018-01-31, i.e. > right at the end of the CF. So it's not like the patch was sitting there > with unresolved

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

On 03/02/2018 09:05 PM, Andres Freund wrote: > Hi, > > On 2018-03-01 21:39:36 -0500, David Steele wrote: >> On 3/1/18 9:33 PM, Tomas Vondra wrote: >>> On 03/02/2018 02:12 AM, Andres Freund wrote: Hm, this CF entry is marked as needs review as of 2018-03-01 12:54:48, but I don't see a

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

Tomas Vondra writes: > OK, time to revive this old thread ... >>> [ scalarineqsel may fall over when used by extension operators ] > Attached is a minimal fix adding a flag to convert_numeric_to_scalar, > tracking when it fails because of unsupported data type. If

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

Hi there, attached is an updated patch fixing all the reported issues (a bit more about those below). The main change in this patch version is reworked logging of subxact assignments, which needs to be done immediately for incremental decoding to work properly. The previous patch versions did

Re: [COMMITTERS] pgsql: Add much-more-extensive TAP tests for pgbench.

On 9/8/17 09:32, Tom Lane wrote: > Add much-more-extensive TAP tests for pgbench. > > Fabien Coelho, reviewed by Nikolay Shaplov and myself The use of done_testing() raises the requirement of Test::More from 0.82 to 0.87. That seems OK, but we should update the version requirement in

Re: line_perp() (?-|) is broken.

Kyotaro HORIGUCHI writes: > I happend to see a strange geometric calcualtion on master/HEAD. > ... > Instead, calculating inner product of the two direction vectors > works as expected. > (l1->A * l2->A) + (l1->B * l2->B) == 0 This seems to be a strict subset

Re: JIT compiling with LLVM v11

On 2018-03-02 16:29:54 -0800, Andres Freund wrote: > > #include > > #include > > > > It seems that it was intended that way anyway, since llvmjit.h contains > > its own provisions for extern C. > > Hrmpf, yea, I broke that the third time now. I'm actually inclined to > add an appropriate

Re: [HACKERS] path toward faster partition pruning

On 3 March 2018 at 04:47, Robert Haas wrote: > On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote > wrote: >> 2. Removing redundant clauses from each list, that is, >>remove_redundant_clauses() to produce lists with just one member per >>

Re: JIT compiling with LLVM v11

Hi, On 2018-03-02 19:13:01 -0500, Peter Eisentraut wrote: > On 3/1/18 03:02, Andres Freund wrote: > > I've pushed a revised version of my JIT patchset. > > The git tree is at > > https://git.postgresql.org/git/users/andresfreund/postgres.git > > in the jit branch > > > >

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

On Thu, 01 Mar 2018 18:49:20 -0500 Tom Lane wrote: > The sticking point in my mind right now is, if we do that, what to do with > VACUUM's estimates. If you believe the argument in the PDF that we'll > necessarily overshoot reltuples in the face of declining true density, >

Re: JIT compiling with LLVM v11

On 3/1/18 03:02, Andres Freund wrote: > I've pushed a revised version of my JIT patchset. > The git tree is at > https://git.postgresql.org/git/users/andresfreund/postgres.git > in the jit branch > >

Re: Online enabling of checksums

On 03/02/2018 11:01 PM, Magnus Hagander wrote: > On Fri, Mar 2, 2018 at 5:50 PM, Tomas Vondra > > wrote: > > > > On 03/02/2018 02:35 PM, Magnus Hagander wrote: > > > > > > On Wed, Feb 28, 2018 at 6:06 PM, Robert

Re: Documenting commitfest Rules

On 2018-03-02 18:08:00 -0500, Tom Lane wrote: > Andres Freund writes: > > - that there's a single point documenting the state of the patch, to > > avoid situations where different people interpret a thread differently > > without noticing. > > I think that third point is

Re: Testing "workers launched" in expected output? Really?

On 3 March 2018 at 04:27, Robert Haas wrote: > On Fri, Mar 2, 2018 at 3:13 PM, Tom Lane wrote: > > My point is that just because it isn't falling over on > > relatively-lightly-loaded buildfarm machines doesn't mean that it won't > > fall over in other

Re: Documenting commitfest Rules

Andres Freund writes: > Thus I'm trying to summarize my understanding in this email. It probably > doesn't 100% match other people's understanding. After we've resolved > those differences, we should update the wiki page, and delete outdated > content. > Commitfests primarily

Re: [HACKERS] log_destination=file

On Fri, Mar 2, 2018 at 7:29 PM, Tom Lane wrote: > Robert Haas writes: > > On Mon, Jan 22, 2018 at 4:25 PM, Tomas Vondra > > wrote: > >> Sorry for the naive question, but which of these bottlenecks are we > >> actually

Documenting commitfest Rules

Hi Tomas, Everyone. This seems like a good thing to discuss separately from the original thread. On 2018-03-02 22:06:32 +0100, Tomas Vondra wrote: > Can you guys please point me to the CF rules that say this? Because my > understanding (and not just mine, AFAICS) was obviously different. >

Re: [PATCH] Opclass parameters

On 02.03.2018 19:12, Nikolay Shaplov wrote: В письме от 1 марта 2018 23:02:20 пользователь Oleg Bartunov написал: 2. Your patch does not provide any example of your new tool usage. In my prototype patch I've shown the implementation of opclass options for intarray. May be you should do the

Re: [HACKERS] [POC] Faster processing at Gather node

Hello Robert, On Fri, March 2, 2018 12:22 pm, Robert Haas wrote: > On Wed, Feb 28, 2018 at 10:06 AM, Robert Haas > wrote: >> [ latest patches ] > > Committed. Thanks for the review. Cool :) There is a typo, tho: + /* +* If the counterpary is known to have

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

David Gould writes: > I'm confused at this point, I provided a patch that addresses this and a > test case. We seem to be discussing everything as if we first noticed the > issue. Have you reviewed the patch and and attached analysis and tested it? > Please commment on that?

Re: prokind column (was Re: [HACKERS] SQL procedures)

On 2/28/18 17:37, Peter Eisentraut wrote: > On 2/28/18 15:45, Tom Lane wrote: >> I have reviewed this patch and attach an updated version below. >> I've rebased it up to today, fixed a few minor errors, and adopted >> most of Michael's suggestions. Also, since I remain desperately >> unhappy with

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 5:50 PM, Tomas Vondra wrote: > > > On 03/02/2018 02:35 PM, Magnus Hagander wrote: > > > > > > On Wed, Feb 28, 2018 at 6:06 PM, Robert Haas > > wrote: > > > > On Sun, Feb 25, 2018 at

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

On Fri, 2 Mar 2018 18:47:44 +0300 Alexander Kuzmenkov wrote: > The calculation I made for the first step applies to the next steps too, > with minor differences. So, the estimate increases at each step. Just > out of interest, I plotted the reltuples for 60 steps,

Re: heap_lock_updated_tuple_rec can leak a buffer refcount

Alexander Kuzmenkov writes: > Looks like a leak indeed, the fix seems right. Yup, it's a leak. It's hard to hit because you need to be starting with an update of a tuple in an all-visible page; otherwise we never pin the vm page so there's nothing to leak. But if

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

2018-03-02 3:43 GMT+01:00 Pavel Stehule : > > > 2018-03-02 3:38 GMT+01:00 Andres Freund : > >> On 2018-03-02 03:13:04 +0100, Pavel Stehule wrote: >> > 2018-03-01 23:10 GMT+01:00 Andres Freund : >> > >> > > On 2018-01-23 17:08:56

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

Hi 2018-03-01 21:14 GMT+01:00 David Steele : > 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

Re: Cached/global query plans, autopreparation

2018-03-02 21:51 GMT+01:00 Tom Lane : > Andres Freund writes: > > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: > >> While I have heard people complain about how other databases cache > >> prepare plans, I have heard few complaints about the Postgres

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

On 03/02/2018 09:21 PM, David Steele wrote: > On 3/2/18 3:06 PM, Robert Haas wrote: >> On Thu, Mar 1, 2018 at 9:33 PM, Tomas Vondra >> wrote: >>> Ah, apologies - that's due to moving the patch from the last CF (it was >>> marked as RWF so I had to reopen it before

Re: Cached/global query plans, autopreparation

Andres Freund writes: > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: >> While I have heard people complain about how other databases cache >> prepare plans, I have heard few complaints about the Postgres approach, >> and I haven't even heard of people asking to control

Re: [HACKERS] Creating backup history files for backups taken from standbys

Hi, On 3/2/18 1:03 PM, Fujii Masao wrote: > On Fri, Mar 2, 2018 at 1:07 PM, Michael Paquier wrote: > >> We would talk about two backups running >> simultaneously on a standby, which would overlap with each other to >> generate a file aimed only at being helpful for

Re: Cached/global query plans, autopreparation

On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote: > Postgres uses a conservative method for reusing plans with previous > constants, as described in the PREPARE manual page: > > https://www.postgresql.org/docs/10/static/sql-prepare.html > Prepared statements can use generic plans

Re: Cached/global query plans, autopreparation

On Thu, Feb 15, 2018 at 03:00:17PM +0100, Shay Rojansky wrote: > Just wanted to say that I've seen more than 10% improvement in some real-world > application when preparation was done properly. Also, I'm assuming that > implementing this wouldn't involve "rewriting substantial part of Postgres >

Re: Testing "workers launched" in expected output? Really?

On Fri, Mar 2, 2018 at 3:13 PM, Tom Lane wrote: > My point is that just because it isn't falling over on > relatively-lightly-loaded buildfarm machines doesn't mean that it won't > fall over in other environments. It doesn't mean it will, either. > I should think that your

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

On 3/2/18 3:06 PM, Robert Haas wrote: > On Thu, Mar 1, 2018 at 9:33 PM, Tomas Vondra > wrote: >> Ah, apologies - that's due to moving the patch from the last CF (it was >> marked as RWF so I had to reopen it before moving it). I'll submit a new >> version of the

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

On Fri, Mar 2, 2018 at 1:47 AM, Fabien COELHO wrote: > On the "adequate return" point, my opinion is that currently pgbench is just > below the feature set needed to be generally usable, so not improving it is > a self-fullfilling ensurance that it will not be used further.

Re: Testing "workers launched" in expected output? Really?

Robert Haas writes: > On Fri, Mar 2, 2018 at 2:28 PM, Tom Lane wrote: >> ... now I am on the warpath. I have no idea whether or not the diff >> here is significant --- maybe it is --- but I am desperately unhappy >> that we have expected-output files

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

On Thu, Mar 1, 2018 at 9:33 PM, Tomas Vondra wrote: > Ah, apologies - that's due to moving the patch from the last CF (it was > marked as RWF so I had to reopen it before moving it). I'll submit a new > version of the patch shortly, please mark it as WOA until then.

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

Hi, On 2018-03-01 21:39:36 -0500, David Steele wrote: > On 3/1/18 9:33 PM, Tomas Vondra wrote: > > On 03/02/2018 02:12 AM, Andres Freund wrote: > > > Hm, this CF entry is marked as needs review as of 2018-03-01 12:54:48, > > > but I don't see a newer version posted? > > > > > > > Ah, apologies

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

Julian Markwort writes: > Andres Freund wrote on 2018-03-02: >> and I'd checked that 1.5 already exists. But you just renamed the file, >> presumably because it's essentially rewriting the whole file? I'm not >> sure I'm a big fan of doing so, because that makes

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On Fri, Mar 2, 2018 at 1:20 PM, Robert Haas wrote: > On Fri, Mar 2, 2018 at 5:35 AM, Etsuro Fujita > wrote: >> Agreed. Better safe than sorry, so I disabled autovacuum for all the tables >> created in the postgres_fdw regression test, except

Re: Testing "workers launched" in expected output? Really?

On Fri, Mar 2, 2018 at 2:28 PM, Tom Lane wrote: > So buildfarm member piculet just fell over like this: > > == pgsql.build/src/test/regress/regression.diffs > == > *** >

Re: WIP Patch: Precalculate stable functions, infrastructure v1

Hi, On 2018-03-02 11:22:01 +0300, Marina Polyakova wrote: > I fixed the failure that Thomas pointed out to me, and I'm finishing work on > it, but it took me a while to study this part of the executor.. I unfortunately think that makes this too late for v11, and we should mark this as returned

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

On 2018-03-02 12:22:15 +0300, Ildus Kurbangaliev wrote: > On Thu, 1 Mar 2018 20:34:11 -0800 > Andres Freund wrote: > > - Custom compression methods > > > > RFC. While marked as ready for committer, I think this is mostly > > because some high level design input is needed.

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

Andres Freund wrote on 2018-03-02: > Yea, I misread the diff to think you added a conflicting version. Due > to: > -DATA =3D pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \ > +DATA =3D pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \ > and I'd checked that 1.5 already

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

Andres Freund writes: > Yea, I misread the diff to think you added a conflicting version. Due > to: > -DATA =3D pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \ > +DATA =3D pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \ > and I'd checked that 1.5

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

Bcc: Reply-To: Hi, On 2018-03-02 10:47:01 +0100, Fabien COELHO wrote: > For instance, I used extensively tps throttling, latencies and timeouts > measures when developping and testing the checkpointer sorting & throttling > patch. That doesn't say that much about proposed feature additions,

Re: [HACKERS] pgbench randomness initialization

Fabien COELHO writes: >> Hm ... so I tried to replicate this problem, and failed to: the log files >> get made under the VPATH build directory, as desired, even without this >> patch. Am I doing something wrong, or is this platform-dependent somehow? > As I recall, it

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

Hi, On 2018-03-02 11:06:12 +0100, Fabien COELHO wrote: > A lot of patches do not even get a review: no immediate interest or more > often no ressources currently available, patch stays put, I'm fine with > that. Well, even if that's the case that's not free of cost to transport them from fest to

Re: [HACKERS] Early locking option to parallel backup

On 2018-03-02 11:42:06 -0500, Robert Haas wrote: > On Fri, Mar 2, 2018 at 2:29 AM, Andres Freund wrote: > > There seems to to be consensus in this thread that the approach Lucas > > proposed isn't what we want, and that instead some shared lock based > > approach is desirable.

Re: [Patch] Checksums for SLRU files

On 2018-03-02 11:49:05 -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 8:25 PM, Andres Freund wrote: > > 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

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

On 2018-03-02 18:07:32 +0100, Julian Markwort wrote: > Andres Freund wrote on 2018-03-01: > > I think the patch probably doesn't apply anymore, due to other changes > > to pg_stat_statements since its posting. Could you refresh? > > pgss_plans_v02.patch applies cleanly to master, there were no

Testing "workers launched" in expected output? Really?

So buildfarm member piculet just fell over like this: == pgsql.build/src/test/regress/regression.diffs == *** /home/andres/build/buildfarm-piculet/HEAD/pgsql.build/../pgsql/src/test/regress/expected/select_parallel.out 2018-02-28 16:10:01.986941733 +

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

Hi, On 2018-03-02 20:22:21 +0300, Nikolay Shaplov wrote: > Since I get a really big patch as a result, it was decided to commit it in > parts. I get that, but I strongly suggest not creating 10 loosely related threads, but keeping it as a patch series in one thread. It's really hard to follow

Re: Kerberos test suite

Thomas Munro writes: > Peter Eisentraut wrote: >> On 2/27/18 00:56, Thomas Munro wrote: >>> FWIW it passes for me if I add this: >>> >>> +elsif ($^O eq 'freebsd') >>> +{ >>> + $krb5_bin_dir = '/usr/local/bin'; >>> +

Re: Kerberos test suite

Michael Paquier writes: > On Wed, Feb 14, 2018 at 09:27:04AM -0500, Peter Eisentraut wrote: > >> (If it appears to hang for you in the "setting up Kerberos" step, you >> might need more entropy/wait a while. That problem appears to be >> limited to some virtual machine

Re: IndexJoin memory problem using spgist and boxes

Hi Anton, I can reproduce the high memory consumption with your queries. Looking at the patch, I see that you changed the lifetime of the temporary context from per-tuple to per-index-scan. It is not obvious that this change is correct. Could you explain, what memory context are involved in

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 1, 2018 at 4:52 PM, Robert Haas wrote: > This is not a full review, but I'm out of time for right now. Another thing I see here now is that create_grouping_paths() and create_child_grouping_paths() are extremely similar. Isn't there some way we can refactor

Re: [HACKERS] log_destination=file

Robert Haas writes: > On Mon, Jan 22, 2018 at 4:25 PM, Tomas Vondra > wrote: >> Sorry for the naive question, but which of these bottlenecks are we >> actually hitting? I don't recall dealing with an actual production >> system where the log

Re: [HACKERS] log_destination=file

On Mon, Jan 22, 2018 at 4:25 PM, Tomas Vondra wrote: > Sorry for the naive question, but which of these bottlenecks are we > actually hitting? I don't recall dealing with an actual production > system where the log collector would be an issue, so I don't have a very

Re: WIP: a way forward on bootstrap data

John Naylor writes: > Version 8, rebased against 76b6aa41f41d. I took a preliminary look through this, without yet attempting to execute the script against HEAD. I have a few thoughts: * I'm inclined not to commit the conversion scripts to the repo. I doubt there are third

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On Fri, Mar 2, 2018 at 5:35 AM, Etsuro Fujita wrote: > Agreed. Better safe than sorry, so I disabled autovacuum for all the tables > created in the postgres_fdw regression test, except the ones with no data > modification created in the sections "test handling of

Re: [PATCH] Verify Checksums during Basebackups

On Fri, Mar 2, 2018 at 6:23 AM, Magnus Hagander wrote: > Another quick note -- we need to assert that the size of the buffer is > actually divisible by BLCKSZ. I don't think it's a common scenario, but it > could break badly if somebody changes BLCKSZ. Either that or perhaps

Re: [HACKERS] Creating backup history files for backups taken from standbys

On Fri, Mar 2, 2018 at 12:26 PM, Andres Freund wrote: > Hi! > > On 2018-03-02 02:29:13 +0900, Fujii Masao wrote: >> On Fri, Feb 2, 2018 at 2:06 PM, Michael Paquier >> wrote: >> > On Fri, Feb 02, 2018 at 12:47:26AM +0900, Fujii Masao wrote: >> >> The

Re: [HACKERS] Creating backup history files for backups taken from standbys

On Fri, Mar 2, 2018 at 1:07 PM, Michael Paquier wrote: > On Fri, Mar 02, 2018 at 02:29:13AM +0900, Fujii Masao wrote: >> + * write a backup history file with the same name. >> >> So more than one backup history files with the same name >> but the diffferent content can be

Re: heap_lock_updated_tuple_rec can leak a buffer refcount

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Looks like a leak indeed, the fix seems right.

Re: [HACKERS] [POC] Faster processing at Gather node

On Wed, Feb 28, 2018 at 10:06 AM, Robert Haas wrote: > [ latest patches ] Committed. Thanks for the review. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

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

В письме от 1 марта 2018 16:15:32 пользователь Andres Freund написал: > > This is part or my bigger patch > > https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#21464 > > 19.veIEZdk4E4@x200m we've decided to commit by smaller parts. > > I've not read that thread. Is this

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 03/02/2018 04:29 AM, Andres Freund wrote: > Hi, > > On 2018-02-24 23:01:59 +0100, Tomas Vondra wrote: >> Sadly, this patch series does not seem to move forward very much, and >> I'm not sure how to change that :-/ > > What's your estimate about the patchset's maturity? > It's dying of old

Re: WIP: BRIN multi-range indexes

On 03/02/2018 05:08 AM, Tom Lane wrote: > Andres Freund writes: >> On 2018-02-25 01:30:47 +0100, Tomas Vondra wrote: >>> Note: Currently, this only works with float8-based data types. >>> Supporting additional data types is not a big issue, but will >>> require extending the

Re: jsonlog logging only some messages?

On 27 February 2018 at 16:50, Greg Stark wrote: > On 27 February 2018 at 02:04, Michael Paquier wrote: >> On Mon, Feb 26, 2018 at 05:38:56PM +, Greg Stark wrote: >> >> Hm. I have just loaded jsonlog on a 9.6 and 10 instance where >> log_checkpoints is

Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

Andres Freund wrote on 2018-03-01: > I think the patch probably doesn't apply anymore, due to other changes > to pg_stat_statements since its posting. Could you refresh? pgss_plans_v02.patch applies cleanly to master, there were no changes to pg_stat_statements since the copyright updates at the

Re: New gist vacuum.

> 2 марта 2018 г., в 21:25, Tom Lane написал(а): > > Andrey Borodin writes: >> So, I agree, unconditional counting is a good idea. Here's the v3 patch. > > Pushed with trivial cosmetic adjustments. > > I've marked the CF entry as committed; please

Re: Rewrite of pg_dump TAP tests

Andres, * Andres Freund (and...@anarazel.de) wrote: > 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

Re: [PROPOSAL] Nepali Snowball dictionary

On Thu, Mar 01, 2018 at 10:23:11PM -0800, Andres Freund wrote: > What is that entry for, if I may ask? We need to wait for them to merge > it, then sync the snowball code, including the nepali dictionary. This > doesn't realistically seem doable for this commitfest. Therefore I think > this

Re: Online enabling of checksums

On 03/02/2018 02:35 PM, Magnus Hagander wrote: > > > On Wed, Feb 28, 2018 at 6:06 PM, Robert Haas > wrote: > > On Sun, Feb 25, 2018 at 9:54 AM, Magnus Hagander > > wrote: > >

Re: [Patch] Checksums for SLRU files

On Thu, Mar 1, 2018 at 8:25 PM, Andres Freund wrote: > 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

Re: Rangejoin rebased

On Fri, Mar 2, 2018 at 11:12 AM, Alexander Kuzmenkov wrote: > On 16.01.2018 10:49, Jeff Davis wrote: >> My proposed fix is to make an internal opfamily identical to the >> external one, such that it's not recognized as part of the same EC, >> and the planner won't try

Re: psql tab completion for ALTER INDEX SET

On Fri, Mar 2, 2018 at 3:52 PM, Masahiko Sawada wrote: > Hi, > > I found that tab completion for ALTER INDEX SET [tab] doesn't support > the reloptions of brin and gist. Attached patch adds "buffering", > "pages_per_range" and "autosummarize" options. Thanks for the patch!

Re: [HACKERS] Early locking option to parallel backup

On Fri, Mar 2, 2018 at 2:29 AM, Andres Freund wrote: > There seems to to be consensus in this thread that the approach Lucas > proposed isn't what we want, and that instead some shared lock based > approach is desirable. As that has been the case for ~1.5 months, I > propose

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 2:44 AM, Andres Freund wrote: > And even more so, I'm not even sure it makes sense to try to get this > into v11. This is a medium-large complicated feature, submitted to the > last CF for v11. That's pretty late. Now, Magnus is a committer, but >

  1   2   >