Re: [HACKERS] UPDATE of partition key

>> 3. >> + longer satisfy the partition constraint of the containing partition. In >> that >> + case, if there is some other partition in the partition tree for which >> this >> + row satisfies its partition constraint, then the row is moved to that >> + partition. If there isn't such a

Re: [HACKERS] [POC] hash partitioning

On Fri, May 12, 2017 at 8:08 AM, Amit Langote wrote: > On 2017/05/12 11:20, Robert Haas wrote: >> On Thu, May 11, 2017 at 10:15 PM, Amit Langote >> wrote: >>> On 2017/05/12 10:42, Robert Haas wrote: On Thu, May 11, 2017 at 12:02

Re: [HACKERS] UPDATE of partition key

On 12 May 2017 at 08:30, Amit Kapila wrote: > On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar > wrote: >> On 11 May 2017 at 17:23, Amit Kapila wrote: >>> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar

Re: [HACKERS] UPDATE of partition key

On 12 May 2017 at 10:01, Amit Kapila wrote: > On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote: >> On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar >> wrote: >>> On 11 May 2017 at 17:24, Amit Kapila

Re: [HACKERS] [POC] hash partitioning

On Fri, May 12, 2017 at 7:12 AM, Robert Haas wrote: > On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote: >> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL >> for hash also, right? > > I think it should. > +1 As long as we

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki wrote: > Likewise, when the first host has already reached max_connections, libpq > doesn't attempt the connection aginst later hosts. It seems to me that the feature is behaving as wanted. Or in short attempt

Re: [HACKERS] UPDATE of partition key

On Fri, May 12, 2017 at 9:27 AM, Amit Kapila wrote: > On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar > wrote: >> On 11 May 2017 at 17:24, Amit Kapila wrote: >>> Few comments: >>> 1. >>> Operating directly on partition

[HACKERS] Improvement in log message of logical replication worker

Hi, When I created a subscription with copydata option that corresponds to a publication that includes several tables, I got the following log messages. [7019] LOG: starting logical replication worker for subscription "hoge_sub" [7047] LOG: logical replication apply for subscription hoge_sub

[HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello, I found a problem with libpq connection failover. When libpq cannot connect to earlier hosts in the host list, it doesn't try to connect to other hosts. For example, when you specify a wrong port that some non-postgres program is using, or some non-postgres program is using PG's port

[HACKERS] Hash Functions

https://www.postgresql.org/message-id/camp0ubeo3fzzefie1vmc1ajkkrpxlnzqooaseu6o-c+...@mail.gmail.com In that thread, I pointed out some important considerations for the hash functions themselves. This is a follow-up, after I looked more carefully. 1. The hash functions as they exist today

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/11/17, 7:20 PM, "Michael Paquier" wrote: > Browsing the code Thanks for taking a look. > It seems to me that you don't need those extra square brackets around > the column list. Same remark for vacuum.sgml. I’ll remove them. My intent was to ensure that we

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund writes: > On 2017-05-11 17:21:18 -0400, Tom Lane wrote: >> I doubt my machine is 6X faster than yours, >> so this indicates that the subtransaction overhead is pretty real. > Isn't that pretty much the point? The whole open_share_lock() > optimization looks

Re: [HACKERS] UPDATE of partition key

On Thu, May 11, 2017 at 5:45 PM, Amit Khandekar wrote: > On 11 May 2017 at 17:24, Amit Kapila wrote: >> Few comments: >> 1. >> Operating directly on partition doesn't allow update to move row. >> Refer below example: >> create table t1(c1 int)

Re: [HACKERS] PG 10 release notes

Michael Paquier writes: > Bruce, the release notes do not mention yet that support for cleartext > passwords is removed. This has been done recently by Heikki in > eb61136d. This has as consequence that CREATE ROLE PASSWORD > UNENCRYPTED returns an error, and that

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

Robert Haas writes: > On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada > wrote: >> ... I'd like to propose to change relation >> extension lock management so that it works using LWLock instead. > That's not a good idea because it'll make the code

Re: [HACKERS] PG 10 release notes

On Mon, May 8, 2017 at 10:50 PM, Bruce Momjian wrote: > [other stuff] Bruce, the release notes do not mention yet that support for cleartext passwords is removed. This has been done recently by Heikki in eb61136d. This has as consequence that CREATE ROLE PASSWORD UNENCRYPTED

Re: [HACKERS] multi-column range partition constraint

On Wed, May 10, 2017 at 10:21 PM, Amit Langote wrote: >> Next update on this issue by Thursday 5/11. > > Attached updated patches. Thanks. 0001, at least, really needs a pgindent run. Also, my compiler has this apparently-justifiable complaint:

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Neha Khatri writes: > On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote: >> Neha Khatri writes: >>> Following are pg_controldata interfaces that might require change: >>> Latest checkpoint location: >>> Prior checkpoint location:

Re: [HACKERS] UPDATE of partition key

On Thu, May 11, 2017 at 5:41 PM, Amit Khandekar wrote: > On 11 May 2017 at 17:23, Amit Kapila wrote: >> On Fri, Mar 17, 2017 at 4:07 PM, Amit Khandekar >> wrote: >>> On 4 March 2017 at 12:49, Robert Haas

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Hmm, yeah, makes sense. Here's a patch for this approach. I did some code review on this patch. The attached update makes the following hopefully-uncontroversial changes: * fix inconsistencies in the set of fields in CreateStatsStmt * get

Re: [HACKERS] Race conditions with WAL sender PID lookups

On Thu, May 11, 2017 at 10:48 AM, Michael Paquier wrote: > Hi all, > > I had my eyes on the WAL sender code this morning, and I have noticed > that walsender.c is not completely consistent with the PID lookups it > does in walsender.c. In two code paths, the PID value

Re: [HACKERS] Adding support for Default partition in partitioning

On Thu, May 11, 2017 at 10:07 AM, Rahila Syed wrote: > Please find attached an updated patch with review comments and bugs reported > till date implemented. You haven't done anything about the repeated suggestion that this should also cover range partitioning. +

Re: [HACKERS] [POC] hash partitioning

On 2017/05/12 11:20, Robert Haas wrote: > On Thu, May 11, 2017 at 10:15 PM, Amit Langote > wrote: >> On 2017/05/12 10:42, Robert Haas wrote: >>> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote: We need to add PARTITION_STRATEGY_HASH

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote: > Neha Khatri writes: > > [In case forgotten] pg_controdata and pg_waldump interfaces should also > be > > considered for this standardization. > > > Following are pg_controldata interfaces that might

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Thu, May 11, 2017 at 6:16 PM, Petr Jelinek wrote: > On 11/05/17 10:10, Masahiko Sawada wrote: >> On Thu, May 11, 2017 at 4:06 PM, Michael Paquier >> wrote: >>> On Wed, May 10, 2017 at 11:57 AM, Masahiko Sawada

Re: [HACKERS] [POC] hash partitioning

On Thu, May 11, 2017 at 10:15 PM, Amit Langote wrote: > On 2017/05/12 10:42, Robert Haas wrote: >> On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote: >>> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL >>> for hash

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Fri, May 12, 2017 at 9:47 AM, Bossart, Nathan wrote: > Attached is a more complete first attempt at adding this functionality. I > added two node types: one for parsing the “relation and columns” list in the > grammar, and one for holding the relation information we

Re: [HACKERS] [POC] hash partitioning

On 2017/05/12 10:42, Robert Haas wrote: > On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote: >> We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL >> for hash also, right? > > I think it should. > > Actually, I think that not supporting nulls for

Re: [HACKERS] Addition of pg_dump --no-publications

On Thu, May 11, 2017 at 3:19 PM, Michael Paquier wrote: > I imagine that pg_dump -s would be the basic operation that users > would do first before creating a subcription on a secondary node, but > what I find surprising is that publications are dumped by default. I >

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

On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada wrote: > Currently, the relation extension lock is implemented using > heavyweight lock manager and almost functions (except for > brin_page_cleanup) using LockRelationForExntesion use it with > ExclusiveLock mode. But

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 9:33 AM, Tom Lane wrote: > Uh ... what in that is creating the already-extant parent? /me looks embarrassed. Never mind. I didn't read what you wrote carefully enough. >> I think one answer to the original complaint might be to add a new >> flag to

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 5/11/17, 6:32 PM, "Tom Lane" wrote: > You probably won't get much in the near term, because we're in > stabilize-the-release mode not develop-new-features mode. > Please add your patch to the pending commitfest > https://commitfest.postgresql.org/14/ > so that we remember

Re: [HACKERS] [POC] hash partitioning

On Thu, May 11, 2017 at 12:02 PM, Dilip Kumar wrote: > We need to add PARTITION_STRATEGY_HASH as well, we don't support NULL > for hash also, right? I think it should. Actually, I think that not supporting nulls for range partitioning may have been a fairly bad decision.

Re: [HACKERS] Row Level Security Documentation

Of course, better thoughts appear immediately after hitting the send button. This version of the table attempts to stipulate which section of the process the rule applies to. On Thu, May 11, 2017 at 8:40 PM, Rod Taylor wrote: > I think the biggest piece missing is

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

"Bossart, Nathan" writes: > Looking forward to any feedback that you have. You probably won't get much in the near term, because we're in stabilize-the-release mode not develop-new-features mode. Please add your patch to the pending commitfest

Re: [HACKERS] snapbuild woes

On 2017-05-11 14:54:26 -0700, Andres Freund wrote: > On 2017-05-11 14:51:55 -0700, wrote: > > On 2017-05-08 00:10:12 -0700, Andres Freund wrote: > > > I plan to commit the next pending patch after the back branch releases > > > are cut - it's an invasive fix and the issue doesn't cause corruption

Re: [HACKERS] Cached plans and statement generalization

On Thu, May 11, 2017 at 10:41:45PM +0300, Konstantin Knizhnik wrote: > This is why I have provided second implementation which replace > literals with parameters after raw parsing. Certainly it is slower > than first approach. But still provide significant advantage in > performance: more than

[HACKERS] Row Level Security Documentation

I think the biggest piece missing is something to summarize the giant blocks of text. Attached is a table that has commands and policy types, and a "yes" if it applies. -- Rod Taylor diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml index

Re: [HACKERS] A design for amcheck heapam verification

On Mon, May 1, 2017 at 6:39 PM, Peter Geoghegan wrote: > On Mon, May 1, 2017 at 6:20 PM, Tom Lane wrote: >> Maybe you can fix this by assuming that your own session's advertised xmin >> is a safe upper bound on everybody else's RecentGlobalXmin. But I'm not >>

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > BTW the new castNode() family of macros don't work with Value nodes > (because the tags are different depending on what's stored, but each > type does not have its own struct. Oh well.) Yeah. Value nodes are pretty much of a wart --- it's not

