Re: using index or check in ALTER TABLE SET NOT NULL

Hello Sergei, I couldn't find any case when your code doesn't work properly. So it seems ok to me. @@ -220,6 +220,13 @@ WITH ( MODULUS numeric_literal, REM + Full table scan is performed to check that no existing row + in the table has null values in given column.

Re: public schema default ACL

On Sat, Mar 03, 2018 at 02:31:58AM -0800, Joe Conway wrote: > On 03/03/2018 01:56 AM, Noah Misch wrote: > > If we do that alone, databases reaching v11 via dump/reload or pg_upgrade > > will > > get the new default ACL if they had not changed the ACL of schema public. > > If > > they had

Re: PATCH: psql tab completion for SELECT

I've reworked the SELECT completion patch to use the VersionedQuery infrastructure. I've also made it a schema query (for the functions), with an addon for the attributes. This provides schema-aware completion. Previously, addons to schema queries were appended verbatim; I've changed this to

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 6 March 2018 at 11:43, Alvaro Herrera wrote: > Pushed now, to branches master and pg10, with Tomas changes. I made a > few changes of my own Great! Many thanks to both of you for making those changes and thanks Alvaro for pushing. > 3. I chose not to backpatch the

Re: inserts into partitioned table may cause crash

Fujita-san, Thanks for the review. On 2018/03/05 22:00, Etsuro Fujita wrote: > I started reviewing this.  I think the analysis you mentioned upthread > would be correct, but I'm not sure the patch is the right way to go > because I think that exception handling added by the patch throughout >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-06 2:32 GMT+01:00 Michael Paquier : > On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote: > > I afraid so there is not good solution. Is possible to store options in > > original form? When the function will be displayed, then the original > value > > will

Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

On Mon, Mar 5, 2018 at 8:58 AM, Thomas Munro wrote: > On Sun, Mar 4, 2018 at 12:53 AM, Amit Kapila wrote: >> Yes, but I think it would be better if we call this once we are sure >> that at least one tuple from the old bucket has been

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

05.03.2018 18:00, Tom Lane пишет: > Tomas Vondra writes: >> Snapshots are static (we don't really add new XIDs into existing ones, >> right?), so why don't we simply sort the XIDs and then use bsearch to >> lookup values? That should fix the linear search, without

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire wrote: >> Introducing any case that allows us to land on a recycled page, and >> reason that it must at least not be the page we were looking for based >> on *any* criteria about the page itself seems very brittle. Yeah, it >>

Re: constraint exclusion and nulls in IN (..) clause

Hi. Thanks for reviewing again. On 2018/03/05 23:04, Emre Hasegeli wrote: >>> Shouldn't we check if we consumed all elements (state->next_elem >= >>> state->num_elems) inside the while loop? >> >> You're right. Fixed. > > I don't think the fix is correct. arrayconst_next_fn() can still >

Re: Faster inserts with mostly-monotonically increasing values

On Tue, Mar 6, 2018 at 7:29 AM, Peter Geoghegan wrote: > On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire > wrote: > > > I believe PKs are a prime candidate for this optimization, and > > expecting it to apply only when no concurrency is involved is severely

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Mar 5, 2018 at 3:02 AM, Pavan Deolasee wrote: >> Again, I have to ask: is such an UPDATE actually meaningfully >> different from a concurrent DELETE + INSERT? If so, why is a special >> error better than a dup violation, or maybe even having the INSERT >> (and

Re: PATCH: Configurable file mode mask

On Mon, Mar 05, 2018 at 03:07:20PM -0500, David Steele wrote: > On 2/28/18 2:28 AM, Michael Paquier wrote: >> On Tue, Feb 27, 2018 at 03:52:32PM -0500, David Steele wrote: >> I don't quite understand here. I have no objection into extending >> setup_cluster() with a group_access argument so as

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 10:59 PM, Peter Geoghegan wrote: > On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire wrote: >> But in thise case there's no right link to follow, so it's a non-issue. >> >> BTree doesn't truncate AFAIK, so the cached block number can't be

Re: [PATCH] GET DIAGNOSTICS FUNCTION_NAME

On Thu, 1 Mar 2018 14:29:58 -0800 Andres Freund wrote: > Hi, > > On 2018-01-11 11:03:26 +0900, Yugo Nagata wrote: > > However, I don't inisist on this patch, so If anyone other don't need this > > feature, I'll withdraw this. > > Given this is where the discussion dried up

Re: pgsql: Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL)

Thomas Munro wrote: > On Tue, Mar 6, 2018 at 11:39 AM, Alvaro Herrera > wrote: > > Clone extended stats in CREATE TABLE (LIKE INCLUDING ALL) > > Is this commit responsible for this valgrind error? > >

Re: Kerberos test suite

On Mon, Mar 05, 2018 at 02:45:07PM -0500, Peter Eisentraut wrote: > On 2/27/18 00:21, Michael Paquier wrote: >> +my ($stdout, $krb5_version); >> +IPC::Run::run [ 'krb5-config', '--version' ], '>', \$stdout or die >> "could not execute krb5-config"; >> +$stdout =~ m/Kerberos 5 release

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire wrote: > From what I read, both phase 1 & 2 are served by the !P_IGNORE check. True. > For the third phase: > >> A deleted page can only be reclaimed once there is no scan or search that >> has a reference to it; until then,

Re: BUG #14941: Vacuum crashes

On 2018-03-03 16:12:52 -0800, Andres Freund wrote: > On 2018-01-11 08:14:42 +0900, Michael Paquier wrote: > > On Wed, Jan 10, 2018 at 05:26:43PM +, Bossart, Nathan wrote: > > > Perhaps any logging changes for VACOPT_NOWAIT could be handled in a > > > separate thread. For now, I've updated

Re: Re: BUGFIX: standby disconnect can corrupt serialized reorder buffers

On 5 March 2018 at 23:25, David Steele wrote: > Hi Craig, > > On 1/21/18 5:45 PM, Craig Ringer wrote: > > On 6 January 2018 at 08:28, Alvaro Herrera > > wrote: > > > > I think this should use ReadDirExtended with

Re: 2018-03 CFM

On 2018-03-05 20:49:02 -0500, David Steele wrote: > On 3/5/18 8:33 PM, Thomas Munro wrote: > > On Tue, Mar 6, 2018 at 1:00 PM, David Steele wrote: > >> I've been using commitfest.cputube.org for reference since the last CF, > >> though I'm unsure if it rechecks patches when

Re: 2018-03 CFM

On 3/5/18 8:33 PM, Thomas Munro wrote: > On Tue, Mar 6, 2018 at 1:00 PM, David Steele wrote: >> I've been using commitfest.cputube.org for reference since the last CF, >> though I'm unsure if it rechecks patches when master changes, so I do >> that manually. Anyway, that's

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 9:52 PM, Peter Geoghegan wrote: > On Mon, Mar 5, 2018 at 4:37 PM, Claudio Freire wrote: >> Correct me if I'm wrong, but there's lots of code in nbtree already >> that risks reading recycled pages for various reasons. Presumably, >>

Re: PATCH: Configurable file mode mask

On 3/5/18 8:03 PM, Michael Paquier wrote: > On Mon, Mar 05, 2018 at 05:11:29PM -0500, Tom Lane wrote: >> David Steele writes: >>> On 2/28/18 2:28 AM, Michael Paquier wrote: That's basically a recursive chmod, so chmod_recursive is more adapted? I could imagine that

Re: User defined data types in Logical Replication

On Tue, Mar 6, 2018 at 8:35 AM, Alvaro Herrera wrote: > I noticed that logicalrep_typmap_gettypname's only caller is > slot_store_error_callback, which is an error callback. So by raising an > error from the former, we would effectively just hide the actual reason > for

Re: Change RangeVarGetRelidExtended() to take flags argument?

On Mon, Mar 05, 2018 at 05:21:11PM -0800, Andres Freund wrote: > Hi, > > On 2018-03-06 10:17:49 +0900, Michael Paquier wrote: > > On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > > > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > > > similar code. It'd

Re: 2018-03 CFM

On Tue, Mar 6, 2018 at 1:00 PM, David Steele wrote: > I've been using commitfest.cputube.org for reference since the last CF, > though I'm unsure if it rechecks patches when master changes, so I do > that manually. Anyway, that's probably too much to ask since every push >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote: > I afraid so there is not good solution. Is possible to store options in > original form? When the function will be displayed, then the original value > will be displayed. The current patch (with known extensions) can be used as > bug

Re: Change RangeVarGetRelidExtended() to take flags argument?

Hi, On 2018-03-06 10:17:49 +0900, Michael Paquier wrote: > On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > > similar code. It'd not be too hard to move RangeVarGetRelidExtended() > > code into

Re: Change RangeVarGetRelidExtended() to take flags argument?

On Mon, Mar 05, 2018 at 05:06:59PM -0800, Andres Freund wrote: > Yea, that's a concern. OTOH, it doesn't seem nice to grow duplicates of > similar code. It'd not be too hard to move RangeVarGetRelidExtended() > code into RangeVarGetRelidInternal() and add > RangeVarGetRelidTryLock(). Not sure if

Re: Change RangeVarGetRelidExtended() to take flags argument?

On 2018-03-05 19:57:44 -0500, Tom Lane wrote: > Andres Freund writes: > > One wrinkle in that plan is that it'd not be trivial to discern whether > > a lock couldn't be acquired or whether the object vanished. I don't > > really have good idea how to tackle that yet. > > Do

Re: PATCH: Configurable file mode mask

On Mon, Mar 05, 2018 at 05:11:29PM -0500, Tom Lane wrote: > David Steele writes: >> On 2/28/18 2:28 AM, Michael Paquier wrote: >>> That's basically a recursive chmod, so chmod_recursive is more adapted? >>> I could imagine that this is useful as well for removing group >>>

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

On Mon, Mar 05, 2018 at 04:34:09PM -0800, Andres Freund wrote: > Scratch that, we should be going down the > /* If caller supplied OID, there's nothing we need do here. */ > if (OidIsValid(vrel->oid)) > { > oldcontext = MemoryContextSwitchTo(vac_context); >

Re: Change RangeVarGetRelidExtended() to take flags argument?

Andres Freund writes: > One wrinkle in that plan is that it'd not be trivial to discern whether > a lock couldn't be acquired or whether the object vanished. I don't > really have good idea how to tackle that yet. Do we really care which case applies? But having to mess

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

On 2018-03-05 19:53:23 -0500, Tom Lane wrote: > Andres Freund writes: > > Scratch that, we should be going down the > > /* If caller supplied OID, there's nothing we need do here. */ > > branch in expand_vacuum_rel() for autovacuum, so this shouldn't > > matter. Sorry for

Change RangeVarGetRelidExtended() to take flags argument?

Hi, https://www.postgresql.org/message-id/7327b413-1a57-477f-a6a0-6fd80cb54...@amazon.com adds a SKIP LOCKED option to vacuum. To avoid blocking in expand_vacuum_rel()'s call of RangeVarGetRelid(), it open codes a SKIP_LOCKED variant (i.e. RangeVarGetRelidExtended()'s nowait, but doesn't error

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

Andres Freund writes: > Scratch that, we should be going down the > /* If caller supplied OID, there's nothing we need do here. */ > branch in expand_vacuum_rel() for autovacuum, so this shouldn't > matter. Sorry for the noise But you said you'd seen blocking behind AEL

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 4:37 PM, Claudio Freire wrote: > Correct me if I'm wrong, but there's lots of code in nbtree already > that risks reading recycled pages for various reasons. Presumably, > checking P_ISDELETED and P_ISHALFDEAD should be enough, which is what >

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 9:37 PM, Claudio Freire wrote: > Assuming the rightmost page is the first page the value could be on, > it already does get an exclusive buffer lock. That made me check, and: +/* + * Acquire exclusive lock on the buffer before doing

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

Andres Freund writes: > On 2017-09-29 20:26:42 +, Tom Lane wrote: >> get_rel_oids used to not take any relation locks at all, but that stopped >> being a good idea with commit 3c3bb9933, which inserted a syscache lookup >> into the function. A concurrent DROP TABLE could

Re: Cache lookup errors with functions manipulation object addresses

On Mon, Mar 05, 2018 at 12:57:38PM +, Aleksander Alekseev wrote: > It looks like that this patch doesn't apply anymore: > http://commitfest.cputube.org/ > > The new status of this patch is: Waiting on Author Yes, this happens because patch 0003 from the last series has been committed as

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 5, 2018 at 9:12 PM, Peter Geoghegan wrote: > On Thu, Mar 1, 2018 at 3:18 PM, Claudio Freire wrote: >> The key there is strictly greater than the rightmost key. As such, it >> must precede the first page with an equal key, and since it's the >>

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

On 2018-03-05 16:11:52 -0800, Andres Freund wrote: > Hi Tom, > > On 2017-09-29 20:26:42 +, Tom Lane wrote: > > get_rel_oids used to not take any relation locks at all, but that stopped > > being a good idea with commit 3c3bb9933, which inserted a syscache lookup > > into the function. A

Re: Faster inserts with mostly-monotonically increasing values

On Thu, Mar 1, 2018 at 3:18 PM, Claudio Freire wrote: > given... > > +if (P_ISLEAF(lpageop) && P_RIGHTMOST(lpageop) && > +!P_INCOMPLETE_SPLIT(lpageop) && > +!P_IGNORE(lpageop) && > +(PageGetFreeSpace(page) > itemsz) && > +

Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids().

Hi Tom, On 2017-09-29 20:26:42 +, Tom Lane wrote: > get_rel_oids used to not take any relation locks at all, but that stopped > being a good idea with commit 3c3bb9933, which inserted a syscache lookup > into the function. A concurrent DROP TABLE could now produce "cache lookup > failed",

Re: 2018-03 CFM

On 3/5/18 6:06 PM, Thomas Munro wrote: > On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev >> >> I don't think commitfest.cputube.org has the SQL data on whether patch >> pass the tests. It just displays SVG images from travis-ci.org. Also >> unfortunately both commitfest.postgresql.org and

RE: [bug fix] pg_rewind takes long time because it mistakenly copies data files

From: Fujii Masao [mailto:masao.fu...@gmail.com] > Thanks for the patch! Pushed. Thank you. I'm glad to see you again on this list. Regards Takayuki Tsunakawa

Re: PATCH: Configurable file mode mask

On 3/5/18 5:51 PM, Tom Lane wrote: > David Steele writes: >> On 3/5/18 5:11 PM, Tom Lane wrote: >>> David Steele writes: I'm not sure what the protocol for introducing a new Perl module is? I couldn't find packages for the major OSes. Are we

Re: jsonpath

On 06.03.2018 00:29, Tomas Vondra wrote: Hi, The patch no longer applies - it got broken by fd1a421fe66 which changed columns in pg_proc. A rebase is needed. Fixing it is pretty simle, so I've done that locally and tried to run 'make check' under valgrind. And I got a bunch of reports about

Re: 2018-03 Commitfest Summary (Andres #1)

Hi, On 2018-03-04 11:03:05 +0100, Fabien COELHO wrote: > > A lot of contributors, including serial ones, don't even remotely put in > > as much resources reviewing other people's patches as they use up in > > reviewer and committer bandwidth. You certainly have contributed more > > patches than

Re: User defined data types in Logical Replication

I noticed that logicalrep_typmap_gettypname's only caller is slot_store_error_callback, which is an error callback. So by raising an error from the former, we would effectively just hide the actual reason for the error behind the error that the cache entry cannot be found. Therefore, I'm

Re: [HACKERS] Creating backup history files for backups taken from standbys

On Tue, Mar 06, 2018 at 02:23:19AM +0900, Fujii Masao wrote: > I have no objection to mark the patch "returned with feedback". Yes I have done so, that's way too late. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi, On 2018-02-13 12:41:26 +0530, amul sul wrote: > From 08c8c7ece7d9411e70a780dbeed89d81419db6b6 Mon Sep 17 00:00:00 2001 > From: Amul Sul > Date: Tue, 13 Feb 2018 12:37:52 +0530 > Subject: [PATCH 1/2] Invalidate ip_blkid v5 > > v5: > - Added code in heap_mask to skip

Re: Weird failures on lorikeet

On Thu, Feb 22, 2018 at 7:06 AM, Andres Freund wrote: > Hi Andrew, > > I noticed your animal lorikeet failed in the last two runs: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet=2018-02-21%2009%3A47%3A17 > TRAP: FailedAssertion("!(((PageHeader)

Re: 2018-03 CFM

On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev wrote: >> You do realize we have the actual source database available, I hope? Since >> it's our own system... There is no need to scrape the data back out -- if >> we can just define what kind of reports we want, we

Re: jsonpath

Thanks, Tomas ! Will publish a new version really soon ! Regards, Oleg On Tue, Mar 6, 2018 at 12:29 AM, Tomas Vondra wrote: > Hi, > > The patch no longer applies - it got broken by fd1a421fe66 which changed > columns in pg_proc. A rebase is needed. > > Fixing it

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 03/05/2018 02:07 PM, Tom Lane wrote: > So you can revert the rhinoceros config change if you like --- thanks > for making it so quickly! Ok, reverted. > Meanwhile, I'm back to wondering what could possibly have affected > the planner's estimates, if pg_proc and pg_statistic didn't change. > I

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

On 03/05/2018 08:34 PM, Tom Lane wrote: > Tomas Vondra writes: >> On 03/04/2018 09:46 PM, Tom Lane wrote: >>> Well, I think the existing bytea bug is a counterexample to that. If >>> someone were to repeat that mistake with, say, UUID, these tests would not >>>

Re: PATCH: Configurable file mode mask

David Steele writes: > On 3/5/18 5:11 PM, Tom Lane wrote: >> David Steele writes: >>> I'm not sure what the protocol for introducing a new Perl module is? I >>> couldn't find packages for the major OSes. Are we OK with using CPAN? >> I don't think

Re: 2018-03 CFM

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 3/5/18 4:55 PM, Magnus Hagander wrote: > > > > I would like to get a list of submitter patches totals vs the total > > number of patches they are reviewing.  In the past I have done this by > > eyeball. > > > > I think

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

Pushed now, to branches master and pg10, with Tomas changes. I made a few changes of my own 1. you forgot to update various src/backend/nodes/ files 2. I got rid of "NameData stxname" variable in CreateStatistics, which seems pointless now. We can work with a cstring only. Not sure why we had

Re: [HACKERS] GUC for cleanup indexes threshold.

On Mon, Mar 5, 2018 at 5:56 AM, Masahiko Sawada wrote: > On Sun, Mar 4, 2018 at 8:59 AM, Alexander Korotkov > wrote: > > On Fri, Mar 2, 2018 at 10:53 AM, Masahiko Sawada > > wrote: > >> > >> > 2) In the append-only case,

Re: PATCH: Configurable file mode mask

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > David Steele writes: > > On 2/28/18 2:28 AM, Michael Paquier wrote: > >> That's basically a recursive chmod, so chmod_recursive is more adapted? > >> I could imagine that this is useful as well for removing group > >>

Re: PATCH: Configurable file mode mask

Hi Tom, On 3/5/18 5:11 PM, Tom Lane wrote: > David Steele writes: >> On 2/28/18 2:28 AM, Michael Paquier wrote: >>> That's basically a recursive chmod, so chmod_recursive is more adapted? >>> I could imagine that this is useful as well for removing group >>> permissions, so

Re: PATCH: Configurable file mode mask

David Steele writes: > On 2/28/18 2:28 AM, Michael Paquier wrote: >> That's basically a recursive chmod, so chmod_recursive is more adapted? >> I could imagine that this is useful as well for removing group >> permissions, so the new mode could be specified as an argument. >

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

I admit to much head-scratching, erasing my entire ccache cache, the autoconf cache and doing two complete rebuilds from scratch, because I was seeing 40 errors in regression tests. But it turned out to be about this hunk, which was identical to the idea I had while skimming David's original,

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

Joe Conway writes: > On 03/05/2018 11:19 AM, Tom Lane wrote: >> Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to >> rhinoceros' extra_config options, temporarily? Correlating that log >> output with the log_statement output from the test proper would let >>

Re: 2018-03 CFM

Hi Magnus, On 3/5/18 4:55 PM, Magnus Hagander wrote: > > I would like to get a list of submitter patches totals vs the total > number of patches they are reviewing.  In the past I have done this by > eyeball. > > I think that's pretty much the part that's available under "reports"

Re: JIT compiling with LLVM v11

On 2018-03-05 13:36:04 -0800, Andres Freund wrote: > On 2018-03-05 16:19:52 -0500, Peter Eisentraut wrote: > > Testing 0732ee73cf3ffd18d0f651376d69d4798d351ccc on Debian testing ... > > > > The build works out of the box with whatever the default system packages > > are. > > > > Regression tests

Re: 2018-03 CFM

On Mon, Mar 5, 2018 at 3:48 PM, David Steele wrote: > Hi Aleksander, > > On 3/2/18 7:18 AM, Aleksander Alekseev wrote: > > > >> You do realize we have the actual source database available, I hope? > Since > >> it's our own system... There is no need to scrape the data back

Re: JIT compiling with LLVM v11

Hi, On 2018-03-05 12:17:30 -0800, Andres Freund wrote: > Writing up a patch that I can actually push. Thanks both to Thomas and > Peter for pointing me towards this issue! After screwing the first attempt at a fix, the second one seems to work nicely. With optimizations, inlining, etc all core

Re: JIT compiling with LLVM v11

On 2018-03-05 16:19:52 -0500, Peter Eisentraut wrote: > Testing 0732ee73cf3ffd18d0f651376d69d4798d351ccc on Debian testing ... > > The build works out of the box with whatever the default system packages > are. > > Regression tests crash many times. One backtrace looks like this: > > #0

Re: Kerberos test suite

On Tue, Mar 6, 2018 at 8:45 AM, Peter Eisentraut wrote: > New patch attached. Passes here. LGTM. Only complaint is your assumption that 'darwin' implies HomeBrew installation paths, but you already did that in other tests before this one. Perhaps we can sort

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

On 03/05/2018 08:57 PM, Alvaro Herrera wrote: > Tomas Vondra wrote: > >> 4) I see you've added generateClonedExtStatsStmt to parse_utilcmd.h, but >> it was only really called in parse_utilcmd.c, so I've made it static. I >> don't think we need to expose stuff unnecessarily. > >> BTW the last

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On 03/05/2018 09:37 PM, Thomas Munro wrote: > On Tue, Mar 6, 2018 at 9:17 AM, Robert Haas wrote: >> The optimistic approach seems a little bit less likely to slow this >> down on systems where barriers are expensive, so I committed that one. >> Thanks for debugging this;

Re: jsonpath

Hi, The patch no longer applies - it got broken by fd1a421fe66 which changed columns in pg_proc. A rebase is needed. Fixing it is pretty simle, so I've done that locally and tried to run 'make check' under valgrind. And I got a bunch of reports about uninitialised values. Full report attached,

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

> On 26 Jan 2018, at 00:05, Daniel Gustafsson wrote: > >> On 24 Jan 2018, at 16:45, Alvaro Herrera wrote: >> Maybe have two patches, 0001 creates the files moving the contents over, >> then 0002 adds your new stuff on top. > > The two attached patches

Re: JIT compiling with LLVM v11

Testing 0732ee73cf3ffd18d0f651376d69d4798d351ccc on Debian testing ... The build works out of the box with whatever the default system packages are. Regression tests crash many times. One backtrace looks like this: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1

Re: [PATCH] Verify Checksums during Basebackups

Hi Michael, On 3/5/18 6:36 AM, Stephen Frost wrote: > * Michael Banck (michael.ba...@credativ.de) wrote: > >> So I guess this would have to be sent back via the replication protocol, >> but I don't see an off-hand way to do this easily? > > The final ordinary result set could be extended to

Re: [HACKERS] Partition-wise aggregation/grouping

On Mon, Mar 5, 2018 at 3:56 AM, Jeevan Chalke wrote: > However, to perform Gather or Gather Merge once we have all partial paths > ready, and to avoid too many existing code rearrangement, I am calling > try_partitionwise_grouping() before we do any

Re: PATCH: psql tab completion for SELECT

I wrote: > If people like this approach, I propose to commit this more or less > as-is. The select-tab-completion patch would then need to be rewritten > to use this infrastructure, but I think that should be straightforward. > As a separate line of work, the infrastructure could be applied to

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Tue, Mar 6, 2018 at 9:17 AM, Robert Haas wrote: > The optimistic approach seems a little bit less likely to slow this > down on systems where barriers are expensive, so I committed that one. > Thanks for debugging this; I hope this fixes it, but I guess we'll > see.

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

Joe Conway writes: > On 03/05/2018 11:19 AM, Tom Lane wrote: >> Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to >> rhinoceros' extra_config options, temporarily? Correlating that log >> output with the log_statement output from the test proper would let >>

Re: PATCH: Configurable file mode mask

On 3/1/18 11:18 PM, Michael Paquier wrote: > > Based on my recent lookup at code level for this feature, the patch for > pg_resetwal (which could have been discussed on its own thread as well), > would be fine for commit. The thing could be extended a bit more but > there is nothing opposing

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-02-21 8:35 GMT+01:00 Michael Paquier : > On Tue, Feb 20, 2018 at 06:46:57PM +0300, Arthur Zakirov wrote: > > Just 2 cents from me. It seems that there is a problem with extensions > > GUCs. > > > > [...] > > > > =# SELECT

RE: [HACKERS] Client Connection redirection support for PostgreSQL

Please see the attached patch with the comments. Changes in the patch: A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries. BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1 downgrades to v3.0 upon receipt of this message.

Re: JIT compiling with LLVM v11

Hi, On 2018-03-04 21:00:06 -0800, Andres Freund wrote: > > Looking at llvm_get_function(), the function that raises that error, I > > see that there are a few different paths here. I don't have > > HAVE_DECL_LLVMORCGETSYMBOLADDRESSIN defined, and I don't have LLVM < > > 5, so I should be getting

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 4:46 PM, Thomas Munro wrote: > Thanks! Here are a couple of patches. I'm not sure which I prefer. > The "pessimistic" one looks simpler and is probably the way to go, but > the "optimistic" one avoids doing an extra read until it has

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 03/05/2018 11:19 AM, Tom Lane wrote: > Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to > rhinoceros' extra_config options, temporarily? Correlating that log > output with the log_statement output from the test proper would let > us confirm or deny whether it's autovacuum.

Re: PATCH: Configurable file mode mask

On 2/28/18 2:28 AM, Michael Paquier wrote: > On Tue, Feb 27, 2018 at 03:52:32PM -0500, David Steele wrote: >> On 1/30/18 3:01 AM, Michael Paquier wrote: > >>> +command_ok( >>> + ['chmod', "-R", 'g+rX', "$pgdata"], >>> + 'add group perms to PGDATA'); >>> >>> That would blow up on Windows. You

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Tue, Mar 6, 2018 at 5:04 AM, Alvaro Herrera wrote: > Thomas Munro wrote: >> On Sun, Mar 4, 2018 at 10:46 PM, Magnus Hagander wrote: >> > Um. Have you actually seen the "mail archive app" cut long threads off in >> > other cases? Because it's

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

Tomas Vondra wrote: > 4) I see you've added generateClonedExtStatsStmt to parse_utilcmd.h, but > it was only really called in parse_utilcmd.c, so I've made it static. I > don't think we need to expose stuff unnecessarily. > BTW the last point made me thinking, because parse_utilcmd.h also >

Re: chained transactions

On 2018-03-05 09:21:33 +, Simon Riggs wrote: > On 2 March 2018 at 07:18, Andres Freund wrote: > > Hi, > > > > On 2018-02-28 22:35:52 -0500, Peter Eisentraut wrote: > >> This feature is meant to help manage transaction isolation in > >> procedures. > > > > This is a major

Re: [HACKERS] generated columns

On 2/1/18 21:25, Michael Paquier wrote: > On Thu, Feb 01, 2018 at 09:29:09AM -0500, Peter Eisentraut wrote: >> That would be nice. I'm going to study this some more to see what can >> be done. > > Thanks for the update. Note: Peter has moved the patch to next CF. I didn't get to updating this

Re: Kerberos test suite

On 2/27/18 00:21, Michael Paquier wrote: > Thanks. Could you document that on the README please? krb5-user and > krb5-kdc is a split from Debian. For darwin, are you using macports or > homebrew? I would assume the later, and it would be nice to precise > that in the README as well. On Debian

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

Tomas Vondra writes: > On 03/04/2018 09:46 PM, Tom Lane wrote: >> Well, I think the existing bytea bug is a counterexample to that. If >> someone were to repeat that mistake with, say, UUID, these tests would not >> catch it, because none of them would exercise

Re: [HACKERS] PoC: custom signal handler for extensions

Hi Maksim, On 3/5/18 11:24 AM, Maksim Milyutin wrote: > Hello David, > > > On 05.03.2018 18:50, David Steele wrote: >> Hello Maksim, >> >> On 1/27/18 2:19 PM, Arthur Zakirov wrote: >> >>> Is there actual need in UnregisterCustomProcSignal() within _PG_init()? >>> An extension registers a

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

I wrote: > The thing that I find curious, now that we've shut off autovacuum > altogether on those tables, is that we *still* aren't getting stable > results. How can that be? I spent some time trying to figure out what's going on here. I've still not been able to replicate the failure on any

Re: parallel append vs. simple UNION ALL

On Tue, Feb 27, 2018 at 6:21 AM, Rajkumar Raghuwanshi wrote: > I have applied 0001 on pg-head, and while playing with regression tests, it > crashed with below test case. > > postgres=# SET min_parallel_table_scan_size=0; > SET > postgres=# SELECT * FROM

Re: IndexJoin memory problem using spgist and boxes

On 04.03.2018 20:20, Anton Dignös wrote: The better alternative may be to have two temporary memory contexts, one per-tuple for calling the inner consistent method and one per-index-scan for the traversal memory. Yes, this seems to be a better way of fixing the problem without introducing

  1   2   >