Re: Questions/Observations related to Gist vacuum

On Fri, Oct 18, 2019 at 10:48 AM Amit Kapila wrote: > > Thanks for the test. It shows that prior to patch the memory was > getting leaked in TopTransactionContext during multi-pass vacuum and > after patch, there is no leak. I will commit the patch early next > week unless Heikki or someone

Cannot commit or rollback in “security definer” PL/pgSQL proc

Here’s a cut-down version of Umair Shahid’s blog post here: https://www.2ndquadrant.com/en/blog/postgresql-11-server-side-procedures-part-1/ __ create table t(k int primary key, v int not null); create

Re: dropdb --force

po 21. 10. 2019 v 7:11 odesílatel Amit Kapila napsal: > On Sun, Oct 20, 2019 at 2:06 AM Pavel Stehule > wrote: > > > > so 19. 10. 2019 v 12:37 odesílatel Amit Kapila > napsal: > >> > >> On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule > wrote: > >> > > >> >> > >> >> Can we add few tests for this

Re: Remove obsolete information schema tables

On Sun, Oct 20, 2019 at 10:01:09AM +0200, Peter Eisentraut wrote: > On 2019-10-17 09:44, Michael Paquier wrote: > > I have a question here. Per the notes in information_schema.sql, > > SQL_SIZING_PROFILES has been removed in SQL:2011, > > OK, we can remove that one as well. New patch attached.

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Fri, Oct 18, 2019 at 5:32 PM Amit Kapila wrote: I have replied to some of your questions inline. I will work on the remaining comments and post the patch for the same. > > > > > > Sure, I wasn't really proposing to adding all stats from that patch, > > > including those related to

Re: dropdb --force

On Sun, Oct 20, 2019 at 2:06 AM Pavel Stehule wrote: > > so 19. 10. 2019 v 12:37 odesílatel Amit Kapila > napsal: >> >> On Fri, Oct 4, 2019 at 9:54 PM Pavel Stehule wrote: >> > >> >> >> >> Can we add few tests for this feature. >> > >> > there are not any other test for DROP DATABASE >> > >>

Re: Fix of fake unlogged LSN initialization

On Sat, Oct 19, 2019 at 05:03:00AM +, tsunakawa.ta...@fujitsu.com wrote: > The attached trivial patch fixes the initialization of the fake > unlogged LSN. Currently, BootstrapXLOG() in initdb sets the initial > fake unlogged LSN to FirstNormalUnloggedLSN (=1000), but the > recovery and

Re: Missing error_context_stack = NULL in AutoVacWorkerMain()

Michael Paquier writes: > On Mon, Oct 21, 2019 at 12:47:40AM -0400, Tom Lane wrote: >> This seems like a real and possibly serious bug to me. Backend sigsetjmp >> callers *must* clear error_context_stack (or restore it to a previous >> value), because if it isn't NULL it's surely pointing at

Re: Missing error_context_stack = NULL in AutoVacWorkerMain()

On Mon, Oct 21, 2019 at 12:47:40AM -0400, Tom Lane wrote: > This seems like a real and possibly serious bug to me. Backend sigsetjmp > callers *must* clear error_context_stack (or restore it to a previous > value), because if it isn't NULL it's surely pointing at garbage, ie a > local variable

Re: Missing error_context_stack = NULL in AutoVacWorkerMain()

I wrote: > The issue might be argued to be insignificant because the autovacuum > worker is just going to do proc_exit anyway. But if it encountered > another error during proc_exit, elog.c might try to invoke error > callbacks using garbage callback data. Oh --- looking closer, proc_exit itself

Re: Missing error_context_stack = NULL in AutoVacWorkerMain()

Michael Paquier writes: > On Fri, Oct 18, 2019 at 05:55:32PM -0700, Ashwin Agrawal wrote: >> I am not sure if this causes any potential problems or not, but for >> consistency of code seems we are missing below. All other places in code >> where sigsetjmp() exists for top level handling has

Re: Fix most -Wundef warnings

> "Mark" == Mark Dilger writes: Mark> I tried briefly to download this project from pgfoundry without Mark> success. Do you have a copy of the relevant code where you can Mark> see how this gets defined, and can you include it in a reply? I have a backup of the CVS from the pgfoundry

Re: Remove obsolete options for createuser

On Sat, Oct 19, 2019 at 03:34:56PM +0300, Alexander Lakhin wrote: > I've noticed that the createuser utility supports two undocumented > options (--adduser, --no-adduser), that became obsolete in 2005. > I believe that their existence should come to end someday (maybe > today?). The patch to

Re: Missing error_context_stack = NULL in AutoVacWorkerMain()

On Fri, Oct 18, 2019 at 05:55:32PM -0700, Ashwin Agrawal wrote: > I am not sure if this causes any potential problems or not, but for > consistency of code seems we are missing below. All other places in code > where sigsetjmp() exists for top level handling has error_context_stack set > to NULL.

Re: Ordering of header file inclusion

Amit Kapila writes: > On Sun, Oct 20, 2019 at 10:58 PM vignesh C wrote: >> Should we make this changes only in master branch or should we make in >> back branches also. > I am in favor of doing this only for HEAD, but I am fine if others > want to see for back branches as well and you can

