Re: Is it too soon for a PG12 open items wiki page?

On Sat, Mar 9, 2019 at 1:03 AM Michael Paquier wrote: > > On Fri, Mar 08, 2019 at 10:06:43PM +0900, Amit Langote wrote: > > On Fri, Mar 8, 2019 at 7:52 PM Julien Rouhaud wrote: > >> It seems like a good timing to me. > > It would be a good timing as some issues are already showing up. And > abra

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 12:35 AM Magnus Hagander wrote: > > On Mon, Mar 4, 2019 at 11:31 AM Julien Rouhaud wrote: >> >> On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander wrote: >> > >> > It tracks things that happen in the general backends. Possibly we should >> > also consider counting the errors

Re: Should we increase the default vacuum_cost_limit?

On Sat, 9 Mar 2019 at 16:11, Tom Lane wrote: > I propose therefore that instead of increasing vacuum_cost_limit, > what we ought to be doing is reducing vacuum_cost_delay by a similar > factor. And, to provide some daylight for people to reduce it even > more, we ought to arrange for it to be spe

RE: Timeout parameters

Hello Ryohei-san, About socket_timeout: From: Fabien COELHO are actually finished. I cannot say that I'm thrilled by that behavior. ISTM that libpq should at least attempt to cancel the query Would you please tell me why you think so? As I understand the "client-side timeout" use-case, a

Re: Should we increase the default vacuum_cost_limit?

On 3/9/19 4:28 AM, David Rowley wrote: > On Sat, 9 Mar 2019 at 16:11, Tom Lane wrote: >> I propose therefore that instead of increasing vacuum_cost_limit, >> what we ought to be doing is reducing vacuum_cost_delay by a similar >> factor. And, to provide some daylight for people to reduce it eve

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On Mon, 4 Mar 2019 at 16:26, Tom Lane wrote: > I was a bit surprised to find that I didn't need to fool around > with lying about whether [Merge]Append can project. I've not dug > into the exact reason why, but I suspect it's that previous changes > made in support of parallelization have resulte

Re: Should we increase the default vacuum_cost_limit?

David Rowley writes: > I agree that vacuum_cost_delay might not be granular enough, however. > If we're going to change the vacuum_cost_delay into microseconds, then > I'm a little concerned that it'll silently break existing code that > sets it. Scripts that do manual off-peak vacuums are pretty

Re: Should we increase the default vacuum_cost_limit?

Andrew Dunstan writes: > On 3/9/19 4:28 AM, David Rowley wrote: >> I agree that vacuum_cost_delay might not be granular enough, however. >> If we're going to change the vacuum_cost_delay into microseconds, then >> I'm a little concerned that it'll silently break existing code that >> sets it. Scr

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

On Thu, 28 Feb 2019 at 19:56, Tomas Vondra wrote: > Attached is an updated version of this patch series. Here are some random review comments. I'll add more later, but I'm out of energy for today. 1). src/test/regress/expected/type_sanity.out has bit-rotted. 2). Duplicate OIDs (3425). 3). It l

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 9:34 AM Julien Rouhaud wrote: > > On Sat, Mar 9, 2019 at 12:35 AM Magnus Hagander wrote: > > > > On Mon, Mar 4, 2019 at 11:31 AM Julien Rouhaud wrote: > >> > >> On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander > >> wrote: > >> > > >> > It tracks things that happen in the

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 12:33 AM Julien Rouhaud wrote: > On Sat, Mar 9, 2019 at 12:35 AM Magnus Hagander > wrote: > > > > On Mon, Mar 4, 2019 at 11:31 AM Julien Rouhaud > wrote: > >> > >> On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander > wrote: > >> > > >> > It tracks things that happen in the

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 10:41 AM Julien Rouhaud wrote: > On Sat, Mar 9, 2019 at 9:34 AM Julien Rouhaud wrote: > > > > On Sat, Mar 9, 2019 at 12:35 AM Magnus Hagander > wrote: > > > > > > On Mon, Mar 4, 2019 at 11:31 AM Julien Rouhaud > wrote: > > >> > > >> On Fri, Feb 22, 2019 at 3:01 PM Magnus

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 7:48 PM Magnus Hagander wrote: > > On Sat, Mar 9, 2019 at 12:33 AM Julien Rouhaud wrote: >> >> Thanks! Our implementations are quite similar, so I'm fine with most >> of the changes :) I'm just not sure about having two distinct >> functions for reporting failures, given t

Re: Checksum errors in pg_stat_database

On Sat, Mar 9, 2019 at 7:50 PM Magnus Hagander wrote: > > On Sat, Mar 9, 2019 at 10:41 AM Julien Rouhaud wrote: >> >> Sorry, I have again new comments after a little bit more thinking. >> I'm wondering if we can do something about shared objects while we're >> at it. They don't belong to any dat

Re: Should we increase the default vacuum_cost_limit?

On 3/9/19 12:55 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 3/9/19 4:28 AM, David Rowley wrote: >>> I agree that vacuum_cost_delay might not be granular enough, however. >>> If we're going to change the vacuum_cost_delay into microseconds, then >>> I'm a little concerned that it'll silent

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Sun, Feb 17, 2019 at 7:50 PM Michael Paquier wrote: > On Fri, Feb 15, 2019 at 08:03:24PM -0800, Andres Freund wrote: > > I see you've marked the patch as needs review - but as the patch > > previously was marked as ready-for-committer, and I assume nothing > > substantial has changed, I think

