Re: [HACKERS] Constraint merge and not valid status

Hello, On 2016/07/26 11:05, Kyotaro HORIGUCHI wrote: > At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote wrote: > >> So, apparently RelationClearRelation() does intend to discard a cached >> TupleDesc if ccvalid changed in a transaction. Whereas, >> acquire_inherited_sample_rows() does not seem

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Mon, Jul 25, 2016 at 11:12:24PM -0400, Robert Haas wrote: > On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote: > > I've renamed it to require_where and contrib-ified. > > I'm not sure that the Authors section is entirely complete. Does this suit? Best, David. -- David

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 07/25/16 22:09, Michael Paquier wrote: > This is over-complicating things for little gain. The new behavior of > filling in with zeros the tail of a segment makes things far better > when using gzip in archive_command. Then how about filling with actual zeros, instead of with mostly-zeros as

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote: > I've renamed it to require_where and contrib-ified. I'm not sure that the Authors section is entirely complete. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: > I suppose that a fix based on putting PG_TRY blocks into all the affected > functions might be simple enough that we'd risk back-patching it, but > I don't really want to go that way. try/catch blocks aren't completely free,

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On Mon, Jul 25, 2016 at 11:21 PM, Chapman Flack wrote: > The impression that leaves is of tools that relied too heavily > on internal format knowledge to be viable outside of core, which > have had at least periods of incompatibility with newer PG versions, > and whose

Re: [HACKERS] Constraint merge and not valid status

Hello, At Mon, 25 Jul 2016 18:21:27 +0900, Amit Langote wrote in <96fb8bca-57f5-e5a8-9630-79d4fc5b2...@lab.ntt.co.jp> > > Hello, > > On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote: > > > > - Remove ccvalid condition from equalTupleDescs() to reduce > >

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote: > Robbie Harwood writes: Sorry for my late reply. >> I think in order to satisfy Tom's (valid) concern, there does need to be >> a separate handshake - i.e., GSSAPI support in

Re: [HACKERS] Proposal: revert behavior of IS NULL on row types

On 7/22/16 7:01 PM, Andrew Gierth wrote: > In light of the fact that it is an endless cause of bugs both in pg and > potentially to applications, I propose that we cease attempting to > conform to the spec's definition of IS NULL in favour of the following > rules: I can't see how we would

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On 25/07/16 21:20, Andrew Gierth wrote: > Here is my proposed code (first cut; obviously it needs docs too). > Opinions? I support the future of this patch, for 9.6. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise,

Re: [HACKERS] Design for In-Core Logical Replication

On 07/20/2016 10:08 AM, Simon Riggs wrote: > > Monitoring > > pg_stat_replication > > > pg_stat_subscription > > and probably also `pg_stat_publication` or some other way to see, what tables are currently in a PUBLICATION, who has subscribed etc. > > CREATE PUBLICATION

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Alvaro Herrera writes: > Tom Lane wrote: >> Although this is in principle a bug fix, it's invasive enough that I'd >> be pretty hesitant to back-patch it, or even to stick it into HEAD >> post-beta. I'm inclined to sign it up for the next commitfest instead. > Do we

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Alvaro Herrera wrote: > Tom Lane wrote: > > > Although this is in principle a bug fix, it's invasive enough that I'd > > be pretty hesitant to back-patch it, or even to stick it into HEAD > > post-beta. I'm inclined to sign it up for the next commitfest instead. > > Do we have a backpatchable

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Tom Lane wrote: > Although this is in principle a bug fix, it's invasive enough that I'd > be pretty hesitant to back-patch it, or even to stick it into HEAD > post-beta. I'm inclined to sign it up for the next commitfest instead. Do we have a backpatchable fix for the reported problem? If so,

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > "Joshua D. Drake" writes: > > On 07/25/2016 12:19 PM, Tom Lane wrote: > >> Andrew still hasn't shown a concrete > >> example of what he needs to do and why. > > > I think that Andrew and other people who have commented on this

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Robbie Harwood writes: > Michael Paquier writes: > >> On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote: >>> Robbie Harwood writes: Tom Lane writes: > Wait a second. So

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

