Re: [HACKERS] Logical replication and inheritance

On 2017/04/14 21:44, Petr Jelinek wrote: > On 14/04/17 06:14, Amit Langote wrote: >> On 2017/04/14 10:57, Petr Jelinek wrote: >>> For me the current behavior with inherited tables is correct. >> >> By the way, what do you think about the pg_dump example/issue I mentioned? >> Is that a pg_dump

Re: [HACKERS] Comments not allowed on partitioned table columns

On 2017/04/18 14:50, Amit Langote wrote: > Attached patch fixes the oversight that COMMENT ON COLUMN is not allowed > on partitioned tables columns. Forgot to mention that I added this to the open items list. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

[HACKERS] Comments not allowed on partitioned table columns

Attached patch fixes the oversight that COMMENT ON COLUMN is not allowed on partitioned tables columns. Thanks, Amit >From cfc0717478f2a73087c85d67d73e557aaccb4f78 Mon Sep 17 00:00:00 2001 From: amit Date: Tue, 18 Apr 2017 14:48:37 +0900 Subject: [PATCH] Allow COMMENT ON

Re: [HACKERS] scram and \password

On Tue, Apr 11, 2017 at 10:07:12PM +0300, Heikki Linnakangas wrote: > On 04/10/2017 08:42 AM, Michael Paquier wrote: > >As there have been some conflicts because of the commit of SASLprep, > >here is a rebased set of patches. A couple of things worth noting: > >- SASLprep does an allocation of the

Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-04-17 19:26:11 -0400, Tom Lane wrote: > I wrote: > > I'm a bit inclined to agree with the idea of explicitly requiring SRFs > > in FROM to appear only at the top level of the expression. > > If we are going to go down this road, I think it would be a good idea > to try to provide a cursor

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Hi Stephen, On 2017/04/18 1:43, Stephen Frost wrote: > Amit, > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> OK, I agree. I tweaked the existing bullet point about differences from >> traditional inheritance when using ONLY with partitioned tables. > > Please take a look at the

Re: [HACKERS] snapbuild woes

On 2017-04-16 22:04:04 -0400, Noah Misch wrote: > On Thu, Apr 13, 2017 at 12:58:12AM -0400, Noah Misch wrote: > > On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote: > > > On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote: > > > > On 4/12/17 02:31, Noah Misch wrote: > > > > >>> But I

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

At Tue, 18 Apr 2017 09:12:07 +0530, Ashutosh Bapat wrote in > On Tue, Apr 18, 2017 at 8:12 AM, Kyotaro HORIGUCHI > wrote: > > At Mon, 17 Apr 2017 17:50:58

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Tue, Apr 18, 2017 at 8:12 AM, Kyotaro HORIGUCHI wrote: > At Mon, 17 Apr 2017 17:50:58 +0530, Ashutosh Bapat > wrote in > >> On Mon, Apr 17, 2017 at 1:53 PM,

Re: [HACKERS] Different table schema in logical replication crashes

On 4/17/17 08:47, Euler Taveira wrote: > Patch works fine. However, I don't see any documentation about > supporting different schemas for logical replication. Is it an oversight? I have added more documentation about that. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Different table schema in logical replication crashes

On 4/14/17 21:36, Petr Jelinek wrote: > I tried something bit different which seems cleaner to me - use the > pstate->r_table instead of ad-hock locally made up range table and fill > that using standard addRangeTableEntryForRelation. Both in tablesync and > in DoCopy instead of the old coding.

Re: [HACKERS] some review comments on logical rep code

Hi, Thank you for the revised version. At Mon, 17 Apr 2017 23:29:28 +0900, Masahiko Sawada wrote in > On Mon, Apr 17, 2017 at 9:13 PM, Masahiko Sawada > wrote: > > On Mon, Apr

Re: [HACKERS] PATCH: psql show index with type info

Ah, thanks for the suggestions. I'll revise this patch soon :) Fabien COELHO writes: >> Done. > > Ok. The file should be named "v2". > >> Would you like to be the reviewer? > > Dunno. At least I wanted to have a look at it! > > My 0.02€: > > I think that the improvement

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

