Re: [HACKERS] Walsender timeouts and large transactions

Hello Sokolov. At Fri, 29 Sep 2017 15:19:23 +0300, Sokolov Yura wrote in > I don't want to make test to lasts so long and generate so many data. > That is why I used such small timeouts for tests. I understand your

Re: [HACKERS] Logging idle checkpoints

On 2017-10-02 07:43:31 +0900, Michael Paquier wrote: > On Mon, Oct 2, 2017 at 7:41 AM, Andres Freund wrote: > > On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: > >> On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > >> > On 2017-10-02 00:19:33

Re: [HACKERS] [PATCH] Off-by-one error in logical slot resource retention

On 2 October 2017 at 05:27, Daniel Gustafsson wrote: > > On 15 Sep 2017, at 13:26, Daniel Gustafsson wrote: > > > >> On 01 Sep 2017, at 14:28, Aleksander Alekseev < > a.aleks...@postgrespro.ru> wrote: > >> > >> The following review has been posted through the

Re: [HACKERS] pg_prepared_xact_status

On 30 September 2017 at 14:10, konstantin knizhnik < k.knizh...@postgrespro.ru> wrote: > So I do not see any troubles caused by adding this functions. And it can > really be helpful for DBA in some cases. > If it's self-contained and exposes existing functionality, then I'm not opposed, I just

Re: [HACKERS] pg_prepared_xact_status

On 2 October 2017 at 08:09, Robert Haas wrote: > On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik > wrote: > > txid_status() also not always be able to return status of transaction > (if wraparound happen). > > But it is still considered as

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

Thanks for the objection with clear reasoning. For clarity, I first proposed to prohibit servers of different versions from sharing same tablespace directory. https://www.postgresql.org/message-id/20170406.160844.120459562.horiguchi.kyot...@lab.ntt.co.jp And I had -1 that it is just a reverting

Re: [HACKERS] path toward faster partition pruning

On 2017/09/30 1:28, Robert Haas wrote: > On Thu, Sep 28, 2017 at 5:16 AM, David Rowley > wrote: >> I'd imagine, for >> each partition key, you'd want to store a Datum with the minimum and >> maximum possible value based on the quals processed. If either the >>

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

> On 06 Sep 2017, at 08:42, Fabien COELHO wrote: > > Hello Alik, > > Applies, compiles, works for me. > > Some minor comments and suggestions. > > Two typos: > - "usinng" -> "using" > - "a rejection method used" -> "a rejection method is used" > > I'm not sure of

Re: [HACKERS] Small patch for pg_basebackup argument parsing

> On 18 Sep 2017, at 23:18, Pierre Ducroquet wrote: > > On Monday, September 18, 2017 5:13:38 PM CEST Tom Lane wrote: >> Ryan Murphy writes: >>> Looked thru the diffs and it looks fine to me. >>> Changing a lot of a integer/long arguments that were

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 28 Sep 2017, at 14:55, Yugo Nagata wrote: > > On Sun, 3 Sep 2017 22:47:10 +0200 > Daniel Gustafsson wrote: > > I have reviewed your latest patch. > > I can apply this to the master branch and build this successfully, > and the behavior is as

Re: [HACKERS] CLUSTER command progress monitor

> On 12 Sep 2017, at 14:57, Tatsuro Yamada wrote: > > On 2017/09/12 21:20, Tatsuro Yamada wrote: >> On 2017/09/11 23:38, Robert Haas wrote: >>> On Sun, Sep 10, 2017 at 10:36 PM, Tatsuro Yamada >>> wrote: Thanks for the comment.

Re: [HACKERS] Fwd: Have a problem with citext

On Fri, Sep 29, 2017 at 6:16 PM, David E. Wheeler wrote: > Are permissions correct in the citext extension? Not to be picky, but couldn't you investigate that a bit before posting here? Off-hand, I see no GRANT or REVOKE statements in any of the citext SQL files, so I'm

Re: [HACKERS] pg_prepared_xact_status

On Mon, Oct 2, 2017 at 9:09 AM, Robert Haas wrote: > On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik > wrote: >> txid_status() also not always be able to return status of transaction (if >> wraparound happen). >> But it is still considered

Re: [HACKERS] pg_prepared_xact_status

On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik wrote: > txid_status() also not always be able to return status of transaction (if > wraparound happen). > But it is still considered as one of the key features of 10 (transaction > traceability...). Not by me.

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

> On 08 Apr 2017, at 16:14, David Steele wrote: > > On 3/22/17 6:20 AM, Etsuro Fujita wrote: >> On 2017/02/22 19:57, Rushabh Lathia wrote: >>> Marked this as Ready for Committer. >> >> I noticed that this item in the CF app was incorrectly marked as >> Committed. This

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