Re: Ordering of header file inclusion

On Sun, Oct 20, 2019 at 10:58 PM vignesh C wrote: > > On Thu, Oct 17, 2019 at 4:44 PM Amit Kapila wrote: > > > > > > I haven't reviewed it completely, but generally, the changes seem to > > be fine. Please see if you can be consistent in extra space between > > includes. Kindly check the same

Re: Fix most -Wundef warnings

On 10/15/19 5:23 AM, Andrew Gierth wrote: "Mark" == Mark Dilger writes: >> +#ifdef HSTORE_IS_HSTORE_NEW Mark> Checking the current sources, git history, and various older Mark> commits, I did not find where HSTORE_IS_HSTORE_NEW was ever Mark> defined. In contrib/hstore, it never

Re: libpq: Fix wrong connection status on invalid "connect_timeout"

On Fri, Oct 18, 2019 at 02:01:23PM +0200, Lars Kanis wrote: > Am 18.10.19 um 05:06 schrieb Michael Paquier: >> So attached is a patch to skip trailing whitespaces as well, >> which also fixes the issue with ECPG. I have refactored the parsing >> logic a bit while on it. The comment at the top of

回复：Bug about drop index concurrently

Thanks for the quick reply. And sorry I haven’t got back to you sooner . I have seen this backtrace in the core file, and I also looked at the bug in the standby because there is no lock in the drop index concurrently. However, when our business will perform a large number of queries in the

Re: [HACKERS] Block level parallel vacuum

On Fri, Oct 18, 2019 at 3:48 PM Dilip Kumar wrote: > > On Fri, Oct 18, 2019 at 11:25 AM Amit Kapila wrote: > > > > On Fri, Oct 18, 2019 at 8:45 AM Dilip Kumar wrote: > > > > > > On Thu, Oct 17, 2019 at 4:00 PM Amit Kapila > > > wrote: > > > > > > > > On Thu, Oct 17, 2019 at 3:25 PM Dilip

Re: configure fails for perl check on CentOS8

Andrew Dunstan writes: > On 10/20/19 1:23 PM, Tom Lane wrote: >> The right way to fix it, likely, is to add CFLAGS_SL while performing this >> particular autoconf test, as that would replicate the switches used for >> plperl (and it turns out that adding -fPIC does solve this problem). >> But the

Re: jsonb_set() strictness considered harmful to data

Steven Pousty wrote: > I would think though that raising an exception is better than a > default behavior which deletes data. I can't help but feel the need to make the point that the function is not deleting anything. It is just returning null. The deletion of data is being performed by an

Re: Tweaking DSM and DSA limits

On Fri, Jun 21, 2019 at 6:52 AM Andres Freund wrote: > On 2019-06-20 14:20:27 -0400, Robert Haas wrote: > > On Tue, Jun 18, 2019 at 9:08 PM Thomas Munro wrote: > > > Perhaps also the number of slots per backend should be dynamic, so > > > that you have the option to increase it from the current

Re: jsonb_set() strictness considered harmful to data

On 10/20/19 4:18 PM, Tomas Vondra wrote: > On Sun, Oct 20, 2019 at 03:48:05PM -0400, Andrew Dunstan wrote: >> >> On 10/20/19 1:14 PM, David G. Johnston wrote: >>> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan >>> >> > wrote: >>> >>>     And yet another is

Re: Clean up MinGW def file generation

On 2019-10-20 10:26, Peter Eisentraut wrote: > On 2019-10-18 15:00, Tom Lane wrote: >> Yeah, the comment that Peter complained about is mine. I believe the >> desire to avoid depending on "sed" at build time was focused on our >> old support for building libpq with Borland C (and not much else).

Re: jsonb_set() strictness considered harmful to data

> > > You're not following because you don't want to follow. > > I think that anyone with a "commit bit" on this project that tolerates that sentence is a much better human being than I ever will be. I may be the dumbest person on this list by many measures - but isn't there standard options that

Re: pause recovery if pitr target not reached

On Sat, 2019-10-19 at 21:45 +0200, Peter Eisentraut wrote: > On 2019-09-17 13:23, Leif Gunnar Erlandsen wrote: > > This patch allows PostgreSQL to pause recovery before PITR target is > > reached > > if recovery_target_time is specified. > > > > Missing WAL's could then be restored from backup

Re: jsonb_set() strictness considered harmful to data

I would think though that raising an exception is better than a default behavior which deletes data. As an app dev I am quite used to all sorts of "APIs" throwing exceptions and have learned to deal with them. This is my way of saying that raising an exception is an improvement over the current

Re: jsonb_set() strictness considered harmful to data

On Sun, Oct 20, 2019 at 03:48:05PM -0400, Andrew Dunstan wrote: On 10/20/19 1:14 PM, David G. Johnston wrote: On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan mailto:andrew.duns...@2ndquadrant.com>> wrote: And yet another is to raise an exception, which is easy to write but really punts

Re: jsonb_set() strictness considered harmful to data