At Mon, 17 Apr 2017 17:50:58 +0530, Ashutosh Bapat wrote in > On Mon, Apr 17, 2017 at 1:53 PM, Kyotaro HORIGUCHI > wrote: > > At Thu, 13 Apr 2017 13:04:12

Re: [HACKERS] PATCH: psql show index with type info

Done. Ok. The file should be named "v2". Would you like to be the reviewer? Dunno. At least I wanted to have a look at it! My 0.02€: I think that the improvement provided is worthwhile. Two questions: Why no documentation update? Why no non-regressions tests? As far as the output is

Re: [HACKERS] PATCH: psql show index with type info

Done. Would you like to be the reviewer? Thanks! diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c index 0f9f497..a6dc599 100644 --- a/src/bin/psql/describe.c +++ b/src/bin/psql/describe.c @@ -3284,7 +3284,7 @@ listTables(const char *tabtypes, const char *pattern, bool verbose, bool

Re: [HACKERS] PATCH: psql show index with type info

I'm not sure where to add documentations about this patch or if needed one. Please help me if you think this patch is useful. This patch does not apply anymore. Are you planning to update it? -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Logical replication and inheritance

On 2017/04/17 23:08, Peter Eisentraut wrote: > On 4/16/17 23:00, Amit Langote wrote: >>> To fix this, pg_dump should emit ADD TABLE ONLY foo. >> >> Yeah, that's one way. Attached is a tiny patch for that. >> >> By the way, I noticed that although grammar accepts ONLY and * against a >> table name

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

Hello Jan, Corrected problem with \pset linestyle when format is set to markdown, or rst. Corrected tuples only for markdown and rst (normal and expanded) It seems that the patch does not apply anymore on head due to changes in psql non regression tests. Could you rebase? -- Fabien. --

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On Tue, Apr 18, 2017 at 12:33 AM, Jeff Janes wrote: > On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier > wrote: >> >> >> >> Jeff, does this patch make the situation better? The fix is rather >> simple as it just makes sure that the next XID never

Re: [HACKERS] Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

I wrote: > I'm a bit inclined to agree with the idea of explicitly requiring SRFs > in FROM to appear only at the top level of the expression. If we are going to go down this road, I think it would be a good idea to try to provide a cursor position for the "can't accept a set" error message,

Re: [HACKERS] extended stats not friendly towards ANALYZE with subset of columns

David Rowley wrote: > On 18 April 2017 at 05:12, Alvaro Herrera wrote: > > Pushed, after tweaking so that a WARNING is still emitted, because it's > > likely to be useful in pointing out a procedural mistake while extended > > stats are being tested. > > Thanks for

Re: [HACKERS] extended stats not friendly towards ANALYZE with subset of columns

On 18 April 2017 at 05:12, Alvaro Herrera wrote: > Pushed, after tweaking so that a WARNING is still emitted, because it's > likely to be useful in pointing out a procedural mistake while extended > stats are being tested. Thanks for pushing. Seems you maintained most

Re: [HACKERS] Allowing extended stats on foreign and partitioned tables

On 18 April 2017 at 09:01, Alvaro Herrera wrote: > David Rowley wrote: >> While reviewing extended stats I noticed that it was possible to >> create extended stats on many object types, including sequences. I >> mentioned that this should be disallowed. Statistics were

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

Alvaro Herrera wrote: > Tom Lane wrote: > > Peter Eisentraut writes: > > > On 4/13/17 08:37, Heikki Linnakangas wrote: > > >> We have a bunch of > 3-character prefixes already: amop*, amproc*, > > >> enum*, cast*. But I think I nevertheless like "ste" better. >

Re: [HACKERS] Allowing extended stats on foreign and partitioned tables

David Rowley wrote: > While reviewing extended stats I noticed that it was possible to > create extended stats on many object types, including sequences. I > mentioned that this should be disallowed. Statistics were then changed > to be only allowed on plain tables and materialized views. > >

Re: [HACKERS] Self-signed certificate instructions

On 04/15/2017 03:58 PM, Andrew Dunstan wrote: The instructions on how to create a self-signed certificate in s 18.9.3 of the docs seem unduly cumbersome. +1, I see no reason for us to spread unnecessarily complicated instructions. Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Self-signed certificate instructions

On Mon, Apr 17, 2017 at 04:27:30PM -0400, Andrew Dunstan wrote: > > I would like to revisit these instructions, as well as document how to > > create intermediate certificates. I have scripts that do that. > > > > > OK.. Do you want to run with this? Please go forward and I will work on the

Re: [HACKERS] Self-signed certificate instructions

On 04/17/2017 02:19 PM, Bruce Momjian wrote: > On Sat, Apr 15, 2017 at 11:17:14AM -0400, Andrew Dunstan wrote: >> >> On 04/15/2017 09:58 AM, Andrew Dunstan wrote: >>> The instructions on how to create a self-signed certificate in s 18.9.3 >>> of the docs seem unduly cumbersome. AFAICT we could

[HACKERS] Passing values to a dynamic background worker

So after reading a recent thread on the steep learning curve for PG internals [1], I figured I'd share where I've gotten stuck with this in a new thread vs hijacking that one. One of the goals I had with pg_partman was to see if I could get the partitioning python scripts redone as C functions

Re: [HACKERS] Self-signed certificate instructions

On Mon, Apr 17, 2017 at 03:43:09PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I think the reason we have those cumbersome instructions is that there > > is no way to create a non-expireable certificate using simpler > > instructions. > > Um ... but the current

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 4/13/17 12:11, Robert Haas wrote: > > I wonder if we should have an --no-subscriptions option, now that they > > are dumped by default, just like we have --no-blobs, --no-owner, > > --no-password, --no-privileges, --no-acl,

Re: [HACKERS] Row Level Security UPDATE Confusion

Rod, * Rod Taylor (rod.tay...@gmail.com) wrote: > Yep. It's equivalent to a DELETE or DEACTIVATE. RLS may not be the right > facility but it was very close to working exactly the way I wanted in FOR > ALL mode. Turning an UPDATE into, effectively, a DELETE, does seem like it's beyond the mandate

Re: [HACKERS] Self-signed certificate instructions

Bruce Momjian writes: > I think the reason we have those cumbersome instructions is that there > is no way to create a non-expireable certificate using simpler > instructions. Um ... but the current instructions don't address that either. > I would like to revisit these

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Noah, all, * Noah Misch (n...@leadboat.com) wrote: > On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote: > > On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost wrote: > > > Sure, though I won't be able to today and I've got some doubts about the > > > other patches.

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: > Tom Lane wrote: >> I'm coming around to the idea that it'd be better to disable physical >> tlists for custom scans. >> However, I'm hesitant to make such a change in the back branches; if >> there's anyone using custom scans who's negatively

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

On 2017-04-17 15:59, Stas Kelvich wrote: On 17 Apr 2017, at 10:30, Erik Rijkers wrote: On 2017-04-16 20:41, Andres Freund wrote: On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote: On 2017-04-15 04:47, Erik Rijkers wrote: > >

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 4/17/17 12:30, Andres Freund wrote: So I guess that CREATE_REPLICATION_SLOT code calls LogStandbySnapshot() and which generates WAL record about snapshot of running transactions. >>> >>> Erroring out in these cases sounds easy enough. Wonder if there's not a >>> bigger problem with

Re: [HACKERS] Self-signed certificate instructions

On Sat, Apr 15, 2017 at 11:17:14AM -0400, Andrew Dunstan wrote: > > > On 04/15/2017 09:58 AM, Andrew Dunstan wrote: > > The instructions on how to create a self-signed certificate in s 18.9.3 > > of the docs seem unduly cumbersome. AFAICT we could replace all the > > commands (except the chmod)

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 4/16/17 22:01, Noah Misch wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Wed, Apr 12, 2017 at 2:36 AM, Masahiko Sawada wrote: > On Thu, Apr 6, 2017 at 4:17 PM, Masahiko Sawada wrote: >> On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote: >>> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao

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

Craig Ringer wrote: > Personally I have to agree that the learning curve is very steep. Some > of the docs and presentations help, but there's a LOT to understand. There is a wiki page "Developer_FAQ" which is supposed to help answer these questions. It is currently not very useful, because

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andres Freund writes: > Btw, I think Tom's "more that could be done" was referring more to doing > more upfront work, checking, easier input format, whatnot in the genbki, > not so much performance work... Tom, correct me if I'm wrong. Yeah, as per what we were just saying,

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote: > Tom Lane writes: > > > There's certainly lots more that could be done in the genbki code, > > but I think all we can justify at this stage of the development > > cycle is to get the low-hanging fruit for testing

Re: [HACKERS] extended stats not friendly towards ANALYZE with subset of columns

David Rowley wrote: > ERROR: extended statistics could not be collected for column "a" of > relation public.ab1 > HINT: Consider ALTER TABLE "public"."ab1" ALTER "a" SET STATISTICS -1 > > I don't think the error is useful here, as it means nothing gets done. > Probably better to just not

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Andres Freund writes: > On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote: >> I threw Devel::NYTProf at it and picked some more low-hanging fruit. > I'm a bit doubtful about improving the performance of genbki at the cost > of any sort of complication - it's only

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote: > Tom Lane writes: > > > There's certainly lots more that could be done in the genbki code, > > but I think all we can justify at this stage of the development > > cycle is to get the low-hanging fruit for testing

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Tom Lane writes: > There's certainly lots more that could be done in the genbki code, > but I think all we can justify at this stage of the development > cycle is to get the low-hanging fruit for testing speedups. I threw Devel::NYTProf at it and picked some more low-hanging

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > OK, I agree. I tweaked the existing bullet point about differences from > traditional inheritance when using ONLY with partitioned tables. Please take a look at the attached and let me know your thoughts on it. I changed the code to

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

On 27 March 2017 at 13:00, Kang Yuzhe wrote: > I have found PG source Code reading and hacking to be one the most > frustrating experiences in my life. I believe that PG hacking should not be > a painful journey but an enjoyable one! > > It is my strong believe that out of

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 2017-04-17 18:28:16 +0200, Petr Jelinek wrote: > On 17/04/17 18:02, Andres Freund wrote: > > On 2017-04-15 02:33:59 +0900, Fujii Masao wrote: > >> On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek > >> wrote: > >>> On 12/04/17 15:55, Fujii Masao wrote: > Hi, >

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 17/04/17 18:02, Andres Freund wrote: > On 2017-04-15 02:33:59 +0900, Fujii Masao wrote: >> On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek >> wrote: >>> On 12/04/17 15:55, Fujii Masao wrote: Hi, When I shut down the publisher while I repeated

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 2017-04-15 02:33:59 +0900, Fujii Masao wrote: > On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek > wrote: > > On 12/04/17 15:55, Fujii Masao wrote: > >> Hi, > >> > >> When I shut down the publisher while I repeated creating and dropping > >> the subscription in the

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

On Tue, Mar 28, 2017 at 10:36 PM, Craig Ringer wrote: > Personally I have to agree that the learning curve is very steep. Some > of the docs and presentations help, but there's a LOT to understand. Some small patches can be kept to a fairly narrow set of areas, and if you

[HACKERS] PGCon 2017 registration now open

Join us in Ottawa for the 11th annual PGCon. On May 23-26, users and developers from around the world arrive for what has become a traditional gathering of the PostgreSQL community. There will be two days of tutorials on Tuesday and Wednesday. The best of the best will be available to help

Re: [HACKERS] OK, so culicidae is *still* broken

On 2017-04-15 14:34:28 -0700, Andres Freund wrote: > On 2017-04-15 17:30:21 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2017-04-15 16:48:05 -0400, Tom Lane wrote: > > >> Concretely, I propose the attached patch. We'd have to put it into > > >> all supported

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier wrote: > > > Jeff, does this patch make the situation better? The fix is rather > simple as it just makes sure that the next XID never gets updated if > there are no 2PC files. > Yes, that fixes the reported case when

Re: [HACKERS] Re: extended stats not friendly towards ANALYZE with subset of columns

Noah Misch wrote: > On Wed, Apr 05, 2017 at 08:58:54AM -0300, Alvaro Herrera wrote: > > Noah Misch wrote: > > > The above-described topic is currently a PostgreSQL 10 open item. Álvaro, > > > since you committed the patch believed to have created it, you own this > > > open > > > item. > > > >

Re: [HACKERS] some review comments on logical rep code

On Mon, Apr 17, 2017 at 9:13 PM, Masahiko Sawada wrote: > On Mon, Apr 17, 2017 at 7:39 PM, Kyotaro HORIGUCHI > wrote: >> At Mon, 17 Apr 2017 18:02:57 +0900, Masahiko Sawada >> wrote in

Re: [HACKERS] Logical replication and inheritance

On 4/16/17 23:00, Amit Langote wrote: >> To fix this, pg_dump should emit ADD TABLE ONLY foo. > > Yeah, that's one way. Attached is a tiny patch for that. > > By the way, I noticed that although grammar accepts ONLY and * against a > table name to affect whether descendant tables are included,

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

On 10.04.2017 14:20, Robert Haas wrote: On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin wrote: 1. I have added a new relkind for local indexes named RELKIND_LOCAL_INDEX (literal 'l'). Seems like it should maybe be RELKIND_PARTITIONED_INDEX. There's nothing

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

> On 17 Apr 2017, at 10:30, Erik Rijkers wrote: > > On 2017-04-16 20:41, Andres Freund wrote: >> On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote: >>> On 2017-04-15 04:47, Erik Rijkers wrote: >>> > >>> > 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch + >>> >

Re: [HACKERS] Different table schema in logical replication crashes

2017-04-14 22:36 GMT-03:00 Petr Jelinek : > I tried something bit different which seems cleaner to me - use the > pstate->r_table instead of ad-hock locally made up range table and fill > that using standard addRangeTableEntryForRelation. Both in tablesync and > in

Re: [HACKERS] Re: logical replication and PANIC during shutdown checkpoint in publisher

On 16/04/17 08:12, Noah Misch wrote: > On Wed, Apr 12, 2017 at 10:55:08PM +0900, Fujii Masao wrote: >> When I shut down the publisher while I repeated creating and dropping >> the subscription in the subscriber, the publisher emitted the following >> PANIC error during shutdown checkpoint. >> >>

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Mon, Apr 17, 2017 at 1:53 PM, Kyotaro HORIGUCHI wrote: > At Thu, 13 Apr 2017 13:04:12 -0400, Robert Haas wrote > in >> On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas

Re: [HACKERS] some review comments on logical rep code

On Mon, Apr 17, 2017 at 7:39 PM, Kyotaro HORIGUCHI wrote: > At Mon, 17 Apr 2017 18:02:57 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] pgbench - allow to store select results into variables