> On 11 Apr 2017, at 10:55, Etsuro Fujita wrote: > > On 2017/04/07 22:54, Arthur Zakirov wrote: >> Marked the patch as "Ready for Commiter". But the patch should be >> commited only after the patch [1]. > > Thanks for reviewing! I'll continue to work on this for

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

> On 20 Sep 2017, at 01:05, David G. Johnston > wrote: > > On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane > wrote: > ​T​hat​ ​doesn't work today, and this patch doesn't fix it, but it does create > enough confusion that

Re: [HACKERS] parallelize queries containing initplans

> On 15 Sep 2017, at 04:45, Amit Kapila wrote: > > On Thu, Aug 31, 2017 at 11:23 AM, Amit Kapila wrote: >> On Mon, Aug 21, 2017 at 2:40 PM, Amit Kapila wrote: >>> On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi >>>

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

> On 18 Aug 2017, at 13:39, Claudio Freire wrote: > > On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire > wrote: >> Indeed they do, and that's what motivated this patch. But I'd need >> TB-sized tables to set up something like that. I don't have

Re: [HACKERS] 64-bit queryId?

On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark wrote: > Well these kinds of monitoring systems tend to be used by operations > people who are a lot more practical and a lot less worried about > theoretical concerns like that. +1, well said. > In context the point was merely that the

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

> On 02 Sep 2017, at 14:17, Michael Paquier wrote: > > On Fri, Sep 1, 2017 at 7:17 PM, Thomas Munro > wrote: >> On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote: >>> On Sat, Apr 8, 2017 at 10:05 AM, David Steele

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

I wrote: > This patch no longer applies cleanly on HEAD, so here's a rebased version > (no substantive changes). As before, I think the most useful review task > would be to quantify whether it makes planning noticeably slower. Rebased again (over the arrays-of-domains patch).

Re: [HACKERS] Logging idle checkpoints

On Mon, Oct 2, 2017 at 7:41 AM, Andres Freund wrote: > On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: >> On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: >> > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: >> > I'd be ok with applying this now,

Re: [HACKERS] Logging idle checkpoints

On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: > On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > > I'd be ok with applying this now, or in 10.1 - but I do think we should > > fix this before 11. If nobody

Re: [HACKERS] Logging idle checkpoints

On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > I'd be ok with applying this now, or in 10.1 - but I do think we should > fix this before 11. If nobody protests I'll push later today, so we can > get some bf cycles for

Re: [HACKERS] Logging idle checkpoints

Hi, On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > I recently had a sad because I noticed that checkpoint counts were > increasing in pg_stat_bgwriter, but weren't accounted for in my logs > with log_checkpoints enabled. > > After some searching, I found that it was the idle checkpoints that

Re: [HACKERS] Statement-level rollback

> On 15 Sep 2017, at 16:19, Daniel Gustafsson wrote: > >> On 01 Sep 2017, at 13:44, Simon Riggs wrote: >> >> On 14 August 2017 at 23:58, Peter Eisentraut >> wrote: >>> On 2/28/17 02:39, Tsunakawa, Takayuki wrote:

[HACKERS] Logging idle checkpoints

I recently had a sad because I noticed that checkpoint counts were increasing in pg_stat_bgwriter, but weren't accounted for in my logs with log_checkpoints enabled. After some searching, I found that it was the idle checkpoints that weren't being logged. I think this is a missed trick in

Re: [HACKERS] ANALYZE command progress checker

> On 05 Apr 2017, at 03:17, Masahiko Sawada wrote: > > On Wed, Apr 5, 2017 at 1:49 AM, Robert Haas wrote: >> On Tue, Apr 4, 2017 at 4:57 AM, Amit Langote >> wrote: >>> Hmm, you're right. It could be counted with a

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 18:01:27 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: > >> So we can leave it out of there. OTOH I'm not a huge fan of security by > >> obscurity. I guess this wouldn't be too bad a case. > > > I'd

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

Andres Freund writes: > On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: >> So we can leave it out of there. OTOH I'm not a huge fan of security by >> obscurity. I guess this wouldn't be too bad a case. > I'd personally include it, given that we already allow and document

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

> On 27 Aug 2017, at 08:37, Fabien COELHO wrote: > > > About the patch: > > I'm generally in favor of providing more options to pgbench, especially if it > can give optimization ideas to the performance conscious user. > > I think that the name should be

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: > > > On 10/01/2017 04:48 PM, Andres Freund wrote: > > On 2017-10-01 16:42:44 -0400, Tom Lane wrote: > >> Andrew Dunstan writes: > >>> On 09/30/2017 10:32 PM, Andres Freund wrote: > Heh. I'm inclined to

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