Re: [HACKERS] WITH clause in CREATE STATISTICS

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Have you thought further about the upthread suggestion to just borrow > >> SELECT's syntax lock stock and barrel? > > > Bison seems to like the productions below. Is this what you had in > > mind? These

Re: [HACKERS] snapbuild woes

On 2017-04-15 05:18:49 +0200, Petr Jelinek wrote: > >>> From 3318a929e691870f3c1ca665bec3bfa8ea2af2a8 Mon Sep 17 00:00:00 2001 > >>> From: Petr Jelinek > >>> Date: Sun, 26 Feb 2017 01:07:33 +0100 > >>> Subject: [PATCH 3/5] Prevent snapshot builder xmin from going backwards >

Re: [HACKERS] snapbuild woes

On 2017-05-11 14:51:55 -0700, wrote: > On 2017-05-08 00:10:12 -0700, Andres Freund wrote: > > I plan to commit the next pending patch after the back branch releases > > are cut - it's an invasive fix and the issue doesn't cause corruption > > "just" slow slot creation. So it seems better to wait

Re: [HACKERS] snapbuild woes

On Thu, May 11, 2017 at 2:51 PM, Andres Freund wrote: > Now that that's done, here's an updated version of that patch. Note the > new logic to trigger xl_running_xact's to be logged at the right spot. > Works well in my testing. You forgot the patch. :-) -- Peter

Re: [HACKERS] snapbuild woes