Hello, I think you'd better to change the following comments because there's no psqlscan.l or psqlscanslash.l in pgbench source tree. + * underscore. Keep this in sync with the definition of variable_char in + * psqlscan.l and psqlscanslash.l. Here is a v3 with a more precise comment. --

Re: [HACKERS] some review comments on logical rep code

At Mon, 17 Apr 2017 18:02:57 +0900, Masahiko Sawada wrote in

Re: [HACKERS] Failed recovery with new faster 2PC code

> >> commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71 > >> Author: Simon Riggs > >> Date: Tue Apr 4 15:56:56 2017 -0400 > >> > >>Speedup 2PC recovery by skipping two phase state files in normal path > > > > Thanks Jeff for your tests. > > > > So that's now two crash

Re: [HACKERS] Failed recovery with new faster 2PC code

> On 17 Apr 2017, at 12:14, Simon Riggs wrote: > > On 15 April 2017 at 23:37, Jeff Janes wrote: >> After this commit, I get crash recovery failures when using prepared >> transactions. >> >> commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71 >>

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-17 10:58 GMT+02:00 Fabien COELHO : > > I don't think so :?xxx is good idea, because for me :xxx is related to >> content, not to metadata >> > > Hmmm. Indeed it is not. I do not see it as an issue, but it is a good > point. > > Consider perl "defined $x" or "exists

