Re: [HACKERS] Proposal: Local indexes for partitioned table

Hi Jesper, Thanks for reviewing. Jesper Pedersen wrote: > I have been looking at the "CREATE INDEX ... ONLY" syntax, and I think it > could cause some confusion due to the "Note" described in create_index.sgml. > > An alternative, maybe crazy, could be to treat a partitioned index as one; >

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

Mark Dilger wrote: > I understand project policy to allow elog for error conditions that will be > reported > in "can't happen" type situations, similar to how an Assert would be used. > For > conditions that can happen through (mis)use by the user, ereport is > appropriate. > Not knowing

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

A typo in all the messages the patch adds: "to an another" -> "to another" -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: PG10.1 autovac killed building extended stats

Justin Pryzby wrote: > On Fri, Nov 17, 2017 at 03:43:52PM -0600, Justin Pryzby wrote: > > On Fri, Nov 17, 2017 at 01:36:00PM -0300, Alvaro Herrera wrote: > > > If I recall things correctly, the "continue" should be executed > > > regardless of IsAutoVacuu

Re: Code cleanup patch submission for extended_stats.c

Mark Dilger wrote: > > > On Nov 25, 2017, at 2:05 PM, Tom Lane wrote: > > > > Mark Dilger writes: > >> It looks to me like Alvaro introduced this in the original version of the > >> file which > >> was created in commit

Re: [HACKERS] Custom compression methods