"Joshua D. Drake" writes: > On 07/25/2016 12:19 PM, Tom Lane wrote: >> Andrew still hasn't shown a concrete >> example of what he needs to do and why. > I think that Andrew and other people who have commented on this thread > made it pretty obvious why it is useful.

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On 07/25/2016 12:19 PM, Tom Lane wrote: Robert Haas writes: On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote: You missed the "compelling argument why it's needed" part. What is the need for this? It's self-evident that this thread wouldn't exist

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

> "Tom" == Tom Lane writes: Tom> Andrew still hasn't shown a concrete example of what he needs to Tom> do and why. The issue I ran into was the exact same one as in the JDBC thread I linked to earlier: correctly interpreting pg_index.indoption (to get the ASC / DESC

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Here is my proposed code (first cut; obviously it needs docs too). Opinions? -- Andrew (irc:RhodiumToad) diff --git a/src/backend/access/index/amapi.c b/src/backend/access/index/amapi.c index d347ebc..3e7e084 100644 --- a/src/backend/access/index/amapi.c +++ b/src/backend/access/index/amapi.c

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Robert Haas writes: > On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote: >> You missed the "compelling argument why it's needed" part. What is the >> need for this? > It's self-evident that this thread wouldn't exist if it were not the > case that

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Attached is a draft patch for creating statement-level temporary memory contexts in plpgsql. It creates such contexts only as needed, and there are a lot of simpler plpgsql statements that don't need them, so I think the performance impact should be pretty minimal --- though I've not tried to

Re: [HACKERS] LWLocks in DSM memory

Hi, On 2016-07-25 15:02:41 +1200, Thomas Munro wrote: > > Any thoughts on this approach, or better ways to solve this problem? > > How valuable is the branch-free property of the circular push and > > delete operations? I think it's generally valuable, but I suspect that it doesn't really matter

Re: [HACKERS] LWLocks in DSM memory

On Sun, Jul 24, 2016 at 11:02 PM, Thomas Munro wrote: > On Sun, Jul 24, 2016 at 1:10 AM, Thomas Munro > wrote: >> One solution could be to provide a non-circular variant of the dlist >> interface that uses NULL list termination. I've

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Mon, Jul 25, 2016 at 10:35 AM, Tom Lane wrote: > You missed the "compelling argument why it's needed" part. What is the > need for this? It's self-evident that this thread wouldn't exist if it were not the case that people had queries that no longer work because of these

[HACKERS] ispell/hunspell imprecision in error message