Re: [HACKERS] Failed recovery with new faster 2PC code

On 15 April 2017 at 23:37, Jeff Janes wrote: > After this commit, I get crash recovery failures when using prepared > transactions. > > commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71 > Author: Simon Riggs > Date: Tue Apr 4 15:56:56 2017 -0400 > >

Re: [HACKERS] pgbench - allow to store select results into variables

Fabien, > Hello Tatsuo-san, > >> Thank you for the patch. I tested a little bit and found that it does >> not allow value replacement against non ascii variables in given SQL >> statements . Is it intentional? > > No, this is a bug. > >> If not, I think you need to fix parseVariable() as well.

[HACKERS] CREATE TRIGGER document typo

Hi, Attached is a patch fixing simple typos in the CREATE TRIGGER document. -- Yugo Nagata diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml index 24195b3..c5f7c75 100644 --- a/doc/src/sgml/ref/create_trigger.sgml +++

Re: [HACKERS] some review comments on logical rep code

On Fri, Apr 14, 2017 at 4:47 AM, Fujii Masao wrote: > Hi, > > Though I've read only a part of the logical rep code yet, I'd like to > share some (relatively minor) review comments that I got so far. It seems nobody is working on dealing with these review comments, so I've

Re: [HACKERS] Variable substitution in psql backtick expansion