> On 13 Sep 2017, at 01:24, Daniel Gustafsson wrote: > >> On 18 Apr 2017, at 05:13, Amos Bird wrote: >> >> Ah, thanks for the suggestions. I'll revise this patch soon :) > > Have you had a chance to revise the patch to address the review comments such >

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 10/01/2017 04:48 PM, Andres Freund wrote: > On 2017-10-01 16:42:44 -0400, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 09/30/2017 10:32 PM, Andres Freund wrote: Heh. I'm inclined to take it out. We could add a --use-the-force-luke type

Re: [HACKERS] [PATCH] Off-by-one error in logical slot resource retention

> On 15 Sep 2017, at 13:26, Daniel Gustafsson wrote: > >> On 01 Sep 2017, at 14:28, Aleksander Alekseev >> wrote: >> >> The following review has been posted through the commitfest application: >> make installcheck-world: not tested >> Implements

Re: [HACKERS] 200 = 199 + 1?

I wrote: > I experimented a bit with the attached patch, which modifies > eqjoinsel_semi in two ways. First, if the number-of-distinct-values > estimate for the inner rel is just a default rather than having any > real basis, it replaces it with inner_rel->rows, effectively assuming > that the

Re: [HACKERS] shm_mq_set_sender() crash

On Thu, Sep 15, 2016 at 06:21:30PM -0400, Robert Haas wrote: > On Thu, Sep 15, 2016 at 5:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> Of course, it's also possible that the ParallelWorkerNumber code is > >> entirely correct and something

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 16:42:44 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 09/30/2017 10:32 PM, Andres Freund wrote: > >> Heh. I'm inclined to take it out. We could add a --use-the-force-luke > >> type parameter, but it doesn't seem worth it. > > > I agree,

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

Andrew Dunstan writes: > On 09/30/2017 10:32 PM, Andres Freund wrote: >> Heh. I'm inclined to take it out. We could add a --use-the-force-luke >> type parameter, but it doesn't seem worth it. > I agree, but I think we need this discussed on -hackers. Does anyone

[HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 09/30/2017 10:32 PM, Andres Freund wrote: > Hi, > > On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote: But even after fixing that, there unfortunately is: static void set_sig(char *signame) { … #if 0 /* probably should NOT provide SIGKILL */

Re: [HACKERS] 64-bit queryId?

On 1 October 2017 at 16:40, Tom Lane wrote: > Greg Stark writes: >> Indeed. It's simple enough to export stats to prometheus with queryid >> as the key. Then even if the query ages out of the database stats you >> have graphs and derivative metrics going

Re: [HACKERS] pg_basebackup --progress output for batch execution

Updated patch with documentation of the new option. -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services >From ede201ed96d41d799dc3c83dfab1cdcc03e5ced4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?=

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Sun, Oct 01, 2017 at 09:56:11AM -0400, Peter Eisentraut wrote: > On 9/30/17 03:01, Noah Misch wrote: > > This PostgreSQL 10 open item is past due for your status update. On the > > worst > > week to be violating open item policies. Kindly send a status update within > > 24 hours, and include

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Sun, Oct 1, 2017 at 6:27 AM, Peter Eisentraut wrote: > I'm still pondering committing my documentation patch I had posted, and > I've been reviewing your patches to see if there is anything else > documentation-wise that could be added. -1 from me -- I don't

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-30 1:06 GMT+02:00 Nikita Glukhov : > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule : > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : >> >>> >>> >>> I have some free time

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-10-01 04:09:19,"Alexander Korotkov" wrote: On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote: On 2017-09-30 02:17:54，"Alexander Korotkov" wrote: Great. Now code of this patch looks good for me. However, we forgot

Re: [HACKERS] show precise repos version for dev builds?

Hello, Fabien COELHO writes: I wanted to know which version it was, and "11devel" is kind of imprecise. ... ISTM that extending the version name with the commit id and or date in some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it. configure

Re: [HACKERS] 64-bit queryId?

Greg Stark writes: > Indeed. It's simple enough to export stats to prometheus with queryid > as the key. Then even if the query ages out of the database stats you > have graphs and derivative metrics going further back. I'm not really ready to buy into that as a supported

Re: [HACKERS] show precise repos version for dev builds?

Fabien COELHO writes: > I wanted to know which version it was, and "11devel" is kind of imprecise. > ... > ISTM that extending the version name with the commit id and or date in > some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it. configure

[HACKERS] Warnings in objectaddress.c

Hello, hackers! I'm building PostgreSQL 10 rc1 sources on Debian wheezy (gcc 4.7). I have those warnings: objectaddress.c: In function ‘get_object_address’: objectaddress.c:1646:10: warning: ‘typeoids[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 03:01, Noah Misch wrote: > On Mon, Sep 25, 2017 at 08:26:21AM +, Noah Misch wrote: >> On Tue, Sep 19, 2017 at 07:01:47PM -0700, Peter Geoghegan wrote: >>> On Tue, Sep 19, 2017 at 5:52 PM, Peter Eisentraut >>> wrote: On 9/18/17 18:46, Peter

Re: [HACKERS] Parallel Append implementation

On Sat, Sep 30, 2017 at 9:25 PM, Robert Haas wrote: > On Sat, Sep 30, 2017 at 12:20 AM, Amit Kapila wrote: >> Okay, but the point is whether it will make any difference >> practically. Let us try to see with an example, consider there are >> two

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 15:28, Tom Lane wrote: > This suggests to me that arguing about canonicalization is moot so > far as avoiding reindexing goes: if you change ICU library versions, > you're screwed and will have to jump through all the reindexing hoops, > no matter what we do or don't do. One reason for

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 15:28, Tom Lane wrote: > Now, it may still be worthwhile to argue about whether canonicalization > will help the other component of the problem, which is whether you can > dump and reload CREATE COLLATION commands into a new ICU version and > expect to get more-or-less-the-same behavior

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

Michael Paquier wrote: > On Sun, Oct 1, 2017 at 10:25 AM, Peter Geoghegan wrote: > > On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera > > wrote: > >> Maybe what this means is that we need to do both Dan's initially > >> proposed patch (or something related

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/29/17 19:38, Peter Geoghegan wrote: > On Mon, Sep 25, 2017 at 11:40 AM, Peter Eisentraut > wrote: >> Reading over this code again, it is admittedly not quite clear why this >> "canonicalization" is in there right now. I think it had something to >> do with

Re: [HACKERS] list of credits for release notes

On 9/27/17 14:55, Dave Page wrote: >> Attached is the proposed documentation commit as well as the raw list. > At the very least my name is missing (I contributed the monitoring roles > patch and pg_ls_log/waldir. I have no idea if others are. > > >> Thoughts on the heading? I have considered

Re: [HACKERS] 64-bit queryId?

On 30 September 2017 at 21:03, Alexander Korotkov wrote: > I heard from customers that they periodically dump contents of > pg_stat_statements and then build statistics over long period of time. If > even they leave default pg_stat_statements.max unchanged,

Re: [HACKERS] why subplan is 10x faster then function?

2017-09-30 23:23 GMT+02:00 Pavel Stehule : > Hi > > I have some strange slow queries based on usage "view" functions > > one function looks like this: > > CREATE OR REPLACE FUNCTION ides_funcs.najdatsplt_cislo_exekuce(mid_najdatsplt > bigint) > RETURNS character varying

Re: [HACKERS] why subplan is 10x faster then function?

2017-10-01 12:45 GMT+02:00 Sokolov Yura : > 1 октября 2017 г. 12:42:14 GMT+03:00, Pavel Stehule < > pavel.steh...@gmail.com> пишет: > >2017-09-30 23:23 GMT+02:00 Pavel Stehule : > > > >> Hi > >> > >> I have some strange slow queries based on

Re: [HACKERS] why subplan is 10x faster then function?

1 октября 2017 г. 12:42:14 GMT+03:00, Pavel Stehule пишет: >2017-09-30 23:23 GMT+02:00 Pavel Stehule : > >> Hi >> >> I have some strange slow queries based on usage "view" functions >> >> one function looks like this: >> >> CREATE OR REPLACE

Re: [HACKERS] why subplan is 10x faster then function?

2017-09-30 23:23 GMT+02:00 Pavel Stehule : > Hi > > I have some strange slow queries based on usage "view" functions > > one function looks like this: > > CREATE OR REPLACE FUNCTION ides_funcs.najdatsplt_cislo_exekuce(mid_najdatsplt > bigint) > RETURNS character varying

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

On 1 October 2017 at 01:47, Alexander Korotkov wrote: > On Sat, Sep 30, 2017 at 6:12 PM, Shubham Barai > wrote: > >> I have made changes according to your suggestions. Please have a look at >> the updated patch. >> I am also considering your

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

On Sun, Oct 1, 2017 at 10:25 AM, Peter Geoghegan wrote: > On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera > wrote: >> Maybe what this means is that we need to do both Dan's initially >> proposed patch (or something related to it) apart from the fixes

[HACKERS] show precise repos version for dev builds?

Hello, I use postgres "11devel" packages kindly distributed on "apt.postgresql.org" and recompiled every few hours. I wanted to know which version it was, and "11devel" is kind of imprecise. Ok, there is a hint in the deb package name:

Re: [HACKERS] pgbench - minor fix for meta command only scripts

On 09/29/2017 08:43 PM, Fabien COELHO wrote: reality. So I don't know if this needs backpatching or not. But it should be fixed for v10, as there it becomes a demonstrably live issue. Yes. Patch looks good to me, so committed to master and v10. Thanks! - Heikki -- Sent via pgsql-hackers