RE: Timeout parameters

2019-03-27 Thread Fabien COELHO
Hello Ryohei-san, About the backend v11 patch. Patch applies cleanly, though compiles with a warning. Make check ok, although the feature is not tested. I'm okay with exposing this parameter. Documentation: ISTM this is not about libpq connections but about TCP connections. There can be non

Re: minimizing pg_stat_statements performance overhead

2019-03-27 Thread legrand legrand
Hi, the part that hurts in terms or performances is: if (jstate.clocations_count > 0) pgss_store(pstate->p_sourcetext, query->queryId, query->stmt_location, query->stmt_len,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

2019-03-27 Thread Heikki Linnakangas
On 25/03/2019 20:13, Fabien COELHO wrote: Attached is the remainder of the patch rebased to current head. I stared at the new test case for a while, and I must say it looks very cryptic. It's not exactly this patch's fault - all the pgbench tests are cryptic - but I think we need to do someth

Re: explain plans with information about (modified) gucs

2019-03-27 Thread Rafia Sabih
On Tue, 26 Mar 2019 at 21:04, Tomas Vondra wrote: > On Mon, Mar 18, 2019 at 11:31:48AM +0100, Rafia Sabih wrote: > >On Sun, 24 Feb 2019 at 00:06, Tomas Vondra > wrote: > >> > >> Hi, > >> > >> attached is an updated patch, fixing and slightly tweaking the docs. > >> > >> > >> Barring objections,

Re: Ordered Partitioned Table Scans

2019-03-27 Thread Amit Langote
On 2019/03/27 15:48, Amit Langote wrote: > Hi David, > > Sorry if this was discussed before, but why does this patch add any new > code to partprune.c? AFAICT, there's no functionality changes to the > pruning code. > > Both > > +bool > +partkey_is_bool_constant_for_query(RelOptInfo *partrel, i

Re: Protect syscache from bloating with negative cache entries

2019-03-27 Thread Kyotaro HORIGUCHI
At Mon, 25 Mar 2019 09:28:57 -0400, Robert Haas wrote in > On Thu, Mar 7, 2019 at 11:40 PM Ideriha, Takeshi > wrote: > > Just to be sure, we introduced the LRU list in this thread to find the > > entries less than threshold time > > without scanning the whole hash table. If hash table becomes

Re: txid_status() off-by-one error

2019-03-27 Thread Thomas Munro
On Wed, Mar 27, 2019 at 7:55 PM Thomas Munro wrote: > If you keep asking for txid_status(txid_current() + 1) in new > transactions, you eventually hit: > > ERROR: could not access status of transaction 32768 > DETAIL: Could not read from file "pg_xact/" at offset 8192: No error: 0. > -

Re: Log a sample of transactions

2019-03-27 Thread Adrien NAYRAT
Hello, On 3/27/19 7:05 AM, Masahiko Sawada wrote: Why are both of these checked? ISTM once xact_is_sampled is set, we ought not to respect a different value of log_xact_sample_rate for the rest of that transaction. I added theses checks to allow to disable logging during a sampled transaction,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

2019-03-27 Thread Fabien COELHO
Hello Heikki, I stared at the new test case for a while, and I must say it looks very cryptic. It's not exactly this patch's fault - all the pgbench tests are cryptic - Perl is cryptic. Regexprs are cryptic. but I think we need to do something about that before adding any more tests. I'm

Re: amcheck verification for GiST

2019-03-27 Thread Andrey Borodin
Hi! Here's new version of GiST amcheck, which takes into account recently committed GiST VACUUM. It tests that deleted pages do not contain any data. Also, Heikki's fix applied (wrong OffsetNumberNext(i) replaced by OffsetNumberNext(o)). Thanks! Best regards, Andrey Borodin. 0001-GiST-verif

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread Julien Rouhaud
On Wed, Mar 27, 2019 at 12:21 AM legrand legrand wrote: > > here is a new version: > > - "track_planning" GUC added > to permit to keep previous behavior unchanged good > - trailing whitespaces and comments wider than 80 characters > not fixed why? In case it's not cle

Re: [Patch] Base backups and random or zero pageheaders

2019-03-27 Thread Michael Banck
Hi, Am Dienstag, den 26.03.2019, 19:23 +0100 schrieb Michael Banck: > Am Dienstag, den 26.03.2019, 10:30 -0700 schrieb Andres Freund: > > On 2019-03-26 18:22:55 +0100, Michael Banck wrote: > > > /* > > > - * Only check pages which have not been >

Re: jsonpath

2019-03-27 Thread Alexander Korotkov
On Tue, Mar 26, 2019 at 6:06 PM Alexander Korotkov wrote: > On Tue, Mar 26, 2019 at 5:32 PM Tom Lane wrote: > > Alexander Korotkov writes: > > > Got access to that buildfarm animal thanks to Tom Turelinckx. Now > > > running check-world in a loop on the same commit hash with same build > > > op

Re: Usage of epoch in txid_current

2019-03-27 Thread Thomas Munro
On Tue, Mar 26, 2019 at 12:58 PM Thomas Munro wrote: > On Tue, Mar 26, 2019 at 3:23 AM Heikki Linnakangas wrote: > > Looks good. I did some testing and proof-reading and made a few minor changes: * I tidied up the code that serialises transaction state. It was already hammering round pegs into

Re: Fix XML handling with DOCTYPE

2019-03-27 Thread Ryan Lambert
Thanks for putting up with a new reviewer! --with-libxml is the PostgreSQL configure option to make it use libxml2. > > The very web page http://xmlsoft.org/index.html says "The XML C parser > and toolkit of Gnome: libxml" and is all about libxml2. > > So I think I was unsure what conven

Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

2019-03-27 Thread Amit Kapila
On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi wrote: > On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila wrote: >> >> As part of this thread, maybe we can >> just fix the case of the parallel cooperating transaction. > > > With the current patch, all the parallel implementation transaction are > ge

Re: pg_upgrade version checking questions

2019-03-27 Thread Christoph Berg
Re: Daniel Gustafsson 2019-03-26 > 0003 - Make -B default to CWD and remove the exec_path check > > Defaulting to CWD for the new bindir has the side effect that the default > sockdir is in the bin/ directory which may be less optimal. Hmm, I would have thought that the default for the new bind

Re: monitoring CREATE INDEX [CONCURRENTLY]

2019-03-27 Thread Rahila Syed
On Mon, 25 Mar 2019 at 22:23, Alvaro Herrera wrote: > Here's v6 of this patch. I have rebased on top of today's CLUSTER > monitoring, as well as on table AM commits. The latter caused a bit of > trouble, as now the number of blocks processed by a scan is not as easy > to get as before; I added

Re: BUG #15708: RLS 'using' running as wrong user when called from a view

2019-03-27 Thread Dean Rasheed
On Mon, 25 Mar 2019 at 20:27, Stephen Frost wrote: > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > > > It looks like the best place to fix it is in > > get_policies_for_relation(), since that's where all the policies to be > > applied for a given RTE are pulled together. Patch attached. > >

Re: Usage of epoch in txid_current

2019-03-27 Thread Heikki Linnakangas
On 27/03/2019 13:44, Thomas Munro wrote: * I tidied up the code that serialises transaction state. It was already hammering round pegs into square holes, and the previous patch made that even worse, so I added a new struct SerializedTransactionState to do this properly. Ah, good, it used to be

Re: Log a sample of transactions

2019-03-27 Thread Adrien NAYRAT
On 3/27/19 10:22 AM, Adrien NAYRAT wrote: Hello, On 3/27/19 7:05 AM, Masahiko Sawada wrote: Why are both of these checked? ISTM once xact_is_sampled is set, we ought not to respect a different value of log_xact_sample_rate for the rest of that transaction. I added theses checks to allow to dis

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Fred .Flintstone
Many of these are gone in the modern PostgreSQL, a few remain. https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist /usr/lib/postgresql/11/bin/clusterdb /usr/lib/postgresql/11/bin/createdb /usr/lib/postgresql/11/bin/createuser /usr/lib/postgresql/11/bin/dropdb /usr/lib/postgresql/

Re: Fix XML handling with DOCTYPE

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Chapman Flack wrote: > On 03/26/19 21:39, Ryan Lambert wrote: > > Should this be clarified as the libxml2 library? That's what I installed > > to build postgres from source (Ubuntu 16/18). If it is the libxml library > > and the "2" is irrelevant > > That's a good catch. I'm no

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

2019-03-27 Thread Fabien COELHO
Hello Heikki, Indeed, yet again, I forgot the attachement:-( I stared at the new test case for a while, and I must say it looks very cryptic. It's not exactly this patch's fault - all the pgbench tests are cryptic - Perl is cryptic. Regexprs are cryptic. but I think we need to do something

Re: jsonpath

2019-03-27 Thread Tom Lane
Alexander Korotkov writes: > Still no reproduction. Annoying, but it's probably not worth expending more effort on right now. I wonder whether that buildfarm animal can be upgraded to capture core dump stack traces --- if so, then if it happens again we'd have more info.

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tomas Vondra
On Wed, Mar 27, 2019 at 02:31:14PM +0100, Fred .Flintstone wrote: Many of these are gone in the modern PostgreSQL, a few remain. https://packages.ubuntu.com/disco/amd64/postgresql-client-11/filelist /usr/lib/postgresql/11/bin/clusterdb /usr/lib/postgresql/11/bin/createdb /usr/lib/postgresql/11/b

Re: Progress reporting for pg_verify_checksums

2019-03-27 Thread Michael Banck
Hi, Am Samstag, den 23.03.2019, 10:49 +0900 schrieb Michael Paquier: > On Fri, Mar 22, 2019 at 02:23:17PM +0100, Michael Banck wrote: > > The current version prints a newline when it progress reporting is > > toggled off. Do you mean there is a hazard that this happens right when > > we are printi

Re: Enable data checksums by default

2019-03-27 Thread Christoph Berg
Re: To Tom Lane 2019-03-26 <20190326151446.gg3...@msg.df7cb.de> > I run a benchmark with checksums disabled/enabled. shared_buffers is > 512kB to make sure almost any read will fetch the page from the OS > cache; scale factor is 50 (~750MB) to make sure the whole cluster fits > into RAM. [...] > So

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Tomas Vondra wrote: > I think the consensus in this thread (and the previous ancient ones) is > that it's not worth it. It's one thing to introduce new commands with the > pg_ prefix, and it's a completely different thing to rename existing ones. > That has inherent costs, and as T

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Fred .Flintstone
It does not matter if they are in a different directory, because when I use tab-completion in the shell, then all commands show. I type "create" then "createdb" and "createuser" shows up. This is very confusing, and I don't know if this creates a Linux system user account or a PostgreSQL account. W

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Komяpa
Hello, at the very least my Ubuntu Cosmic has createdb, createuser and createlang in user's space, and I had at least two cases when people were trying to use createuser to create a new OS user. I would prefer them having pg_ prefix to have less confusion. On Wed, Mar 27, 2019 at 4:51 PM Tomas V

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Andreas Karlsson
On 3/27/19 2:51 PM, Tomas Vondra wrote: I think the consensus in this thread (and the previous ancient ones) is that it's not worth it. It's one thing to introduce new commands with the pg_ prefix, and it's a completely different thing to rename existing ones. That has inherent costs, and as Tom

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tomas Vondra
On Wed, Mar 27, 2019 at 11:00:18AM -0300, Alvaro Herrera wrote: On 2019-Mar-27, Tomas Vondra wrote: I think the consensus in this thread (and the previous ancient ones) is that it's not worth it. It's one thing to introduce new commands with the pg_ prefix, and it's a completely different thing

Re: partitioned tables referenced by FKs

2019-03-27 Thread Jesper Pedersen
Hi, On 3/26/19 5:39 PM, Alvaro Herrera wrote: As I said before, I'm thinking of getting rid of the whole business of checking partitions on the referenced side of an FK at DROP time, and instead jut forbid the DROP completely if any FKs reference an ancestor of that partition. Will that allow

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tom Lane
Alvaro Herrera writes: > On 2019-Mar-27, Tomas Vondra wrote: >> I think the consensus in this thread (and the previous ancient ones) is >> that it's not worth it. It's one thing to introduce new commands with the >> pg_ prefix, and it's a completely different thing to rename existing ones. >> That

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tomas Vondra
On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote: On 3/27/19 2:51 PM, Tomas Vondra wrote: I think the consensus in this thread (and the previous ancient ones) is that it's not worth it. It's one thing to introduce new commands with the pg_ prefix, and it's a completely different

Re: Progress reporting for pg_verify_checksums

2019-03-27 Thread Fabien COELHO
Hallo Michael, About patch v12: Patch applies cleanly, compiles. make check ok, but feature is not tested. Doc build ok. Although I'm in favor of it, I'm not sure that the signal think will make it for 12. Maybe it is worth compromising, doing a simple version for now, and resubmitting th

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Andreas Karlsson
On 3/27/19 3:26 PM, Tomas Vondra wrote: That is true, of course. But are there actual examples of such conflicts in practice? I mean, are there tools/packages that provide commands with a conflicting name? I'm not aware of any, and as was pointed before, we'd have ~20 years of history on any new

Re: jsonpath

2019-03-27 Thread Alexander Korotkov
On Wed, Mar 27, 2019 at 4:49 PM Tom Lane wrote: > Alexander Korotkov writes: > > Still no reproduction. > > Annoying, but it's probably not worth expending more effort on > right now. I wonder whether that buildfarm animal can be upgraded > to capture core dump stack traces --- if so, then if it

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tom Lane
Andreas Karlsson writes: > On 3/27/19 3:26 PM, Tomas Vondra wrote: >> That is true, of course. But are there actual examples of such conflicts >> in practice? I mean, are there tools/packages that provide commands with >> a conflicting name? I'm not aware of any, and as was pointed before, we'd >>

Re: jsonpath

2019-03-27 Thread Tomas Vondra
On Wed, Mar 27, 2019 at 05:37:40PM +0300, Alexander Korotkov wrote: On Wed, Mar 27, 2019 at 4:49 PM Tom Lane wrote: Alexander Korotkov writes: > Still no reproduction. Annoying, but it's probably not worth expending more effort on right now. I wonder whether that buildfarm animal can be upgr

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Mar-27, Tomas Vondra wrote: > >> I think the consensus in this thread (and the previous ancient ones) is > >> that it's not worth it. It's one thing to introduce new commands with the > >> pg_ prefix, and it's a completely diffe

Re: speeding up planning with partitions

2019-03-27 Thread Tom Lane
David Rowley writes: > On Wed, 27 Mar 2019 at 18:39, Amit Langote > wrote: >> On 2019/03/27 14:26, David Rowley wrote: >>> Perhaps the way to make this work, at least in the long term is to do >>> in the planner what we did in the executor in d73f4c74dd34. >> Maybe you meant 9ddef36278a9? > Pro

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Reid Thompson
On Wed, 2019-03-27 at 15:07 +0100, Andreas Karlsson wrote: > [EXTERNAL SOURCE] > > > > On 3/27/19 2:51 PM, Tomas Vondra wrote: > > I think the consensus in this thread (and the previous ancient ones) is > > that it's not worth it. It's one thing to introduce new commands with the > > pg_ prefix,

Re: pgbench - doCustom cleanup

2019-03-27 Thread Alvaro Herrera
Pushed, thanks. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Progress reporting for pg_verify_checksums

2019-03-27 Thread Michael Banck
Hi, thanks again for your review! Am Mittwoch, den 27.03.2019, 15:34 +0100 schrieb Fabien COELHO: > Hallo Michael, > > About patch v12: > > Patch applies cleanly, compiles. make check ok, but feature is not tested. > Doc build ok. > > Although I'm in favor of it, I'm not sure that the signal

Re: SET LOCAL ROLE NO RESET -- sandbox transactions

2019-03-27 Thread Chapman Flack
On 3/27/19 2:40 AM, Eric Hanson wrote: > What would be the implications of adding a NO RESET clause to SET LOCAL > ROLE? There's a part of this that seems to be a special case of the GUC-protected-by-cookie idea discussed a bit in [1] and [2] (which is still an idea that I like). Regards, -Chap

Re: Fix XML handling with DOCTYPE

2019-03-27 Thread Chapman Flack
On 3/27/19 9:31 AM, Alvaro Herrera wrote: > Everyone calls it "libxml2" nowadays. Let's just use that and avoid any > possible confusion. If some libxml3 emerges one day, it's quite likely > we'll need to revise much more than our docs in order to use it. That's persuasive to me. I'll change the

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Tom Lane
Alvaro Herrera writes: > I suppose that if you're a Postgres developer, you naturally expect that > "createdb" creates a Postgres DB. What if you use multiple database > systems, and then only occasionally have to do DBA tasks? I find this > POV that createdb doesn't need renaming a bit self-cen

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Petr Jelinek
On 27/03/2019 15:26, Tomas Vondra wrote: > On Wed, Mar 27, 2019 at 03:07:24PM +0100, Andreas Karlsson wrote: >> On 3/27/19 2:51 PM, Tomas Vondra wrote: >>> I think the consensus in this thread (and the previous ancient ones) is >>> that it's not worth it. It's one thing to introduce new commands wi

Re: amcheck verification for GiST

2019-03-27 Thread Heikki Linnakangas
On 27/03/2019 11:51, Andrey Borodin wrote: Hi! Here's new version of GiST amcheck, which takes into account recently committed GiST VACUUM. It tests that deleted pages do not contain any data. Thanks! I had a look, and refactored it quite a bit. I found the way the recursion worked confusing

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Fred .Flintstone
Symlinks would be great, because then the symlinks could be packaged as an optional package. such as; - postgresql-11 - postgresql-client-11 - postgresql-client-symlinks-11 - postgresql-client-common - postgresql-common Then one might chose to not install the symlinks package or uninstall it. And

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

2019-03-27 Thread Alexey Kondratov
On 26.03.2019 11:19, Michael Paquier wrote: + * This is a simplified and adapted to frontend version of + * RestoreArchivedFile function from transam/xlogarchive.c + */ +static int +RestoreArchivedWAL(const char *path, const char *xlogfname, I don't think that we should have duplicates for that,

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Tom Lane wrote: > Alvaro Herrera writes: > > I suppose that if you're a Postgres developer, you naturally expect that > > "createdb" creates a Postgres DB. What if you use multiple database > > systems, and then only occasionally have to do DBA tasks? I find this > > POV that cr

RE: minimizing pg_stat_statements performance overhead

2019-03-27 Thread Raymond Martin
Hi Pascal, Thanks for your feedback! I like your ideas. >the part that hurts in terms or performances is: > > if (jstate.clocations_count > 0) > pgss_store(pstate->p_sourcetext, I agree that this is the typically the most expensive part, but query normalization and hashing c

Re: Re: A separate table level option to control compression

2019-03-27 Thread Shaun Thomas
> Setting compress_tuple_target to a higher value won't be negative because the > toast_tuple_target is used for compression anyways when compress_tuple_target > is higher than toast_tuple_target. Ack, you're right. Got my wires crossed. I must have gotten confused by my later tests that enforced

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

2019-03-27 Thread Tomas Vondra
Hi, I've now committed the MCV part, after addressing the last two issues raised by Dean: * The MCV build now always uses the mincount to decide which of the items to keep in the list. * Both the MCV build and deserialization now uses the same maximum number of list items (10k). Unfortunately,

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

2019-03-27 Thread Petr Jelinek
On 27/03/2019 20:55, Tomas Vondra wrote: > Hi, > > I've now committed the MCV part, after addressing the last two issues > raised by Dean: > Congrats! -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

RE: minimizing pg_stat_statements performance overhead

2019-03-27 Thread legrand legrand
Your fix is probably the best one. Maybe this could be considered as a bug and back ported to previous versions ... Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Re: Progress reporting for pg_verify_checksums

2019-03-27 Thread Fabien COELHO
I still think that the speed should compute a double to avoid integer rounding errors within the computation. ISTM that rounding should only be done for display in the end. Ok, also done this way. I decided to print only full MB and not any further digits as those don't seem very relevant.

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread legrand legrand
>> - trailing whitespaces and comments wider than 80 characters >> not fixed > why? In case it's not clear, I'm talking about the .c file, not the > regression tests. I work on a poor msys install on windows 7, where perl is broken ;o( So no pgindent available. Will fix that later,

Re: Enable data checksums by default

2019-03-27 Thread Ants Aasma
On Wed, Mar 27, 2019, 15:57 Christoph Berg wrote: > Re: To Tom Lane 2019-03-26 <20190326151446.gg3...@msg.df7cb.de> > > I run a benchmark with checksums disabled/enabled. shared_buffers is > > 512kB to make sure almost any read will fetch the page from the OS > > cache; scale factor is 50 (~750MB

Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread Komяpa
Hi hackers, Attached is sketch of small patch that fixes several edge cases with autovacuum. Long story short autovacuum never comes to append only tables, killing large productions. First case, mine. https://www.postgresql.org/message-id/CAC8Q8tLBeAxR%2BBXWuKK%2BHP5m8tEVYn270CVrDvKXt%3D0PkJTY9g

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Gavin Flower
On 28/03/2019 03:07, Andreas Karlsson wrote: On 3/27/19 2:51 PM, Tomas Vondra wrote: I think the consensus in this thread (and the previous ancient ones) is that it's not worth it. It's one thing to introduce new commands with the pg_ prefix, and it's a completely different thing to rename exis

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Gavin Flower
On 28/03/2019 03:41, Tom Lane wrote: Andreas Karlsson writes: On 3/27/19 3:26 PM, Tomas Vondra wrote: That is true, of course. But are there actual examples of such conflicts in practice? I mean, are there tools/packages that provide commands with a conflicting name? I'm not aware of any, and

Re: PostgreSQL pollutes the file system

2019-03-27 Thread Peter Eisentraut
On 2019-03-27 18:09, Tom Lane wrote: > My recollection of the discussion is that people argued that "postmaster" > might be taken to have something to do with an e-mail server, and > therefore we needed to stop using that name. The lack of either follow-on > complaints or follow-on action doesn't

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread Julien Rouhaud
On Wed, Mar 27, 2019 at 9:36 PM legrand legrand wrote: > > >> - trailing whitespaces and comments wider than 80 characters > >> not fixed > > > why? In case it's not clear, I'm talking about the .c file, not the > > regression tests. > > I work on a poor msys install on windows 7, wh

Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

2019-03-27 Thread Robert Haas
On Tue, Mar 26, 2019 at 10:35 PM Tsunakawa, Takayuki wrote: > I almost have the same view as Sawada-san. The reloption > vacuum_shrink_enabled is a positive name and follows the naming style of > other reloptions. I hope this matches the style you have in mind. You're both right and I'm wrong

Re: Should the docs have a warning about pg_stat_reset()?

2019-03-27 Thread Peter Eisentraut
On 2019-03-26 16:28, Euler Taveira wrote: > I don't remember why we didn't consider table without stats to be > ANALYZEd. Isn't it the case to fix autovacuum? Analyze > autovacuum_count + vacuum_count = 0? When the autovacuum system was introduced, we didn't have those columns. But now it seems t

Re: Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Darafei "Komяpa" Praliaskouski wrote: > Attached is sketch of small patch that fixes several edge cases with > autovacuum. Long story short autovacuum never comes to append only tables, > killing large productions. Yeah, autovac is not coping with these scenarios (and probably oth

Re: Should the docs have a warning about pg_stat_reset()?

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-27, Peter Eisentraut wrote: > On 2019-03-26 16:28, Euler Taveira wrote: > > I don't remember why we didn't consider table without stats to be > > ANALYZEd. Isn't it the case to fix autovacuum? Analyze > > autovacuum_count + vacuum_count = 0? > > When the autovacuum system was introduc

Re: Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread Komяpa
Hi, чт, 28 мар. 2019 г. в 00:32, Alvaro Herrera : > On 2019-Mar-27, Darafei "Komяpa" Praliaskouski wrote: > > > Attached is sketch of small patch that fixes several edge cases with > > autovacuum. Long story short autovacuum never comes to append only > tables, > > killing large productions. > >

Re: Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread Alvaro Herrera
On 2019-Mar-28, Darafei "Komяpa" Praliaskouski wrote: > чт, 28 мар. 2019 г. в 00:32, Alvaro Herrera : > > > On 2019-Mar-27, Darafei "Komяpa" Praliaskouski wrote: > > * certain tables would have some sort of partial scan that sets the > > visibility map. There's no reason to invoke the whole

RE: minimizing pg_stat_statements performance overhead

2019-03-27 Thread Raymond Martin
Hi Fabien, Thank you for your time. Apologies for not being more specific about my testing methodology. > > PGSS not loaded: 0.18ms > > This means 0.0018 ms latency per transaction, which seems rather fast, on my > laptop I have typically 0.0XX ms... This actually means 0.18 milliseconds. I ag

RE: minimizing pg_stat_statements performance overhead

2019-03-27 Thread legrand legrand
my test case: drop table a; create table a (); DO $$ DECLARE i int; BEGIN for i in 1..20 loop execute 'alter table a add column a'||i::text||' int'; end loop; END $$; select pg_stat_statements_reset(); set pg_stat_statements.track='none'; DO $$ DECLARE i int; j int; BEGIN for j in 1..20 loop f

Re: Ordered Partitioned Table Scans

2019-03-27 Thread David Rowley
On Wed, 27 Mar 2019 at 19:48, Amit Langote wrote: > Sorry if this was discussed before, but why does this patch add any new > code to partprune.c? AFAICT, there's no functionality changes to the > pruning code. You're right. It probably shouldn't be there. There's a bit of a lack of a good home

Re: Planning counters in pg_stat_statements (using pgss_store)

2019-03-27 Thread legrand legrand
Julien Rouhaud wrote > On Wed, Mar 27, 2019 at 9:36 PM legrand legrand > < > legrand_legrand@ > > wrote: >> >> >> - trailing whitespaces and comments wider than 80 characters >> >> not fixed >> >> > why? In case it's not clear, I'm talking about the .c file, not the >> > regression

Re: Ordered Partitioned Table Scans

2019-03-27 Thread David Rowley
On Wed, 27 Mar 2019 at 21:24, Amit Langote wrote: > Noticed a typo. > > + * multiple subpaths then we can't make guarantees about the > + * order tuples in those subpaths, so we must leave the > > order of tuples? I'll fix that. Thanks. > Again, sorry if this was

Re: Fix XML handling with DOCTYPE

2019-03-27 Thread Chapman Flack
Hi, xml-functions-type-docfix-5.patch attached, with node-sets instead of nodesets, libxml2 instead of libxml, and parenthesized full sentences now au naturel. I ended up turning the formerly-parenthesized note about libxml2's node-set ordering into a DocBook : there is really something parenthet

Re: Fix XML handling with DOCTYPE

2019-03-27 Thread Chapman Flack
On 03/27/19 19:07, Chapman Flack wrote: > xml-functions-type-docfix-5.patch attached, with node-sets instead of > nodesets, libxml2 instead of libxml, and parenthesized full sentences > now au naturel. > > I ended up turning the formerly-parenthesized note about libxml2's > node-set ordering into

Re: Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread David Rowley
On Thu, 28 Mar 2019 at 11:01, Alvaro Herrera wrote: > > On 2019-Mar-28, Darafei "Komяpa" Praliaskouski wrote: > > "Nearing wraparound" is too late already. In Amazon, reading table from gp2 > > after you exhausted your IOPS burst budget is like reading a floppy drive, > > you have to freeze a lot

Re: Should the docs have a warning about pg_stat_reset()?

2019-03-27 Thread David Rowley
On Thu, 28 Mar 2019 at 10:33, Alvaro Herrera wrote: > > On 2019-Mar-27, Peter Eisentraut wrote: > > > On 2019-03-26 16:28, Euler Taveira wrote: > > > I don't remember why we didn't consider table without stats to be > > > ANALYZEd. Isn't it the case to fix autovacuum? Analyze > > > autovacuum_coun

Re: amcheck verification for GiST

2019-03-27 Thread Peter Geoghegan
On Wed, Mar 27, 2019 at 10:29 AM Heikki Linnakangas wrote: > Thanks! I had a look, and refactored it quite a bit. I'm really happy that other people seem to be driving amcheck in a new direction, without any prompting from me. It's too important to remain something that only I have contributed to

RE: Timeout parameters

2019-03-27 Thread Nagaura, Ryohei
Hello, Fabien-san. > From: Fabien COELHO > About the backend v11 patch. > No space or newline before ";". Same comment about the libpq_ timeout. Fixed. > There is an error in the code, I think it should be < 0 to detect errors. Yes, thanks! > If the parameter has no effect on Windows, I do not

Re: Ordered Partitioned Table Scans

2019-03-27 Thread Amit Langote
Hi, On 2019/03/28 7:29, David Rowley wrote: > On Wed, 27 Mar 2019 at 19:48, Amit Langote > wrote: >> Sorry if this was discussed before, but why does this patch add any new >> code to partprune.c? AFAICT, there's no functionality changes to the >> pruning code. > > You're right. It probably sho

Re: pg_upgrade: Pass -j down to vacuumdb

2019-03-27 Thread Jeff Janes
On Tue, Mar 26, 2019 at 7:28 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-25 22:57, Tom Lane wrote: > > + fprintf(script, "echo %sYou may wish to add --jobs=N for parallel > analyzing.%s\n", > > + ECHO_QUOTE, ECHO_QUOTE); > > But then you get

Re: Log a sample of transactions

2019-03-27 Thread Masahiko Sawada
Thank you for updating the patch! On Wed, Mar 27, 2019 at 10:28 PM Adrien NAYRAT wrote: > > On 3/27/19 10:22 AM, Adrien NAYRAT wrote: > > Hello, > > > > On 3/27/19 7:05 AM, Masahiko Sawada wrote: > > Why are both of these checked? ISTM once xact_is_sampled is set, we > > ought not to resp

Re: Ordered Partitioned Table Scans

2019-03-27 Thread David Rowley
On Thu, 28 Mar 2019 at 14:34, Amit Langote wrote: > > On 2019/03/28 7:29, David Rowley wrote: > > On Wed, 27 Mar 2019 at 19:48, Amit Langote > > It does need to know how many partitions the partitioned table has, > > which it gets from partrel->nparts, so yeah, RelOptInfo is probably > > needed. I

RE: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

2019-03-27 Thread Tsunakawa, Takayuki
From: Robert Haas [mailto:robertmh...@gmail.com] > You're both right and I'm wrong. > > However, I think it would be better to stick with the term 'truncate' > which is widely-used already, rather than introducing a new term. Yeah, I have the same feeling. OTOH, as I referred in this thread, shr

Re: jsonpath

2019-03-27 Thread Andrew Dunstan
On 3/27/19 9:48 AM, Tom Lane wrote: > Alexander Korotkov writes: >> Still no reproduction. > Annoying, but it's probably not worth expending more effort on > right now. I wonder whether that buildfarm animal can be upgraded > to capture core dump stack traces --- if so, then if it happens > agai

RE: Timeout parameters

2019-03-27 Thread Nagaura, Ryohei
Hello, Fabien-san. > From: Fabien COELHO [mailto:coe...@cri.ensmp.fr] > The default postgres configuration file should be updated to reflect the > parameter and its default value. I'm very sorry for not addressing your review in the last patch. I modified TCP_backend patch (adding postgresql.conf.

Re: partitioned tables referenced by FKs

2019-03-27 Thread Amit Langote
Hi, On 2019/03/27 8:27, Alvaro Herrera wrote: > On 2019-Mar-26, Alvaro Herrera wrote: > >> Thanks for the thorough testing and bug analysis! It was spot-on. I've >> applied your two proposed fixes, as well as added a new test setup that >> covers both these bugs. The attached set is rebased on

Re: Timeout parameters

2019-03-27 Thread Kyotaro HORIGUCHI
Hello. At Thu, 28 Mar 2019 01:11:23 +, "Nagaura, Ryohei" wrote in > Hello, Fabien-san. > > > From: Fabien COELHO > > About the backend v11 patch. > > No space or newline before ";". Same comment about the libpq_ timeout. > Fixed. > > > There is an error in the code, I think it should be

Re: Ordered Partitioned Table Scans

2019-03-27 Thread David Rowley
On Thu, 28 Mar 2019 at 15:40, David Rowley wrote: > Thanks for the review. I've attached a patch that mostly just moved > the code around. Here's one that fixes up the compiler warning from the last one. Thanks CF bot... -- David Rowley http://www.2ndQuadrant.com/ PostgreSQ

Re: speeding up planning with partitions

2019-03-27 Thread Amit Langote
On 2019/03/27 23:57, Tom Lane wrote: > David Rowley writes: >> On Wed, 27 Mar 2019 at 18:39, Amit Langote >> wrote: >>> On 2019/03/27 14:26, David Rowley wrote: Perhaps the way to make this work, at least in the long term is to do in the planner what we did in the executor in d73f4c74dd

Re: jsonpath

2019-03-27 Thread Tom Lane
Andrew Dunstan writes: > I was able to get this stack trace. > > (gdb) bt > #0 0x7ffb9ce6a458 in ntdll!RtlRaiseStatus () >from C:\WINDOWS\SYSTEM32\ntdll.dll > #1 0x7ffb9ce7760e in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll > #2 0x7ffb9ac52e1a in msvcrt!_setjmpex () >

Re: speeding up planning with partitions

2019-03-27 Thread Tom Lane
Amit Langote writes: > On 2019/03/27 23:57, Tom Lane wrote: >> Yeah, there's something to be said for having plancat.c open each table >> *and store the Relation pointer in the RelOptInfo*, and then close that >> again at the end of planning rather than immediately. If we can't avoid >> these ret

Re: Usage of epoch in txid_current

2019-03-27 Thread Thomas Munro
On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas wrote: > Once we have the FullTransactionId type and basic macros in place, I'm > sure we could tidy up a bunch of code by using them. For example, > TransactionIdInRecentPast() in walsender.c would be simpler, if the > caller dealt with FullTrans

Re: Berserk Autovacuum (let's save next Mandrill)

2019-03-27 Thread Komяpa
чт, 28 мар. 2019 г. в 01:01, Alvaro Herrera : > On 2019-Mar-28, Darafei "Komяpa" Praliaskouski wrote: > > > > чт, 28 мар. 2019 г. в 00:32, Alvaro Herrera : > > > > > On 2019-Mar-27, Darafei "Komяpa" Praliaskouski wrote: > > > > * certain tables would have some sort of partial scan that sets the >

RE: Timeout parameters

2019-03-27 Thread Tsunakawa, Takayuki
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp] > +if (setsockopt(conn->sock, IPPROTO_TCP, TCP_USER_TIMEOUT, > + (char *) &timeout, sizeof(timeout)) < 0 && errno != > ENOPROTOOPT) > +{ > +charsebuf[256]; > + > +appendPQExpBuffer(&conn->er

  1   2   3   >