I was trying to look up the background of this error message: "Ispell dictionary supports only \"default\", \"long\", and \"num\" flag value" (src/backend/tsearch/spell.c) But I found that this actually talks about Hunspell format dictionaries. (So the man page is hunspell(5) as opposed to

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

> "Tom" == Tom Lane writes: >> It could easily be exposed as a function interface of the form >> index_has_capability(oid,name) or indexam_has_capability(oid,name) >> without any initdb worries. Tom> You missed the "compelling argument why it's needed" part. What

[HACKERS] handling unconvertible error messages

Example: I have a database cluster initialized with --locale=ru_RU.UTF-8 (built with NLS). Let's say for some reason, I have client encoding set to LATIN1. All error messages come back like this: test=> select * from notthere; ERROR: character with byte sequence 0xd0 0x9e in encoding "UTF8"

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> We could in theory expose a view to show the data --- but since a > Tom> large part of the point of that change was to not need initdb for > Tom> AM API changes, and to not be constrained

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 07/23/2016 08:25 AM, Amit Kapila wrote: > On Sat, Jul 23, 2016 at 3:32 AM, Chapman Flack wrote: >> >> Would it then be possible to go back to the old behavior (or make >> it selectable) of not overwriting the full 16 MB every time? >> > > I don't see going back to old

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

* Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > > "Tom" == Tom Lane writes: > > >> With the gutting of pg_am in 9.6, there seems to be no longer any > >> way for a query of the system catalogs to discover any of the index > >> capabilities that were formerly

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

> "Tom" == Tom Lane writes: >> With the gutting of pg_am in 9.6, there seems to be no longer any >> way for a query of the system catalogs to discover any of the index >> capabilities that were formerly columns in pg_am (notably >> amcanorder, amcanorderbyop,

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Andrew Gierth writes: > With the gutting of pg_am in 9.6, there seems to be no longer any way > for a query of the system catalogs to discover any of the index > capabilities that were formerly columns in pg_am (notably amcanorder, > amcanorderbyop, amclusterable,

[HACKERS] No longer possible to query catalogs for index capabilities?

With the gutting of pg_am in 9.6, there seems to be no longer any way for a query of the system catalogs to discover any of the index capabilities that were formerly columns in pg_am (notably amcanorder, amcanorderbyop, amclusterable, amsearcharray, amsearchnulls). Am I missing something or is

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

On Mon, Jul 25, 2016 at 2:52 PM, Michael Paquier wrote: > Ah, yes, and that's a stupid mistake. We had better use > replay_location instead of write_location. There is a risk that > records have not been replayed yet even if they have been written on > the standby, so

Re: [HACKERS] sslmode=require fallback

On 7/20/16 8:55 AM, Daniel Verite wrote: > Personally I think that TLS for local networking is wrong as a default, and > it's unfortunate that distros like Debian/Ubuntu end up using that. There is something to that, but I'm not sure that just giving up and disabling SSL in the default

Re: [HACKERS] Confusing TAP tests readme file

On Mon, Jul 25, 2016 at 7:42 PM, Ildar Musin wrote: > I was checking out TAP tests documentation. And I found confusing this part > of src/test/perl/README file: > > my $ret = $node->psql('postgres', 'SELECT 1'); > is($ret, '1', 'SELECT 1 returns 1'); Good catch.

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Sun, Jul 24, 2016 at 9:17 PM, Tom Lane wrote: > Amit Kapila writes: > >> Wouldn't it be better, if each nested sub-block (which is having an >> exception) has a separate "SPI Proc", "SPI Exec" contexts which would >> be destroyed at sub-block end

[HACKERS] Optimizing numeric SUM() aggregate

Hi, I spent some time profiling a simply query with a SUM() aggregate. We've made some big improvements in this area in recent years, but it seems there's still some room for improvement. A lot of CPU time is spent in the numeric add_var() and friends. Which isn't that surprising, I guess.

[HACKERS] Confusing TAP tests readme file

Hi all, I was checking out TAP tests documentation. And I found confusing this part of src/test/perl/README file: my $ret = $node->psql('postgres', 'SELECT 1'); is($ret, '1', 'SELECT 1 returns 1'); The returning value of psql() function is the exit code of the psql. Hence this test

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

>Can you please patch BRIN to use this new function too? AFAIK Sergey Mirvoda was going to implement and test it. It is easy to do this optimization for brin_samepage_update (see patch draft in attachment, make check passes), but WAL of regular BRIN update is not clear for me. Best regards,

Re: [HACKERS] Constraint merge and not valid status

Hello, On 2016/07/25 17:18, Kyotaro HORIGUCHI wrote: > > - Remove ccvalid condition from equalTupleDescs() to reduce >unnecessary cache invalidation or tuple rebuilding. The following commit introduced the ccvalid check: """ commit c31305de5f5a4880b0ba2f5983025ef0210a3b2a Author: Noah

Re: [HACKERS] Fix typo in postgres_fdw/deparse.c

On Thu, Jul 14, 2016 at 2:22 PM, Masahiko Sawada wrote: > Hi all, > > Attached patch fixes small typo in contrib/postgres_fdw/deparse.c > > s/whenver/whenever/g Applied. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list

[HACKERS] Fix comment in ATExecValidateConstraint

The comment seems to have been copied from ATExecAddColumn, which says: /* * If we are told not to recurse, there had better not be any - * child tables; else the addition would put them out of step. For ATExecValidateConstraint, it should say something like: + * child tables; else

Re: [HACKERS] Constraint merge and not valid status

Hello, At Mon, 25 Jul 2016 15:57:00 +0900, Amit Langote wrote in > On 2016/07/25 12:44, Kyotaro HORIGUCHI wrote: > > At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote: > >> On 2016/07/22 17:06, Kyotaro

Re: [HACKERS] Constraint merge and not valid status

Hello, On 2016/07/25 12:44, Kyotaro HORIGUCHI wrote: > At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote: >> On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote: >> >>> By the way I have one question. >>> >>> Is it an expected configuration where tables in an inheritance >>> tree has different