I don't think so :?xxx is good idea, because for me :xxx is related to content, not to metadata Hmmm. Indeed it is not. I do not see it as an issue, but it is a good point. Consider perl "defined $x" or "exists $f{k}". $x/$f{k} should be contents, but it is not, the dereferencing is

Re: [HACKERS] [POC] hash partitioning

On Fri, 14 Apr 2017 09:05:14 -0400 Robert Haas wrote: > On Fri, Apr 14, 2017 at 4:23 AM, Yugo Nagata wrote: > > On Thu, 13 Apr 2017 16:40:29 -0400 > > Robert Haas wrote: > >> On Fri, Mar 17, 2017 at 7:57 AM, Yugo Nagata

Re: [HACKERS] Extracting GiST index structure stats?

Hello, On 15.04.2017 20:38, Thomas Mercieca wrote: Hi all, I am interested in getting simple statistics of a GiST index structure. For example, heightof tree. It seems that the other indexes have a metapage for this. I am still unsure but it looks to me like the GiST access method internal

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

At Thu, 13 Apr 2017 13:04:12 -0400, Robert Haas wrote in > On Thu, Apr 21, 2016 at 10:53 AM, Robert Haas wrote: > > On Thu, Apr 21, 2016 at 8:44 AM, Michael Paquier > >

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