Tomas Vondra wrote: > On 11/30/2017 04:20 PM, Ildus Kurbangaliev wrote: > > CREATE COMPRESSION METHOD ts1 FOR tsvector HANDLER > > tsvector_compression_handler; > > Understood. Good to know you've considered it, and I agree it doesn't > need to be there from the start (which makes the patch

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

Alexey Kondratov wrote: > I have rebased my branch and squashed all commits into one, since the > patch is quite small. Everything seems to be working fine now, patch > passes all regression tests. On a *very* quick look, please use an enum to return from NextCopyFrom rather than 'int'. The

Re: [HACKERS] Proposal: Local indexes for partitioned table

Michael Paquier wrote: > On Wed, Nov 15, 2017 at 2:49 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > Here's the remaining bits, rebased. > > At least patch 3 has conflicts with HEAD. I am moving this patch to > next CF per a lack of reviews, switching

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > I wonder if it should be this patches job to alter the code in > get_relation_info() which causes the indexes not to be loaded for > partitioned tables: > > /* > * Make list of indexes. Ignore indexes on system catalogs if told to. > * Don't bother with indexes for an

Re: Errands around AllocateDir()

Tom Lane wrote: > Yeah, agreed. The only thing I'm concerned about back-patching is > the places where a wrong errno might be reported. If we're currently reporting "could not open dir: Success" then backpatching such a fix is definitely an improvement. OTOH if currently we have opendir()

Re: [HACKERS] Proposal: Local indexes for partitioned table

Robert Haas wrote: > On Fri, Dec 15, 2017 at 5:18 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > We have two options for marking valid: > > > > 1. after each ALTER INDEX ATTACH, verify whether the set of partitions > > that contain the index is compl

Re: Transform for pl/perl

A few very minor comments while quickly paging through: 1. non-ASCII tests are going to cause problems in one platform or another. Please don't include that one. 2. error messages a) please use ereport() not elog() b) conform to style guidelines: errmsg() start with lowercase, others

Re: [HACKERS] Surjective functional indexes

Konstantin Knizhnik wrote: > If you still thing that additional 16 bytes per relation in statistic is too > high overhead, then I will also remove autotune. I think it's pretty clear that these additional bytes are excessive. -- Álvaro Herrerahttps://www.2ndQuadrant.com/

Re: [HACKERS] [PATCH] Improve geometric types

Does this patch series fix bug #14971? https://www.postgresql.org/message-id/20171213172806.20142.73...@wrigleys.postgresql.org Eric: see https://www.postgresql.org/message-id/CAE2gYzzvp=uvpw4fytoaevyk-wze4jw7u2s1glrok35mr1-...@mail.gmail.com for last version of patch. Motivation for patch is at

Re: [HACKERS] Proposal: Local indexes for partitioned table

After this discussion, this is how I see things working: 1. pg_dump a) creates indexes on partitions normally b) once all existing indexes are done, index on parent is created, with ONLY. No cascading occurs, no indexes are attached. c) ATTACH is run for each existing partition

Re: [HACKERS] Add support for tuple routing to foreign partitions

InitResultRelInfo becomes unintelligible after this patch -- it was straightforward but adding partition_root makes things shaky. Please add a proper comment indicating what each argument is. (I wonder why this function needs a local variable "partition_check" -- seems pointless). -- Álvaro

Re: Notes about Pl/PgSQL assignment performance

Andrey Zhidenkov wrote: > When I run this test in 2 threads I expect that running time will be the > same, because PostgreSQL will fork process for the second connection and > this process will be served by a separate CPU core because I have more than > 2 cores. > Yes, IMMUTABLE flag helps, but I

Re: MemoryContextCreate change in PG 11 how should contexts be created

Paul Ramsey wrote: > Our use of MemoryContextCreate is solely in order to get use > MemoryContextDelete as a callback so that, at the end of a statement, > we can clean up externally allocated memory that we're holding in a > cache. You should not use MemoryContextCreate at all -- it's somewhat

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hmm, so I'm now unsure what the actual proposals for handling pg_dump are. We seem to have the following three proposals: 1. Alvaro: use CREATE INDEX ON ONLY (not recursive ), followed by CREATE INDEX ON , followed by ALTER INDEX ATTACH PARTITION . I provide an ALTER INDEX DETACH

Re: [HACKERS] Proposal: Local indexes for partitioned table

Robert Haas wrote: > On Thu, Nov 30, 2017 at 7:02 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > Great question. So you're thinking that the planner might have an > > interest in knowing what indexes are defined at the parent table level &

Re: [HACKERS] Proposal: Local indexes for partitioned table

Robert Haas wrote: > On Fri, Dec 15, 2017 at 4:02 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > > 3. Robert's: use CREATE INDEX ON ONLY , which creates a shell > >index on parent only (no recursion), followed by CREATE INDEX ON > >. DETACH i

Re: vacuum vs heap_update_tuple() and multixactids

Andres Freund wrote: > I think the bugfix is going to have to essentially be something similar > to FreezeMultiXactId(). I.e. when reusing an old tuple's xmax for a new > tuple version, we need to prune dead multixact members. I think we can > do so unconditionally and rely on multixact id

Re: [HACKERS] replace GrantObjectType with ObjectType

Peter Eisentraut wrote: > On 12/15/17 17:34, Michael Paquier wrote: > > On Sat, Dec 16, 2017 at 2:39 AM, Peter Eisentraut > > wrote: > > That's the whole point of not having "default" in the switches, no? > > Any object additions would be caught at compilation

Re: PG10.1 autovac killed building extended stats

Justin Pryzby wrote: > After adding extended/MV stats to a few of our tables a few days ago, it looks > like I wasn't been paying attention and this first crashed 2 nights ago. Why > at 1am? not sure. I have an "reindex" job which runs at 1am, and an > vacuum/analyze job which runs at 2am, but

Re: PG10.1 autovac killed building extended stats

Justin Pryzby wrote: > Core was generated by `postgres: autovacuum worker process gtt > '. > Program terminated with signal 11, Segmentation fault. > #0 statext_ndistinct_build (totalrows=300, numrows=300, rows=0x21df3e8, > attrs=, stats=0x0) at mvdistinct.c:103 > 103

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > On 15 November 2017 at 01:09, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > if a > > partition exists which *doesn't* have the index, restoring things this > > way would create the index in that partition too, which is unwanted > > b

Re: [HACKERS] Pluggable storage

Hmm. Am I reading it right that this discussion led to moving essentially all code from tqual.c to heapam? Given the hard time we've had to get tqual.c right, it seems fundamentally misguided to me to require that every single storage AM reimplements all the visibility routines. I think that

Re: [HACKERS] Proposal: Local indexes for partitioned table

Simon Riggs wrote: > On 13 November 2017 at 12:55, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > Somehow I managed to include an unrelated patch as attachment. Here's > > another attempt (on which I also lightly touched ddl.sgml with relevant > > changes).

Re: [HACKERS] Proposal: Local indexes for partitioned table

Alvaro Herrera wrote: > Simon Riggs wrote: > > On 13 November 2017 at 12:55, Alvaro Herrera <alvhe...@alvh.no-ip.org> > > wrote: > > > Somehow I managed to include an unrelated patch as attachment. Here's > > > another attempt (on which I also lightly touch

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > So, then this patch is only really intended as a syntax shortcut for > mass adding of indexes to each partition? This patch is intended to serve as a basis on which to construct further features, just like every other patch we apply. > I feel like we could do better here

Re: [HACKERS] Custom compression methods

Tomas Vondra wrote: > On 12/01/2017 08:48 PM, Alvaro Herrera wrote: > > Maybe our dependency code needs to be extended in order to support this. > > I think the current logic would drop the column if you were to do "DROP > > COMPRESSION .. CASCADE", but I'm not

Re: Speeding up pg_upgrade

Tom Lane wrote: > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > It seems pretty clear to me that we should somehow transfer stats from > > the old server to the new one. Shouldn't it just be a matter of > > serializing the MCV/histogram/ndistinct values, then ha

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hello, Andres Freund wrote: > On 2017-12-06 17:23:55 -0300, Alvaro Herrera wrote: > > > I've played around quite some with the attached patch. So far, after > > > applying the second patch, neither VACUUM nor VACUUM FULL / CLUSTER make > > > the situation worse f

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

I think you've done a stellar job of identifying what the actual problem was. I like the new (simpler) coding of that portion of HeapTupleSatisfiesVacuum. freeze-the-dead is not listed in isolation_schedule; an easy fix. I confirm that the test crashes with an assertion failure without the code

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

pport, Remote DBA, Training & Services >From 9ac665638c86460f0b767628203f8bf28df35e49 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera <alvhe...@alvh.no-ip.org> Date: Wed, 6 Dec 2017 16:44:25 -0300 Subject: [PATCH 1/2] tweaks for 0002 --- src/backend/access/heap/heapam.c | 67 +++-

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > ATTACH/REPLACE sounds fine. My objection was more about the > DETACH/ATTACH method to replace an index. So what happens if you do ALTER INDEX .. ATTACH and you already have another index in that partition that is attached to the same parent in the index? With my code, what

Re: [HACKERS] Secondary index access optimizations

Konstantin Knizhnik wrote: > > > On 30.11.2017 05:16, Michael Paquier wrote: > > On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik > > wrote: > > > Concerning broken partition_join test: it is "expected" failure: my patch > > > removes from the plans redundant

Re: [HACKERS] replace GrantObjectType with ObjectType

Peter Eisentraut wrote: > On 12/19/17 19:56, Michael Paquier wrote: > > -stringify_adefprivs_objtype(GrantObjectType objtype) > > +stringify_adefprivs_objtype(ObjectType objtype) > > [...] > > +default: > > +elog(ERROR, "unrecognized grant object type: %d", (int) > > objtype);

Re: [HACKERS] Proposal: Local indexes for partitioned table

Great, thanks for the input. pg_dump behaves as described upthread -- thanks David and Robert for the input. I did this by injecting a fake "INDEX ATTACH" object in pg_dump's model, which depends on the index-on-parent-table; which in turn depends on the index-on-partition. Because of the

Re: Cost Model

neto brpr wrote: > Dear David > I have read documentation that you send, but it has only sequential page > cost and random page cost parameters. What I need, would be a model of > custo for Differentiate Read/Write (sequential and random), because in SSDs > the reads and writes have different

Re: --enable-ccache configure option

Andres Freund wrote: > > On Fri, May 4, 2018 at 1:58 PM, Andres Freund wrote: > > > ISTM --enable-ccache would simplify setup for a number of people? And it > > > shouldn't be hard to implement. > > > > What exactly would it do? I use ccache all the time, have for years, >

perlcritic (was Re: pgsql: Fix precedence problem in new Perl code.)

Moving discussion to -hackers list. Mike Blackwell wrote: > I didn't see a .perlcriticrc file in the project, so ran with our local > settings. > > With those, perlcritic is pretty unhappy, even at -4, though I don't see > anything that pops out as potentially bug-inducing. Uh, we've certainly

Re: VM map freeze corruption

Pavan Deolasee wrote: > I wonder if we should just avoid initialising those variables at the top > and take compiler's help to detect any missed branches. That way, we shall > know exactly why and where we are making them true/false. I also think that > we should differentiate between scenarios

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Hello, Fabien COELHO wrote: > > Looking over the diff, I find that this patch tries to do too much and > > needs to be split up. > > Yep, I agree that it would help the reviewing process. On the other hand I > have bad memories about maintaining dependent patches which interfere >

Re: [HACKERS] path toward faster partition pruning

So I found that this query also crashed (using your rig), create table coercepart (a varchar) partition by list (a); create table coercepart_ab partition of coercepart for values in ('ab'); create table coercepart_bc partition of coercepart for values in ('bc'); create table coercepart_cd

Re: \d doesn't show partitioned table foreign keys

On 2018-May-14, Amit Langote wrote: > Hi. > > I just noticed $subject, which attached seems to fix, although not sure if > that's the correct fix for the issue. The fix looks good to me. Will push shortly. A related issue is that \d of the referenced table shows both the partitioned table as

Re: Cache lookup errors with functions manipulation object addresses

On 2018-Mar-06, Michael Paquier wrote: > On Mon, Mar 05, 2018 at 12:57:38PM +, Aleksander Alekseev wrote: > > It looks like that this patch doesn't apply anymore: > > http://commitfest.cputube.org/ > > > > The new status of this patch is: Waiting on Author > > Yes, this happens because

Re: Indexes on partitioned tables and foreign partitions

On 2018-May-10, Amit Langote wrote: > How about we error out even *before* calling DefineIndex for the 1st time? > I see that ProcessUtilitySlow() gets a list of all partitions when > locking them for index creation before calling DefineIndex. Maybe, just > go through the list and error out if

Re: Cache lookup errors with functions manipulation object addresses

On 2018-May-15, Michael Paquier wrote: > On Mon, May 14, 2018 at 04:27:48PM -0400, Alvaro Herrera wrote: > > I think we're better off adding a new function and avoid changing the > > signature of GetForeignServer et al. Or maybe rename the function and > > k

Re: [HACKERS] path toward faster partition pruning

Marina Polyakova wrote: > Hello everyone in this thread! > I got a similar server crash as in [1] on the master branch since the commit > 9fdb675fc5d2de825414e05939727de8b120ae81 when the assertion fails because > the second argument ScalarArrayOpExpr is not a Const or an ArrayExpr, but is > an

Re: [HACKERS] path toward faster partition pruning

Michael Paquier wrote: > Alvaro, could it be possible to consider as well the patch I posted > here? > https://www.postgresql.org/message-id/20180424012042.gd1...@paquier.xyz > > This removes a useless default clause in partprune.c and it got > forgotten in the crowd. Just attaching it again

Re: [HACKERS] path toward faster partition pruning

Amit Langote wrote: > On 2018/05/09 11:31, David Rowley wrote: > > On 9 May 2018 at 14:29, Amit Langote wrote: > >> On 2018/05/09 11:20, Michael Paquier wrote: > >>> While looking at this code, is there any reason to not make > >>> gen_partprune_steps static? This

Re: Should we add GUCs to allow partition pruning to be disabled?

David Rowley wrote: > On 10 May 2018 at 14:01, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > I'm thinking something a bit more radical. First, since partition > > pruning is the future and constraint exclusion is soon to be a thing of > > the past, we sh

Re: Should we add GUCs to allow partition pruning to be disabled?

David Rowley wrote: > Thanks for reviewing again. Hi, I'm thinking something a bit more radical. First, since partition pruning is the future and constraint exclusion is soon to be a thing of the past, we should describe pruning first, and then describe exclusion in terms of pruning. Second,

Re: Should we add GUCs to allow partition pruning to be disabled?

David Rowley wrote: > On 1 May 2018 at 21:44, Amit Langote wrote: > > About the patch in general, it seems like the newly added documentation > > talks about "Partition Pruning" as something that *replaces* constraint > > exclusion. But, I think "Partition Pruning"

Re: Should we add GUCs to allow partition pruning to be disabled?

Robert Haas wrote: > In defense of constraint exclusion, let me note that constraint > exclusion is not restricted to inheritance cases. It could eliminate > the need to scan a completely unpartitioned table if the WHERE clause > can be refuted by CHECK constraints. It could eliminate the need

Re: Should we add GUCs to allow partition pruning to be disabled?

David G. Johnston wrote: > ​Seems like if it stays the name is good - but at this point no has voiced > opposition to removing it and making the name a moot point. If we think the probability of bugs is 0%, then I'm all for removing it. I don't. I vote to remove the GUC in a couple of releases,

Re: Should we add GUCs to allow partition pruning to be disabled?

David G. Johnston wrote: > As a user I don't really need to know which model is implemented and the > name doesn't necessarily imply the implementation. Pruning seems to be the > commonly-used term for this feature and we should stick with that. I agree with this conclusion. So we have it

Re: Should we add GUCs to allow partition pruning to be disabled?

Hello Amit Langote wrote: > +1 to this more radical overhaul of this part of the documentation. Thanks. I pushed now after some more tweaking, including your suggested corrections. I removed the examples, because they were both wrong. We can give this more polish if anybody has the energy,

Re: PANIC during crash recovery of a recently promoted standby

Michael Paquier wrote: > On Thu, May 10, 2018 at 10:52:12AM +0530, Pavan Deolasee wrote: > > I propose that we should always clear the minRecoveryPoint after promotion > > to ensure that crash recovery always run to the end if a just-promoted > > standby crashes before completing its first regular

Re: Postgres 11 release notes

Bruce Momjian wrote: > OK, so what is the text that people will understand? This? > > Prevent manual VACUUMs on append-only tables from performing > needless index scans Make vacuum cheaper by avoiding scans of btree indexes when not necessary ? Why "manual vacuum"? It's a

Re: Postgres 11 release notes

Andres Freund wrote: > > > >Add configure flag --with-llvm to test for > >LLVM support (Andres Freund) > > > > > >Have configure check for the availability of a C++ compiler > >(Andres Freund) > > > > I wonder if we shouldn't omit

Re: Should we add GUCs to allow partition pruning to be disabled?

I'm thinking something like this. The examples for runtime pruning are lame -- in the first, the text says "watch out for Subplans Removed" and then the example provided doesn't show one. (That example is probably exercising the wrong thing.) Anyway, wording suggestions for 5.10.4 and 5.10.5 in

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Fabien COELHO wrote: > I think that I'll have time for a round of review in the first half of July. > Providing a rebased patch before then would be nice. Note that even in the absence of a rebased patch, you can apply to an older checkout if you have some limited window of time for a review.

Re: MAP syntax for arrays

Peter Eisentraut wrote: > On 5/8/18 09:19, Chapman Flack wrote: > > On 05/08/2018 08:57 AM, Ildar Musin wrote: > >> > >> select map (pow(2, x) - 1 for x in array[1,2,3,4,5]); > > > > I wonder how efficient an implementation would be possible strictly > > as a function, without grammar changes? >

Re: MAP syntax for arrays

Andrew Gierth wrote: > > "Andreas" == Andreas Karlsson writes: > > Andreas> It would be a pain if the SQL committee started using MAP for > Andreas> something. > > They already did - MAP is a non-reserved keyword in sql2016, used at > least with . Can't see any obvious

Re: perlcritic and perltidy

Andrew Dunstan wrote: > Yes. there are separate settings for the three types of brackets. Here's > what happens if we restrict the vertical tightness settings to parentheses. > > I think that's an unambiguous improvement. LGTM. -- Álvaro Herrerahttps://www.2ndQuadrant.com/

Re: cannot drop replication slot if server is running in single-user mode

Robert Haas wrote: > On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund wrote: > >> > 2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file > >> > descriptor > >> > >> I can confirm this bug exists in single-user mode. > > > > I'm not sure we need to do anything

Re: cannot drop replication slot if server is running in single-user mode

Alvaro Herrera wrote: > Robert Haas wrote: > > On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund <and...@anarazel.de> wrote: > > >> > 2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad > > >> > file > > >> > descriptor >

Re: [HACKERS] path toward faster partition pruning

Michael Paquier wrote: > So the problem appears when an expression needs to use > COERCION_PATH_ARRAYCOERCE for a type coercion from one type to another, > which requires an execution state to be able to build the list of > elements. The clause matching happens at planning state, so while there

Re: perlcritic and perltidy

Stephen Frost wrote: > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > > > - 'XLogRecPtr'=> 'pg_lsn'); > > + 'XLogRecPtr'=> 'pg_lsn',); > > There's not much point adding the ',' unless you're also putting the > ');' on the next line, is there..? > > Or is

Re: Postgres 11 release notes

On 2018-May-15, Bruce Momjian wrote: > On Wed, May 16, 2018 at 09:01:35AM +0900, Tatsuo Ishii wrote: > > There's a small typo. > > > > > Add support for with huge(large) pages on Windows (Takayuki Tsunakawa, > > > Thomas Munro) > > > > I think a space between "huge" and "(large)" is needed. >

Re: [BUGFIX] amcanbackward is not checked before building backward index paths

On 2018-May-17, Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, May 17, 2018 at 8:46 AM, Tom Lane wrote: > >> Maybe "Can the scan direction be reversed in mid-scan?". I'm not > >> absolutely sure that that's better ... > > > ​A cursory

Re: Postgres 11 release notes

On 2018-May-16, Magnus Hagander wrote: > On Wed, May 16, 2018 at 4:08 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > I'm not sure why we say "huge (large) pages". The natural term for > > Windows is "large-pages", > > https:

Re: printf format selection vs. reality

On 2018-May-23, Tom Lane wrote: > The practical alternatives seem to be to avoid %z in frontend code, > or to invent a macro SIZE_T_MODIFIER and use it like INT64_MODIFIER. > Either one will be extremely error-prone, I'm afraid, unless we can > find a way to get compiler warnings for violations.

Re: Should we add GUCs to allow partition pruning to be disabled?

On 2018-May-24, Bruce Momjian wrote: > On Wed, May 2, 2018 at 07:49:42PM -0700, David G. Johnston wrote: > > I toss my +1 to removing it altogether. > > +1 We are terrible at removing old GUCs and having it around means > everyone has to decide if they need to change it, so having it is not a

Re: PG 11 feature count

On 2018-May-17, Bruce Momjian wrote: > 9.5 200 > 9.6 220 > 10 194 > 11 167 Just yesterday Andres was telling us that pg11 has so much new stuff, when compared to 9.5 and 9.6, that seemed to have not as much shiny things. I think it's all in the eye of

Re: Transform for pl/perl

Hello This is still listed as an open item, though the patch proposed by Peter upthread has been committed. If I understand correctly, ilmari was going to propose another patch. Or is the right course of action to set the open item as resolved? On 2018-May-02, Dagfinn Ilmari Mannsåker wrote:

Re: Make description of heap records more talkative for flags

On 2018-Apr-23, Alvaro Herrera wrote: > Now, frankly, this being mostly a debugging tool, I think it would be > better to have the output as complete as we can. Otherwise, when > debugging some hideous problem we find ourselves patching the tool > during an emergency in order to fig

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018-May-03, Robert Haas wrote: > The asymmetry doesn't seem horrible to me on its own merits, but it > would lead to some odd behavior: suppose you defined a BEFORE ROW > trigger and an AFTER ROW trigger on the parent, and then inserted one > row into the parent table and a second row

Re: Incorrect comment in get_partition_dispatch_recurse

On 2018-May-17, Tom Lane wrote: > Robert Haas writes: > > Hang on, I can't be wrong (famous last words). If the negative > > indexes were 0-based, that would mean that the first element of the > > list was referenced by -0, which obviously can't be true, because 0 = > >

Re: [PATCH] Clear up perlcritic 'missing return' warning

On 2018-May-23, Andrew Dunstan wrote: > And yes, the idea is that if we do this then we adopt a perlcritic > policy that calls it out when we forget. If we can have a buildfarm animal that runs perlcritic that starts green (and turns yellow with any new critique), with a config that's also part

Re: Needless additional partition check in INSERT?

On 2018-Jun-07, David Rowley wrote: > On 7 June 2018 at 15:57, Alvaro Herrera wrote: > > Hm I was thinking this new function would be companion to ExecConstrains > > (a fact I used in the name I proposed,) so it'd be in the same file > > (probably right after it.) > &g

Re: Needless additional partition check in INSERT?

On 2018-Jun-09, David Rowley wrote: > On 9 June 2018 at 03:24, Alvaro Herrera wrote: > > I was also wondering about introducing a new function call in this path > > where previously was none. Given the amount of other stuff that's > > happening when a tuple is inserted, I s

Re: Needless additional partition check in INSERT?

Training & Services >From 5d57489c6d8c5e1b10413362005ae333acd6c243 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Wed, 6 Jun 2018 15:08:23 -0400 Subject: [PATCH] Fix situation with partition constraints blah blah ... commits 15ce775faa4 19c47e7c820 ... blah blah --- src/backend

Re: Needless additional partition check in INSERT?

Training & Services >From 5d57489c6d8c5e1b10413362005ae333acd6c243 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Wed, 6 Jun 2018 15:08:23 -0400 Subject: [PATCH] Fix situation with partition constraints --- src/backend/commands/copy.c| 30 +--

Re: SHOW ALL does not honor pg_read_all_settings membership

On 2018-Jun-08, Alvaro Herrera wrote: > BTW a further bug here seems to be that "select * from pg_settings()" > does not show the source file/line for members of the role, which seems > to be documented to occur. And I think this fixes it. -- Álvaro Herrera

Re: SHOW ALL does not honor pg_read_all_settings membership

BTW a further bug here seems to be that "select * from pg_settings()" does not show the source file/line for members of the role, which seems to be documented to occur. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: SHOW ALL does not honor pg_read_all_settings membership

On 2018-Mar-01, Laurenz Albe wrote: > I noticed that commit 25fff40798fc4ac11a241bfd9ab0c45c085e2212 forgot > to teach SHOW ALL to show all GUCs when the user belongs to > pg_read_all_settings. > > Patch attached; I think this should be backpatched. Done, with the further fixes downthread.

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018-Jun-08, Alvaro Herrera wrote: > Actually, the column order doesn't matter for a trigger function, > because these don't refer to columns by number but by name. So unless > users write trigger functions in C and use hardcoded column numbers > (extremely unlike

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018-Jun-07, Ashutosh Bapat wrote: > On Thu, Jun 7, 2018 at 10:58 AM, Amit Langote > wrote: > > I don't understand why you think it's too troublesome to let the users > > know that there is some way to use BR triggers with partitioning. We > > didn't do that for indexes, for example, before

Re: SHOW ALL does not honor pg_read_all_settings membership

On 2018-May-31, Michael Paquier wrote: > On Thu, May 31, 2018 at 07:05:58PM +0100, Simon Riggs wrote: > > Any objections to backpatch to v10? > > A backpatch is acceptable in my opinion. Agreed on backpatching. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: Fix slot's xmin advancement and subxact's lost snapshots in decoding.

On 2018-Jun-11, Antonin Houska wrote: > Arseny Sher wrote: > > Please see detailed description of the issues, tests which reproduce > > them and fixes in the attached patch. > > I've played with your tests and gdb for a while, both w/o and with your > patch. I think I can understand both

Re: [HACKERS] Statement-level rollback

On 2018-Jun-16, Robert Haas wrote: > I'm not sure that really solves the problem, because changing the GUC > in either direction causes the system to behave differently. I don't > see any particular reason to believe that changing the behavior from A > to B is any more or less likely to break

Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On 2018-Jun-18, Ashutosh Bapat wrote: > That's a wrong comparison. Inheritance based partitioning works even > after declarative partitioning feature is added. So, users can > continue using inheritance based partitioning if they don't want to > move to declarative partitioning. That's not true

Re: Removing "Included attributes in B-tree indexes" section from docs

On 2018-Jun-17, Peter Geoghegan wrote: > On Sat, Jun 16, 2018 at 8:51 PM, Alvaro Herrera > wrote: > > I don't necessarily object to the proposed change, but I think you > > should generally wait a bit longer for others to react. > > What wait period do you think is

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

On 2018-Jun-13, Alexander Korotkov wrote: > On Wed, Jun 13, 2018 at 12:48 PM Kuntal Ghosh > wrote: > > On Wed, Jun 13, 2018 at 2:28 PM, Masahiko Sawada > > wrote: > > > Hi, > > > > > > Three functions: brin_summarize_new_values, brin_summarize_range and > > > brin_desummarize_range can be

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

On 2018-Jun-13, Fabien COELHO wrote: > > > > With that, is there a need for elog()? In the backend we have > > > > it because $HISTORY but there's no need for that here -- I > > > > propose to lose elog() and use only ereport everywhere. > > See commit 8a07ebb3c172 which turns some ereport into

Re: Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...)

On 2018-Jun-14, Amit Kapila wrote: > On Sun, Jun 3, 2018 at 5:08 AM, Amit Kapila wrote: > > 2. > > +/* > > + * Structure used to represent value to be used when the attribute is not > > + * present at all in a tuple, i.e. when the column was created after the > > tuple > > + */ > > + > >

Re: Index maintenance function for BRIN doesn't check RecoveryInProgress()

On 2018-Jun-14, Michael Paquier wrote: > On Thu, Jun 14, 2018 at 02:06:57AM +0900, Masahiko Sawada wrote: > > On Thu, Jun 14, 2018 at 12:04 AM, Simon Riggs wrote: > >> On 13 June 2018 at 15:51, Alvaro Herrera wrote: > >>> I guess you could go either way ... we'

  1   2   3   4   5   6   7   8   9   10   >