On 2017-05-08 00:10:12 -0700, Andres Freund wrote: > I plan to commit the next pending patch after the back branch releases > are cut - it's an invasive fix and the issue doesn't cause corruption > "just" slow slot creation. So it seems better to wait for a few days, > rather than hurry it into

Re: [HACKERS] CTE inlining

Ilya Shkuratov wrote > First of all, to such replacement to be valid, the CTE must be > 1. non-writable (e.g. be of form: SELECT ...), > 2. do not use VOLATILE or STABLE functions, > 3. ... (maybe there must be more restrictions?) What about simple things like this? CREATE OR

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 2017-05-11 17:21:18 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > I ran this script > > > CREATE SEQUENCE seq1; > > > DO LANGUAGE plpythonu $$ > > plan = plpy.prepare("SELECT nextval('seq1')") > > for i in range(0, 1000): > >

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund writes: > On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote: >> (So without contention fast-path locking beats the extra dance that >> open_share_lock() does.) > That's kind of surprising, I really wouldn't have thought it'd be faster > without. I guess it's

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Peter Eisentraut writes: > I ran this script > CREATE SEQUENCE seq1; > DO LANGUAGE plpythonu $$ > plan = plpy.prepare("SELECT nextval('seq1')") > for i in range(0, 1000): > plpy.execute(plan) > $$; > and timed the "DO". It occurred to me that

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Hi, On 2017-05-11 16:27:48 -0400, Peter Eisentraut wrote: > On 5/10/17 12:24, Andres Freund wrote: > > Upthread I theorized whether > > that's actually still meaningful given fastpath locking and such, but I > > guess we'll have to evaluate that. > > I did some testing. That's with the

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Peter Eisentraut writes: > On 5/10/17 12:24, Andres Freund wrote: >> Upthread I theorized whether >> that's actually still meaningful given fastpath locking and such, but I >> guess we'll have to evaluate that. > [ with or without contention, fast-path locking

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 2017-05-11 11:35:22 -0400, Peter Eisentraut wrote: > On 5/10/17 12:24, Andres Freund wrote: > > The issue isn't the strength, but that we currently have this weird > > hackery around open_share_lock(): > > /* > > * Open the sequence and acquire AccessShareLock if needed > > * > > * If we

Re: [HACKERS] Cached plans and statement generalization

On 05/11/2017 10:52 PM, Andres Freund wrote: On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote: On 05/11/2017 09:31 PM, Tom Lane wrote: Bruce Momjian writes: Good point. I think we need to do some measurements to see if the parser-only stage is actually significant.

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 5/10/17 12:24, Andres Freund wrote: > Upthread I theorized whether > that's actually still meaningful given fastpath locking and such, but I > guess we'll have to evaluate that. I did some testing. I ran this script CREATE SEQUENCE seq1; DO LANGUAGE plpythonu $$ plan = plpy.prepare("SELECT

Re: [HACKERS] Cached plans and statement generalization

On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote: > On 05/11/2017 09:31 PM, Tom Lane wrote: > > Bruce Momjian writes: > > > Good point. I think we need to do some measurements to see if the > > > parser-only stage is actually significant. I have a hunch that > > >

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Tom Lane wrote: >> Have you thought further about the upthread suggestion to just borrow >> SELECT's syntax lock stock and barrel? > Bison seems to like the productions below. Is this what you had in > mind? These mostly mimic joined_table and

Re: [HACKERS] Cached plans and statement generalization

On 05/11/2017 09:31 PM, Tom Lane wrote: Bruce Momjian writes: Good point. I think we need to do some measurements to see if the parser-only stage is actually significant. I have a hunch that commercial databases have much heavier parsers than we do. FWIW, gram.y does show

Re: [HACKERS] Cached plans and statement generalization

On 05/11/2017 06:12 PM, Bruce Momjian wrote: On Wed, May 10, 2017 at 07:11:07PM +0300, Konstantin Knizhnik wrote: I am going to continue work on this patch I will be glad to receive any feedback and suggestions for its improvement. In most cases, applications are not accessing Postgres

Re: [HACKERS] WITH clause in CREATE STATISTICS

Tom Lane wrote: > Have you thought further about the upthread suggestion to just borrow > SELECT's syntax lock stock and barrel? That is, it'd look something > like > > CREATE STATISTICS name [(list of stats types)] expression-list FROM ... > [ WHERE ... ] [ WITH (options) ] > > This would

Re: [HACKERS] Cached plans and statement generalization

On May 11, 2017 11:31:02 AM PDT, Tom Lane wrote: >Bruce Momjian writes: >> Good point. I think we need to do some measurements to see if the >> parser-only stage is actually significant. I have a hunch that >> commercial databases have much heavier

Re: [HACKERS] Cached plans and statement generalization

Bruce Momjian writes: > Good point. I think we need to do some measurements to see if the > parser-only stage is actually significant. I have a hunch that > commercial databases have much heavier parsers than we do. FWIW, gram.y does show up as significant in many of the

Re: [HACKERS] Logical decoding truncate

2017-05-11 4:23 GMT-03:00 Friedrich, Steffen < steffen.friedr...@dieboldnixdorf.com>: > I am writing a logical decoding output plugin decoding WAL to SQL which is > finally applied to target database. > > > > Is it possible to decode a TRUNCATE statement and the tables involved? > > Yes, use

Re: [HACKERS] Cached plans and statement generalization

On Thu, May 11, 2017 at 05:39:58PM +, Douglas Doole wrote: > One interesting idea from Doug Doole was to do it between the tokenizer > and > parser.  I think they are glued together so you would need a way to run > the > tokenizer separately and compare that to the tokens you

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

On Thu, May 11, 2017 at 05:24:16PM +0200, Remi Colinet wrote: > 2017-05-10 21:52 GMT+02:00 David Fetter : > > > On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote: > > > Hello, > > > > > > This is version 2 of the new command name PROGRESS which I wrote in > > > order

Re: [HACKERS] Cached plans and statement generalization

> > One interesting idea from Doug Doole was to do it between the tokenizer > and parser. I think they are glued together so you would need a way to run > the tokenizer separately and compare that to the tokens you stored for the > cached plan. > When I did this, we had the same problem that the

Re: [HACKERS] Time based lag tracking for logical replication

On 11 May 2017 at 18:13, Andres Freund wrote: >>New patch, v3. >> >>Applying in 90 minutes, barring objections. > > Could you please wait till tomorrow? I've bigger pending fixes for related > code pending/being tested that I plan to push today. I'd also like to take a >

Re: [HACKERS] WITH clause in CREATE STATISTICS

Tom Lane wrote: > Have you thought further about the upthread suggestion to just borrow > SELECT's syntax lock stock and barrel? That is, it'd look something > like > > CREATE STATISTICS name [(list of stats types)] expression-list FROM ... > [ WHERE ... ] [ WITH (options) ] > > This would

Re: [HACKERS] Safer and faster get_attstatsslot()

Simon Riggs writes: > On 11 May 2017 at 17:41, Tom Lane wrote: >> ...because code that worked fine for Peter and me failed >> erratically in the buildfarm. > I think its always a little bit too exciting for me also. > I suggest we have a commit tree

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Tom Lane wrote: >> Hmm ... I'm not sure that I buy that particular argument. If you're >> concerned that the grammar could not handle "FROM x JOIN y USING (z)", >> wouldn't it also have a problem with "FROM x JOIN y ON (z)"? > Tomas spent some

Re: [HACKERS] Time based lag tracking for logical replication

On May 11, 2017 8:08:11 AM PDT, Simon Riggs wrote: >On 11 May 2017 at 14:12, Petr Jelinek >wrote: > >>> Attached patch is Petr's patch, slightly rebased with added pacing >>> delay, similar to that used by HSFeedback. >>> >> >> This looks

Re: [HACKERS] WITH clause in CREATE STATISTICS

Tom Lane wrote: > Hmm ... I'm not sure that I buy that particular argument. If you're > concerned that the grammar could not handle "FROM x JOIN y USING (z)", > wouldn't it also have a problem with "FROM x JOIN y ON (z)"? > > It might work anyway, since the grammar should know whether ON or

Re: [HACKERS] Safer and faster get_attstatsslot()

On 11 May 2017 at 17:41, Tom Lane wrote: > ...because code that worked fine for Peter and me failed > erratically in the buildfarm. I think its always a little bit too exciting for me also. I suggest we have a commit tree and a main tree, with automatic copying from commit

Re: [HACKERS] export import bytea from psql

2017-05-11 17:16 GMT+02:00 Daniel Verite : > Pavel Stehule wrote: > > > It is similar to my first or second proposal - rejected by Tom :( > > Doesn't it differ? ISTM that in the patches/discussion related to: > https://commitfest.postgresql.org/11/787/ > it was

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Heikki Linnakangas writes: > On 05/11/2017 06:21 PM, Tom Lane wrote: >>> On a side-note, I find it a bit awkward that ScalarArrayOpExpr uses a >>> 2-element List to hold the scalar and array arguments. Wouldn't it be >>> much more straightforward to have explicit "Expr

[HACKERS] Safer and faster get_attstatsslot()

Monday's round of security patches was a lot more exciting than I would have liked, because code that worked fine for Peter and me failed erratically in the buildfarm. What eventually emerged was that I'd added some missing free_attstatsslot() calls in rangetypes_selfuncs.c, and naively copied

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

On 05/11/2017 06:21 PM, Tom Lane wrote: Heikki Linnakangas writes: Eval_const_expressions() doesn't know about ScalarArrayOpExpr. ... That seems like an oversight. I guess that scenario doesn't happen very often in practice, but there's no reason not to do it when it does.

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

Thx for your comment. Based on other comments, I will probably convert the command into a SQL function. This allows passing arguments such as the one which can be used in the current command (VERBOSE, FORMAT). This will avoid keyword collisions. Regards Remi 2017-05-10 22:04 GMT+02:00 Pavel

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-11 4:05 GMT+02:00 Michael Paquier : > On Thu, May 11, 2017 at 1:40 AM, Remi Colinet > wrote: > > This is version 2 of the new command name PROGRESS which I wrote in > order to > > monitor long running SQL queries in a Postgres backend

Re: [HACKERS] [POC] hash partitioning

On Wed, May 3, 2017 at 6:39 PM, amul sul wrote: > On Thu, Apr 27, 2017 at 1:42 AM, Robert Haas wrote: > >>I spent some time today looking at these patches. It seems like there >>is some more work still needed here to produce something committable

Re: [HACKERS] renaming "transaction log"

Peter Eisentraut writes: > Most documentation and error messages still uses the term "transaction > log" to refer to the write-ahead log. Here is a patch to rename that, > which I think should be done, to match the xlog -> wal renaming in APIs. This will need

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 5/10/17 12:24, Andres Freund wrote: > The issue isn't the strength, but that we currently have this weird > hackery around open_share_lock(): > /* > * Open the sequence and acquire AccessShareLock if needed > * > * If we haven't touched the sequence already in this transaction, > * we need

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

That's good point. I will probably convert the new command to a SQL function. I was fumbling between a table or a SQL function. Oracle uses v$session_longops to track progression of long running SQL queries which have run for more than 6 seconds. But a function is much better to provide

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Heikki Linnakangas writes: > Eval_const_expressions() doesn't know about ScalarArrayOpExpr. > ... > That seems like an oversight. I guess that scenario doesn't happen very > often in practice, but there's no reason not to do it when it does. > Patch attached. Yeah, I think

Re: [HACKERS] export import bytea from psql

Pavel Stehule wrote: > It is similar to my first or second proposal - rejected by Tom :( Doesn't it differ? ISTM that in the patches/discussion related to: https://commitfest.postgresql.org/11/787/ it was proposed to change \set in one way or another, and also in the point #1 of this

Re: [HACKERS] Cached plans and statement generalization

On Wed, May 10, 2017 at 07:11:07PM +0300, Konstantin Knizhnik wrote: > I am going to continue work on this patch I will be glad to receive any > feedback and suggestions for its improvement. > In most cases, applications are not accessing Postgres directly, but using > some connection pooling

Re: [HACKERS] Time based lag tracking for logical replication

On 11 May 2017 at 14:12, Petr Jelinek wrote: >> Attached patch is Petr's patch, slightly rebased with added pacing >> delay, similar to that used by HSFeedback. >> > > This looks reasonable. I would perhaps change: >> + /* >> +* Track lag no more than

[HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Eval_const_expressions() doesn't know about ScalarArrayOpExpr. We simplify the arguments, but if all the arguments are booleans, we don't take the obvious step of replacing the whole expression with a boolean Const. For example: postgres=# explain select * from foo where 1 IN (1,2,3);

Re: [HACKERS] snapbuild woes

On 11/05/17 16:33, Stas Kelvich wrote: > >> On 10 May 2017, at 11:43, Petr Jelinek wrote: >> >> On 09/05/17 22:11, Erik Rijkers wrote: >>> On 2017-05-09 21:00, Petr Jelinek wrote: On 09/05/17 19:54, Erik Rijkers wrote: > On 2017-05-09 11:50, Petr Jelinek

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Neha Khatri writes: > [In case forgotten] pg_controdata and pg_waldump interfaces should also be > considered for this standardization. > Following are pg_controldata interfaces that might require change: > Latest checkpoint location: > Prior checkpoint location: >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Michael Paquier writes: > On Thu, May 11, 2017 at 9:15 AM, Bruce Momjian wrote: >> On Wed, May 10, 2017 at 01:09:36PM -0700, Joe Conway wrote: > On 05/10/2017 12:22 PM, Tom Lane wrote: >>> Hm, well, anybody else want to vote? >>> +1 for #2 >> Same,

Re: [HACKERS] snapbuild woes

> On 10 May 2017, at 11:43, Petr Jelinek wrote: > > On 09/05/17 22:11, Erik Rijkers wrote: >> On 2017-05-09 21:00, Petr Jelinek wrote: >>> On 09/05/17 19:54, Erik Rijkers wrote: On 2017-05-09 11:50, Petr Jelinek wrote: >>> >>> Ah okay, so this is same

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, Please find attached an updated patch with review comments and bugs reported till date implemented. >1. >In following block, we can just do with def_index, and we do not need found_def >flag. We can check if def_index is -1 or not to decide if default partition is >present. found_def is

Re: [HACKERS] If subscription to foreign table valid ?

Hi, On 11/05/17 14:25, tushar wrote: > Hi, > > I observed that -we cannot publish "foreign table" in Publication > > postgres=# create foreign table t (n int) server db1_server options > (table_name 't1'); > CREATE FOREIGN TABLE > > postgres=# create publication pub for table t; > ERROR: "t"

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

That's a good point. A command is more straightforward because it targets only one backend. The user is supposed to know which backend pid is taking a long time to complete based on pg_stat_activity(). This is somehow the same approach as EXPLAIN command. But the use is limited to psql utility.

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Robert Haas writes: > On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote: >> You could argue that it would be better for pg_dump to emit something >> like >> >> CREATE TABLE c (...); >> ALTER TABLE c INHERIT p; >> >> so that if p isn't around, at least c

Re: [HACKERS] If subscription to foreign table valid ?

On Thu, May 11, 2017 at 8:25 AM, tushar wrote: > I observed that -we cannot publish "foreign table" in Publication > > postgres=# create foreign table t (n int) server db1_server options > (table_name 't1'); > CREATE FOREIGN TABLE > > postgres=# create publication

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

Do you have more details about the failed tests? Regards, Remi 2017-05-06 5:38 GMT+02:00 Vinayak Pokale : > > On Mon, Apr 17, 2017 at 9:09 PM, Remi Colinet > wrote: > >> Hello, >> >> I've implemented a new command named PROGRESS to monitor

[HACKERS] Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Thu, May 11, 2017 at 3:38 AM, 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] SCRAM in the PG 10 release notes

Heikki Linnakangas writes: > I updated the List of Drivers in the Wiki. I added a few drivers that > were missing, like the ODBC driver, and the pgtclng driver, as well as a > Go and Rust driver that I'm aware of. I reformatted it, and added a > column to indicate whether each

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Thu, May 11, 2017 at 9:02 AM, Tom Lane wrote: > Jeevan Ladhe writes: >> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat < >>> We add PARTITION OF clause for a table which is partition, so if the >>> parent is not present while restoring, the

  1   2   >