On 2017-04-16 20:41, Andres Freund wrote: On 2017-04-16 10:46:21 +0200, Erik Rijkers wrote: On 2017-04-15 04:47, Erik Rijkers wrote: > > 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch + > 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+ >

Re: [HACKERS] Variable substitution in psql backtick expansion

> > > 4. because pgbench doesn't do early variable evaluation, implementation of >> "defined" function is easy - we can introduce some new syntax for >> implementation some bash patterns like "default value" or "own undefined >> message" >> > > Maybe. ISTM that a :* syntax should be thought for so

Re: [HACKERS] pgbench - allow to store select results into variables

It seems the new feature \gset doesn't work with tables having none ascii column names: Indeed. The same error is triggered with the \set syntax, which does not involve any query execution. I have added a sentence mentionning the restriction when variables are first discussed in the

Re: [HACKERS] pgbench - allow to store select results into variables

Hello Tatsuo-san, Thank you for the patch. I tested a little bit and found that it does not allow value replacement against non ascii variables in given SQL statements . Is it intentional? No, this is a bug. If not, I think you need to fix parseVariable() as well. Indeed. Here is v2. --

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, A more detailed answer to your many points. The pgbench expression language is perfect for us - there is not any new dependency - it is working on all supported platforms. Can be nice, if we can reuse pgbench expressions in psql - there are some task that should be solved first

Re: [HACKERS] Shouldn't duplicate addition to publication be a no-op?

On 2017/04/17 14:46, Robert Haas wrote: > On Sun, Apr 16, 2017 at 11:58 PM, Amit Langote > wrote: >> By the way, Petr said in the other thread that it could be made a no-op >> (presumably without requiring IF NOT EXISTS) on the grounds that >> membership of table in