On 10/20/19 1:14 PM, David G. Johnston wrote: > On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan > > wrote: > > And yet another is to > raise an exception, which is easy to write but really punts the issue > back to the application programmer who

Re: configure fails for perl check on CentOS8

On 10/20/19 1:23 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 10/18/19 9:50 AM, Tom Lane wrote: >>> Can we fix this by using something other than perl_alloc() as >>> the tested-for function? That is surely a pretty arbitrary >>> choice. Are there any standard Perl entry points that are

Re: documentation inconsistent re: alignment

Chapman Flack writes: > The documentation for CREATE TYPE has this to say about alignment: > "The alignment parameter specifies the storage alignment required for the > data type. The allowed values equate to alignment on 1, 2, 4, or 8 byte > boundaries." > ... while the documentation for

Re: Ordering of header file inclusion

On Sun, Oct 20, 2019 at 2:44 AM Andres Freund wrote: > > Hi, > > On 2019-10-19 21:50:03 +0200, Peter Eisentraut wrote: > > diff --git a/contrib/bloom/blcost.c b/contrib/bloom/blcost.c > > index f9fe57f..6224735 100644 > > --- a/contrib/bloom/blcost.c > > +++ b/contrib/bloom/blcost.c > > @@ -12,10

Re: Ordering of header file inclusion

On Sun, Oct 20, 2019 at 1:20 AM Peter Eisentraut wrote: > > diff --git a/contrib/bloom/blcost.c b/contrib/bloom/blcost.c > index f9fe57f..6224735 100644 > --- a/contrib/bloom/blcost.c > +++ b/contrib/bloom/blcost.c > @@ -12,10 +12,10 @@ > */ > #include "postgres.h" > > +#include "bloom.h" >

Re: configure fails for perl check on CentOS8

Andrew Dunstan writes: > On 10/18/19 9:50 AM, Tom Lane wrote: >> Can we fix this by using something other than perl_alloc() as >> the tested-for function? That is surely a pretty arbitrary >> choice. Are there any standard Perl entry points that are just >> plain functions with no weird macro

Re: jsonb_set() strictness considered harmful to data

On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > And yet another is to > raise an exception, which is easy to write but really punts the issue > back to the application programmer who will have to decide how to ensure > they never pass in a NULL parameter.

Re: Declaring a strict function returns not null / eval speed

Moin, On 2019-10-20 16:27, Tom Lane wrote: Tels writes: On 2019-10-20 13:30, Andreas Karlsson wrote: Agreed, this sounds like something useful to do since virtually all strict functions cannot return NULL, especially the ones which are used in tight loops. The main design issue seems to be

Re: Declaring a strict function returns not null / eval speed

Tels writes: > On 2019-10-20 13:30, Andreas Karlsson wrote: >> Agreed, this sounds like something useful to do since virtually all >> strict functions cannot return NULL, especially the ones which are >> used in tight loops. The main design issue seems to be to think up a >> name for this new

Re: jsonb_set() strictness considered harmful to data

On Sun, 20 Oct 2019 at 08:32, Andrew Dunstan wrote: > > Understood. I think the real question here is what it should do instead > when the value is NULL. Your behaviour above is one suggestion, which I > personally find intuitive. Another has been to remove the associated > key. Another is to

Re: jsonb_set() strictness considered harmful to data

On 10/20/19 4:39 AM, Floris Van Nee wrote: > > FWIW I've been bitten by this 'feature' more than once as well, > accidentally erasing a column. Now I usually write js = jsonb_set(js, > coalesce(new_column, 'null'::jsonb)) to prevent erasing the whole > column, and instead setting the value to a

Re: Declaring a strict function returns not null / eval speed

Moin, On 2019-10-20 13:30, Andreas Karlsson wrote: On 10/1/19 9:38 AM, Andres Freund wrote: We spend a surprising amount of time during expression evaluation to reevaluate whether input to a strict function (or similar) is not null, even though the value either comes from a strict function,

Re: Declaring a strict function returns not null / eval speed

On 10/1/19 9:38 AM, Andres Freund wrote: We spend a surprising amount of time during expression evaluation to reevaluate whether input to a strict function (or similar) is not null, even though the value either comes from a strict function, or a column declared not null. Now you can

jsonb_set() strictness considered harmful to data

FWIW I've been bitten by this 'feature' more than once as well, accidentally erasing a column. Now I usually write js = jsonb_set(js, coalesce(new_column, 'null'::jsonb)) to prevent erasing the whole column, and instead setting the value to a jsonb null value, but I also found the STRICT

Re: Clean up MinGW def file generation

On 2019-10-18 15:00, Tom Lane wrote: > Yeah, the comment that Peter complained about is mine. I believe the > desire to avoid depending on "sed" at build time was focused on our > old support for building libpq with Borland C (and not much else). > Since this makefile infrastructure is now only

Re: Remove obsolete information schema tables

On 2019-10-17 09:44, Michael Paquier wrote: > I have a question here. Per the notes in information_schema.sql, > SQL_SIZING_PROFILES has been removed in SQL:2011, OK, we can remove that one as well. New patch attached. > attributes.isnullable and DOMAIN_UDT_USAGE in SQL:2003~. Would it > make