Re: Should we increase the default vacuum_cost_limit?

On Sat, Mar 9, 2019 at 7:58 PM Andrew Dunstan wrote: > > On 3/9/19 12:55 PM, Tom Lane wrote: > >> Maybe we could leave the default units as msec but store it and allow > >> specifying as usec. Not sure how well the GUC mechanism would cope with > >> that. > > I took a quick look at that and I'm af

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Sat, Mar 9, 2019 at 11:03 AM Magnus Hagander wrote: > On Sun, Feb 17, 2019 at 7:50 PM Michael Paquier > wrote: > >> On Fri, Feb 15, 2019 at 08:03:24PM -0800, Andres Freund wrote: >> > I see you've marked the patch as needs review - but as the patch >> > previously was marked as ready-for-comm

Re: Should we increase the default vacuum_cost_limit?

On 10/03/2019 06:55, Tom Lane wrote: Andrew Dunstan writes: On 3/9/19 4:28 AM, David Rowley wrote: I agree that vacuum_cost_delay might not be granular enough, however. If we're going to change the vacuum_cost_delay into microseconds, then I'm a little concerned that it'll silently break exist

Re: Patch to document base64 encoding

Hi Fabien (and Michael), On Wed, 6 Mar 2019 16:37:05 -0600 "Karl O. Pinc" wrote: > I'm confident that the behavior I documented is how PG behaves > but you should know what I did in case you want further > validation. > > Attached: doc_base64_v8.patch FYI. To avoid a stall in the patch submis

Re: Should we increase the default vacuum_cost_limit?

Julien Rouhaud writes: > On Sat, Mar 9, 2019 at 7:58 PM Andrew Dunstan > wrote: >> On 3/9/19 12:55 PM, Tom Lane wrote: >>> The idea of converting vacuum_cost_delay into a float variable, while >>> keeping its native unit as ms, seems probably more feasible from a >>> compatibility standpoint. Th

Re: Should we increase the default vacuum_cost_limit?

Gavin Flower writes: > Hope about  keeping the default unit of ms, but converting it to a > 'double' for input, but storing it as int (or long?) number of > nanoseconds.  Gives finer grain of control withouthaving to specify a > unit, while still allowing calculations to be fast? Don't really

Re: proposal: plpgsql pragma statement

čt 7. 3. 2019 v 18:45 odesílatel Andrew Dunstan < andrew.duns...@2ndquadrant.com> napsal: > > On 3/7/19 12:41 PM, Pavel Stehule wrote: > > > > > > čt 7. 3. 2019 v 18:35 odesílatel Andrew Dunstan > > > > napsal: > > > > > > > > > > The other thing that bu

Re: PATCH: Include all columns in default names for foreign key constraints.

Thanks for the comments! On Fri, Feb 8, 2019 at 2:11 AM Peter Eisentraut wrote: > > On 13/01/2019 01:55, Paul Martinez wrote: > > I pretty much just copied and pasted the implementation from > > ChooseIndexNameAddition and placed it in src/backend/commands/tablecmds.c. > > The use of "name2" in t

Re: Should we increase the default vacuum_cost_limit?

BTW ... I noticed while fooling with this that GUC's out-of-range messages can be confusing: regression=# set vacuum_cost_delay = '1s'; ERROR: 1000 is outside the valid range for parameter "vacuum_cost_delay" (0 .. 100) One's immediate reaction to that is "I put in 1, not 1000". I think it'd b

Re: Re: SQL:2011 PERIODS vs Postgres Ranges?

On Tue, Mar 5, 2019 at 12:35 AM David Steele wrote: > I have marked this patch as targeting PG13 since it is clearly not > material for PG12. I also added you as the patch author. Thanks David! Targeting PG13 was my intention, so sorry if I messed up the commitfest entry. Here is a new patch re

Re: Pluggable Storage - Andres's take

> On Sat, Mar 9, 2019 at 4:13 AM Andres Freund wrote: > > While 0001 is pretty bulky, the interesting bits concentrate on a > comparatively small area. I'd appreciate if somebody could give the > comments added in tableam.h a read (both on callbacks, and their > wrappers, as they have different au

Re: Pluggable Storage - Andres's take

Hi, On 2019-03-10 05:49:26 +0100, Dmitry Dolgov wrote: > > On Sat, Mar 9, 2019 at 4:13 AM Andres Freund wrote: > > > > While 0001 is pretty bulky, the interesting bits concentrate on a > > comparatively small area. I'd appreciate if somebody could give the > > comments added in tableam.h a read (

Re: SQL:2011 PERIODS vs Postgres Ranges?

Hi Pail, On 3/10/19 2:41 AM, Paul A Jungwirth wrote: On Tue, Mar 5, 2019 at 12:35 AM David Steele wrote: I have marked this patch as targeting PG13 since it is clearly not material for PG12. I also added you as the patch author. Thanks David! Targeting PG13 was my intention, so sorry if I m

Re: Feature: temporary materialized views

On 3/8/19 3:38 AM, Michael Paquier wrote: On Thu, Mar 07, 2019 at 10:45:04AM +0200, David Steele wrote: I think a new patch is required here so I have marked this Waiting on Author. cfbot is certainly not happy and anyone trying to review is going to have hard time trying to determine what to r

Re: Patch to document base64 encoding

Hello Karl, I registered as a reviewer in the CF app. "The string and the binary encode and decode functions..." sentence looks strange to me, especially with the English article that I do not really master, so maybe it is ok. I'd have written something more straightforward, eg: "Functions en