Re: Allow some recovery parameters to be changed with reload

On 05/02/2019 04:35, Michael Paquier wrote: > On Mon, Feb 04, 2019 at 11:58:28AM +0100, Peter Eisentraut wrote: >> I think the recovery parameters >> >> archive_cleanup_command > > Only triggered by the checkpointer. > >> promote_trigger_file >> recovery_end_command >>

Re: Connection slots reserved for replication

On Sat, Feb 02, 2019 at 10:35:20AM +0900, Michael Paquier wrote: > Oh, I have just noticed this patch when doing my vacuum homework. I > have just added my name as committer, just wait a bit until the CF is > closed before I begin looking at it.. So, I have looked at this thread and the latest

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

On Wed, 6 Feb 2019 at 23:44, Tomas Vondra wrote: > > On 2/6/19 10:59 PM, David Rowley wrote: > > On Thu, 7 Feb 2019 at 03:16, Alvaro Herrera > > wrote: > >> I wonder what should we be doing with this series -- concretely, should > >> the effort concentrate on one of the two patches, and leave

Re: Protect syscache from bloating with negative cache entries

At Tue, 5 Feb 2019 19:05:26 -0300, Alvaro Herrera wrote in <20190205220526.GA1442@alvherre.pgsql> > On 2019-Feb-05, Tomas Vondra wrote: > > > I don't think we need to remove the expired entries right away, if there > > are only very few of them. The cleanup requires walking the hash table, > >

Re: Synchronize with imath upstream

On Wed, Feb 06, 2019 at 10:15:24AM -0500, Tom Lane wrote: > Andres Freund writes: > > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera > > wrote: > >> I'm -1 for this myself. I think there are a few places that could > >> benefit from it, but my fear is that many *more* places would

Re: bug tracking system

Michael Paquier writes: > On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: >> I do have a modest proposal for improving things going forward. >> How about, if a commit purports to fix a particular bug, that >> we say "Fixes: https://postgr.es/m/" in place of >> our current habit of

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

I wrote: >>> I've got much of the code for it already (in the wreckage of my failed >>> attempts), so I'll go back and finish that up. So I've been poking at that for most of the day, and I've despaired of being able to fix this in v11. The problem is that somebody was rolling dice while

Re: Shared Memory: How to use SYSV rather than MMAP ?

On Sun, Feb 3, 2019 at 10:56 PM Thomas Munro wrote: > Committed 0001. > I've moved the CF entry to the next Commitfest, since we still have to > fix up and commit the 0002 patch for AIX. For the record, one problem with the shared_memory_type=sysv patch as committed is that if you set

Re: Add pg_partition_root to get top-most parent of a partition tree

On Thu, Feb 07, 2019 at 01:34:15PM +0900, Amit Langote wrote: > Yeah, I agree. Should also check with Alvaro maybe? Good idea. Let's wait for his input. -- Michael signature.asc Description: PGP signature

Re: Add pg_partition_root to get top-most parent of a partition tree

Hi, On 2019/02/06 19:14, Michael Paquier wrote: >> Given that a couple (?) of other patches depend on this, maybe it'd be a >> good idea to proceed with this. > > If you are happy with the version attached, I am fine to commit it. I > think that we have the right semantics and the right test

Re: bug tracking system

On Wed, Feb 06, 2019 at 10:50:51PM -0500, Tom Lane wrote: > I do have a modest proposal for improving things going forward. > How about, if a commit purports to fix a particular bug, that > we say "Fixes: https://postgr.es/m/" in place of > our current habit of saying "Discussion: ...". For bugs

Re: Inconsistent error handling in the openssl init code

On Wed, Feb 06, 2019 at 11:18:22PM +0100, Daniel Gustafsson wrote: > The errorhandling in be_tls_init(), and functions called from it, set the > appropriate elevel by the isServerStart. ssl_protocol_version_to_openssl() is > however erroring out unconditionally with ERROR on invalid TLS versions.

Re: bug tracking system

Alvaro Herrera writes: > On 2019-Feb-06, Tom Lane wrote: >> That will have caught exactly none of my own commits. > Well, what text do you use? I see "Per bug #XYZ" in the free-form text > of your commit messages, though that doesn't explicitly say that the bug > is fixed. If we agree that

Re: Documentation and code don't agree about partitioned table UPDATEs

On Wed, Feb 6, 2019 at 4:57 PM David Rowley wrote: > > On Wed, 6 Feb 2019 at 16:20, Amit Kapila wrote: > > I agree that the docs need to be updated and this patch should be > > backpatched as well. However, I think the older wording was more > > descriptive and clear, so I have modified your

Re: pg11.1: dsa_area could not attach to segment

On Thu, Feb 7, 2019 at 12:47 PM Justin Pryzby wrote: > However I *did* reproduce the error in an isolated, non-production postgres > instance. It's a total empty, untuned v11.1 initdb just for this, running > ONLY > a few simultaneous loops around just one query It looks like the simultaneous >

Re: Undo logs

On February 7, 2019 7:34:11 AM GMT+05:30, Michael Paquier wrote: >On Thu, Feb 07, 2019 at 07:25:57AM +0530, Andres Freund wrote: >> We now have the target version as a field, that should make such >> moves unnecessary, right? > >Oh, I missed this stuff. Thanks for pointing it out. It was

Re: Undo logs

On Thu, Feb 07, 2019 at 07:25:57AM +0530, Andres Freund wrote: > We now have the target version as a field, that should make such > moves unnecessary, right? Oh, I missed this stuff. Thanks for pointing it out. -- Michael signature.asc Description: PGP signature

Re: Internal error while setting reloption on system catalogs.

On Wed, Feb 06, 2019 at 09:09:32AM +0900, Kyotaro HORIGUCHI wrote: > At Tue, 05 Feb 2019 10:01:48 -0500, Tom Lane wrote in > <20605.1549378...@sss.pgh.pa.us> >> Isn't this more or less the same thing Peter E. was attempting to fix in >> https://commitfest.postgresql.org/22/1764/? > > Uggh

Re: Undo logs

On February 7, 2019 7:21:49 AM GMT+05:30, Michael Paquier wrote: >On Thu, Feb 07, 2019 at 03:21:09AM +1100, Thomas Munro wrote: >> Correct. Originally the target was 12 but that was a bit too >ambitious. > >Could it be possible to move the patch set into the first PG-13 commit >fest then?

Re: Undo logs

On Thu, Feb 07, 2019 at 03:21:09AM +1100, Thomas Munro wrote: > Correct. Originally the target was 12 but that was a bit too ambitious. Could it be possible to move the patch set into the first PG-13 commit fest then? We could use this CF as recipient for now, even if the schedule for next

RE: Timeout parameters

Hi Fabien, Would you review TCP_USER_TIMEOUT patches first please? I want to avoid the situation that the discussion of socket_timeout has been lengthened and tcp_user_timeout patch is also not commit in the next CF. On Mon, Feb 4, 2019 at 2:24 AM, Michael Paquier wrote: > Moved to next CF per

Re: pg11.1: dsa_area could not attach to segment

FYI, I wasn't yet able to make this work yet. (gdb) print *segment_map->header Cannot access memory at address 0x7f347e554000 However I *did* reproduce the error in an isolated, non-production postgres instance. It's a total empty, untuned v11.1 initdb just for this, running ONLY a few

Re: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote: > The obvious solution is to perform the same surgery for the ssl and > pg_rewind tests that we performed for genbki.pl and other scripts, but > in these cases the used modules are not in the same directory as the > using scripts, but

Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

These two files are used by TAP test suites but fall foul of the tightening of perl's searchpath rules. See for example The obvious solution is to perform the same surgery for the ssl and pg_rewind

Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;

On Wed, Feb 06, 2019 at 04:23:44PM +0100, Andreas Karlsson wrote: > I added a test in create_table.sql where the test for the other form of CTAS > IF NOT EXISTS is. Okay, we can live with that. Instead of a scan on pg_class, I would have switched to a more simple thing like that for the PREPARE

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

On Wed, Feb 06, 2019 at 03:41:20PM +0100, Daniel Gustafsson wrote: > Correct. One could argue that the regex is still suboptimal since “COMMENT ON > DATABASE postgres IS ;” will be matched as well, but there I think the > tradeoff > for readability wins. Okay, that looks like an improvement

Re: Commit Fest 2019-01 is now closed

On 2019-Feb-06, Magnus Hagander wrote: > This has now been pushed and is available. I've set it up with stable, 12 > and 13 as possible versions for now, but I have not added any tags to the > existing patches (except for one, in order to test it). I added a few more tags. Cool stuff, thanks!

RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Dear Ibrar Ahmed. From: Ibrar Ahmed [mailto:ibrar.ah...@gmail.com] Sent: Thursday, February 07, 2019 4:09 AM To: Moon, Insung Cc: Tom Lane; PostgreSQL-development Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) On Tue, Jul 3, 2018 at 5:37

Re: ALTER INDEX fails on partitioned index

On 2019-Jan-05, Justin Pryzby wrote: > 12dev and 11.1: > > postgres=# CREATE TABLE t(i int)PARTITION BY RANGE(i); > postgres=# CREATE INDEX ON t(i) WITH(fillfactor=11); > postgres=# ALTER INDEX t_i_idx SET (fillfactor=12); > ERROR: 42809: "t_i_idx" is not a table, view, materialized view, or

Re: bug tracking system

On 2019-Feb-06, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Feb-03, Nathan Wagner wrote: > >> I have used the regex /Fixes bug #([0-9]+)/ to automatically look for > >> commits purporting to fix bugs by number. > > > Let's use that. > > That will have caught exactly none of my own

Re: Too rigorous assert in reorderbuffer.c

On 2019-Feb-06, Arseny Sher wrote: > > Alvaro Herrera writes: > > > note the additional pg_temp_XYZ row in the middle. This is caused by > > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit > > 325f2ec55; I don't think there's much to do in the backbranches other > > than

Re: Feature: temporary materialized views

On Wed, Feb 06, 2019 at 05:05:56PM +0100, Andreas Karlsson wrote: > On 2/6/19 10:18 AM, Michael Paquier wrote: >> Attached is a patch to do that and close the gap. With that, we will >> be able to check for inconsistencies better when working on the >> follow-up patches. What do you think? > >

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

On 2/6/19 10:59 PM, David Rowley wrote: > On Thu, 7 Feb 2019 at 03:16, Alvaro Herrera wrote: >> I wonder what should we be doing with this series -- concretely, should >> the effort concentrate on one of the two patches, and leave the other >> for pg13, to increase the chances of the first one

performance issue in remove_from_unowned_list()

Hi, While working on benchmarks for the syscache patch (negative entries and all of that), I've ran into a an issue in remove_from_unowned_list. If you create a lot of relations in a single transaction (say, 100k) and then abort the transaction (or if it fails for some reason, e.g. because of

Re: dsa_allocate() faliure

Moving to -hackers, hopefully it doesn't confuse the list scripts too much. On Mon, Feb 04, 2019 at 08:52:17AM +0100, Jakub Glapa wrote: > I see the error showing up every night on 2 different servers. But it's a > bit of a heisenbug because If I go there now it won't be reproducible. Do you

Inconsistent error handling in the openssl init code

The errorhandling in be_tls_init(), and functions called from it, set the appropriate elevel by the isServerStart. ssl_protocol_version_to_openssl() is however erroring out unconditionally with ERROR on invalid TLS versions. The attached patch adds isServerStart handling to the TLS version

Re: Fix optimization of foreign-key on update actions

On 05/02/2019 17:20, Tom Lane wrote: > What I *don't* like about the proposed patch is that it installs a > new, different comparison rule for the ON UPDATE CASCADE case only. > If we were to go in this direction, I'd think we should try to use > the same comparison rule for all FK row

Re: Fix optimization of foreign-key on update actions

On 06/02/2019 12:23, Andrew Gierth wrote: > Two values which are sql-equal but not identical, such as two strings in > a case-insensitive collation that differ only by case, are > distinguishable in some contexts but not others, so what context > actually applies to the quoted rule? > > I think

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

On Thu, 7 Feb 2019 at 03:16, Alvaro Herrera wrote: > I wonder what should we be doing with this series -- concretely, should > the effort concentrate on one of the two patches, and leave the other > for pg13, to increase the chances of the first one being in pg12? I > would favor that approach,

Re: Commit Fest 2019-01 is now closed

> On 6 Feb 2019, at 21:47, Magnus Hagander wrote: > > On Wed, Feb 6, 2019 at 9:46 PM Daniel Gustafsson > wrote: > > On 6 Feb 2019, at 21:37, Daniel Gustafsson > > wrote: > > > >> On 6 Feb 2019, at 21:09, Magnus Hagander >>

Re: Commit Fest 2019-01 is now closed

On Wed, Feb 6, 2019 at 9:46 PM Daniel Gustafsson wrote: > > On 6 Feb 2019, at 21:37, Daniel Gustafsson wrote: > > > >> On 6 Feb 2019, at 21:09, Magnus Hagander wrote: > > > >> This has now been pushed and is available. I've set it up with stable, > 12 and 13 as possible versions for now, but I

Re: Commit Fest 2019-01 is now closed

> On 6 Feb 2019, at 21:37, Daniel Gustafsson wrote: > >> On 6 Feb 2019, at 21:09, Magnus Hagander wrote: > >> This has now been pushed and is available. I've set it up with stable, 12 >> and 13 as possible versions for now, but I have not added any tags to the >> existing patches (except for

Re: Commit Fest 2019-01 is now closed

On Wed, Feb 6, 2019 at 9:38 PM Daniel Gustafsson wrote: > > On 6 Feb 2019, at 21:09, Magnus Hagander wrote: > > > This has now been pushed and is available. I've set it up with stable, > 12 and 13 as possible versions for now, but I have not added any tags to > the existing patches (except for

Re: Commit Fest 2019-01 is now closed

> On 6 Feb 2019, at 21:09, Magnus Hagander wrote: > This has now been pushed and is available. I've set it up with stable, 12 and > 13 as possible versions for now, but I have not added any tags to the > existing patches (except for one, in order to test it). The patch has omitted the ending

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

hello ... we are actually planning to move this forward but we did not get around to actually sit down and do it. the thing is: we would really like to push this forward and we would certainly be happy if the community could reach a consenus on HOW TO implement it and what we really want. the

Re: Commit Fest 2019-01 is now closed

On Tue, Feb 5, 2019 at 6:08 PM Andres Freund wrote: > Hi, > > On 2019-02-05 11:55:37 -0500, Tom Lane wrote: > > Bruce Momjian writes: > > > On Mon, Feb 4, 2019 at 06:34:50AM +, Tsunakawa, Takayuki wrote: > > >> Wow, thank you so much for your hard work. The last CF for PG 12 > should be

Re: pg11.1: dsa_area could not attach to segment

> > It might be interesting to have CPU info, too. model name: Intel(R) Xeon(R) CPU E5-2637 v4 @ 3.50GHz (virtualized vmware) and model name: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz (bare metal) -- regards, pozdrawiam, Jakub Glapa On Wed, Feb 6, 2019 at 7:52 PM Justin Pryzby

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Tue, Jul 3, 2018 at 5:37 PM Moon, Insung wrote: > Dear Tom Lane. > > > -Original Message- > > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > > Sent: Monday, June 18, 2018 11:52 PM > > To: Robert Haas > > Cc: Joe Conway; Masahiko Sawada; Moon, Insung; PostgreSQL-development > > Subject:

Re: pg11.1: dsa_area could not attach to segment

On Wed, Feb 06, 2019 at 06:37:16PM +0100, Jakub Glapa wrote: > I'm seeing dsa_allocate on two different servers. > One is virtualized with VMWare the other is bare metal. Thanks. So it's not limited to vmware or VM at all. FYI here we've seen DSA errors on (and only on) two vmware VMs. It

Re: pg11.1: dsa_area could not attach to segment

Hi > Could you let us know which dsa_* error you were seeing, whether or not you > were running postgres under virtual environment, and (if so) which VM > hypervisor? System from my report is amazon virtual server. lscpu say: Hypervisor vendor: Xen Virtualization type: full regards,

Re: pg11.1: dsa_area could not attach to segment

Hi Justin I'm seeing dsa_allocate on two different servers. One is virtualized with VMWare the other is bare metal. ubuntu@db1:~$ grep dsa_allocate /var/log/postgresql/postgresql-11-main.log 2019-02-03 17:03:03 CET:192.168.10.83(48336):foo@bar:[27979]: FATAL: dsa_allocate could not find 7 free

Re: pg11.1: dsa_area could not attach to segment

On Wed, Feb 06, 2019 at 04:22:12PM +1100, Thomas Munro wrote: > Can anyone else who has hit this comment on any virtualisation they > might be using? I don't think most of these people are on -hackers (one of the original reports was on -performance) so I'm copying them now. Could you let us

Re: Synchronize with imath upstream

Hi, On 2019-02-06 10:15:24 -0500, Tom Lane wrote: > Andres Freund writes: > > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera > > wrote: > >> I'm -1 for this myself. I think there are a few places that could > >> benefit from it, but my fear is that many *more* places would get > >>

Re: Online verification of checksums

Greetings, * Michael Banck (michael.ba...@credativ.de) wrote: > Am Dienstag, den 05.02.2019, 11:30 +0100 schrieb Tomas Vondra: > > On 2/5/19 8:01 AM, Andres Freund wrote: > > > On 2019-02-05 06:57:06 +0100, Fabien COELHO wrote: > > > > > > > I'm wondering (possibly again) about the existing early

Re: Don't deform column-by-column in composite_to_json

Andres Freund writes: > On 2019-02-05 22:53:37 -0300, Alvaro Herrera wrote: >> Isn't this putting much more than needed in the stack? Seems like we >> could just allocate tupdesc->natts members dynamically. Not sure if we >> care: it's about 12 kB; maybe considering palloc overhead, using the

Re: Don't deform column-by-column in composite_to_json

On 2019-02-05 22:53:37 -0300, Alvaro Herrera wrote: > On 2019-Feb-01, Andres Freund wrote: > > > diff --git a/src/backend/utils/adt/json.c b/src/backend/utils/adt/json.c > > index de0d0723b71..8724022df54 100644 > > --- a/src/backend/utils/adt/json.c > > +++ b/src/backend/utils/adt/json.c > > @@

Re: PG_RE_THROW is mandatory (was Re: jsonpath)

Alvaro Herrera writes: > elog.h claims that PG_RE_THROW is "optional": > * (The braces are not actually necessary, but are recommended so that > * pgindent will indent the construct nicely.) The error recovery code > * can optionally do PG_RE_THROW() to propagate the same error outwards. >

Re: PG_RE_THROW is mandatory (was Re: jsonpath)

On 2019-02-06 13:09:59 -0300, Alvaro Herrera wrote: > In https://postgr.es/m/1676.1548726...@sss.pgh.pa.us Tom Lane wrote: > > > Sure: every errcode we have is unsafe to treat this way. > > > > The backend coding rule from day one has been that a thrown error requires > > (sub)transaction

Re: Bogus lateral-reference-propagation logic in create_lateral_join_info

Amit Langote writes: > On 2019/02/06 12:11, Tom Lane wrote: >> I didn't run this totally to bottom yet, but what seems to be >> happening is that inheritance_planner is creating a partition-specific >> subplan for the DELETE, and it's allowing AppendRelInfos from the >> parent query to propagate

Re: Undo logs

On Thu, Feb 7, 2019 at 1:16 AM Alvaro Herrera wrote: > On 2019-Feb-04, Thomas Munro wrote: > > On Mon, Feb 4, 2019 at 3:55 PM Michael Paquier wrote: > > > On Sun, Feb 03, 2019 at 02:23:16AM -0800, Andres Freund wrote: > > > > This thread is curently marked as returned with feedback, set so > > >

PG_RE_THROW is mandatory (was Re: jsonpath)

In https://postgr.es/m/1676.1548726...@sss.pgh.pa.us Tom Lane wrote: > Sure: every errcode we have is unsafe to treat this way. > > The backend coding rule from day one has been that a thrown error requires > (sub)transaction cleanup to be done to make sure that things are back in a > good

Re: Feature: temporary materialized views

On 2/6/19 10:18 AM, Michael Paquier wrote: Attached is a patch to do that and close the gap. With that, we will be able to check for inconsistencies better when working on the follow-up patches. What do you think? I approve. I was when testing this stuff that I found the IF NOT EXISTS

Re: Refactoring IndexPath representation of index conditions

Alvaro Herrera writes: > On 2019-Feb-02, Tom Lane wrote: >> Another idea that I looked into is to not create RestrictInfos for >> derived indexqual clauses, with the hope that that would further >> reduce the added overhead for the commuted-clause case. However >> that crashed and burned when I

Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;

On 2/6/19 12:49 PM, Michael Paquier wrote: A test case in select_into.sql would be nice. Should we back-patch that? It seems to me that this qualifies as a bug fix, and I don't see a reason to not support it knowing that we have the infrastructure for that. I added a test in create_table.sql

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

On Mon, Jan 04, 2019 at 03:06, Michael Paquier wrote: > On Thu, Dec 27, 2018 at 12:14:03PM +0100, Magnus Hagander wrote: >> I definitely am. In fact, I was ages ago (was planning for early December, >> but hey, see wher that let me), so my apologies for failing at that. But it >> definitely

Re: Synchronize with imath upstream

Andres Freund writes: > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera > wrote: >> I'm -1 for this myself. I think there are a few places that could >> benefit from it, but my fear is that many *more* places would get >> worse. > Because of imported code like ryu and imath? And

Re: bug tracking system

Alvaro Herrera writes: > On 2019-Feb-03, Nathan Wagner wrote: >> I have used the regex /Fixes bug #([0-9]+)/ to automatically look for >> commits purporting to fix bugs by number. > Let's use that. That will have caught exactly none of my own commits. regards, tom lane

Re: Is zheap on track for PostgreSQL 12.0?

Hopefully someone checked out this academic paper, as the perf gains seem impressive on the surface.. http://madsys.cs.tsinghua.edu.cn/publications/TS2018-liu.pdf DudeTx: Durable Transactions Made Decoupled "This paper presents DudeTx, a crash-consistent durable transaction system that avoids

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

> On 6 Feb 2019, at 12:37, Michael Paquier wrote: > > On Wed, Feb 06, 2019 at 10:50:27AM +0100, Daniel Gustafsson wrote: >> I still think we should enforce one-or-more matching on the OWNER part as >> well, >> since matching zero would be a syntax error. There are more .* matches but >>

Re: Synchronize with imath upstream

On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera wrote: >On 2019-Feb-03, David Fetter wrote: > >> On Sun, Feb 03, 2019 at 07:07:36AM +, Andrew Gierth wrote: >> > > "Noah" == Noah Misch writes: > >> > So far, expressed opinions have run about 4:2 in favour of allowing >> >

Re: bug tracking system

On 2019-Feb-03, Nathan Wagner wrote: > If the bug seemed to be either an actual bug or something that would > have actual work done, I marked these as open. It's entirely probable > that some or most of these are actually fixed. There were a number > of cases where committers emailed in a "will

Re: Don't deform column-by-column in composite_to_json

On 2019-Feb-01, Andres Freund wrote: > diff --git a/src/backend/utils/adt/json.c b/src/backend/utils/adt/json.c > index de0d0723b71..8724022df54 100644 > --- a/src/backend/utils/adt/json.c > +++ b/src/backend/utils/adt/json.c > @@ -1755,6 +1755,8 @@ composite_to_json(Datum composite, StringInfo

Re: Refactoring IndexPath representation of index conditions

On 2019-Feb-02, Tom Lane wrote: > In any case I think it makes things simpler and clearer, which is > worth a good deal. Looking at the patch, I agree -- this is clearer than what was there before. > Another idea that I looked into is to not create RestrictInfos for > derived indexqual clauses,

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

On 2019-Feb-04, Tomas Vondra wrote: > On 2/4/19 5:53 AM, Michael Paquier wrote: > > Moved the patch to next CF for now, waiting on author as the last > > review happened not so long ago. > > Thanks. Yes, I intend to send a new patch version soon. I wonder what should we be doing with this

Re: fast defaults in heap_getattr vs heap_deform_tuple

On 2019-Feb-05, Andres Freund wrote: > @@ -82,7 +80,7 @@ static Datum getmissingattr(TupleDesc tupleDesc, int > attnum, bool *isnull); > /* > * Return the missing value of an attribute, or NULL if there isn't one. > */ > -static Datum > +Datum > getmissingattr(TupleDesc tupleDesc, >

Re: Undo logs

On 2019-Feb-04, Thomas Munro wrote: > On Mon, Feb 4, 2019 at 3:55 PM Michael Paquier wrote: > > On Sun, Feb 03, 2019 at 02:23:16AM -0800, Andres Freund wrote: > > > This thread is curently marked as returned with feedback, set so > > > 2018-12-01. Given there've been several new versions

Re: Pluggable Storage - Andres's take

On Mon, 21 Jan 2019 at 08:31, Andres Freund wrote: > > Hi, > > (resending with compressed attachements, perhaps that'll go through) > > On 2018-12-10 18:13:40 -0800, Andres Freund wrote: > > On 2018-11-26 17:55:57 -0800, Andres Freund wrote: > > > FWIW, now that oids are removed, and the tuple

Re: fast defaults in heap_getattr vs heap_deform_tuple

> > Sorry I didn't spot this earlier, but... in the backpatch to v11, is the > > expansion of the trigger tuple really unnecessary now? Since > > heap_getattr is a macro, C-language triggers that aren't recompiled > > won't see the default? So perhaps the expansion should be left in? > >

Re: Add missing CREATE TABLE IF NOT EXISTS table_name AS EXECUTE query;

On Wed, Feb 06, 2019 at 03:20:41AM +0100, Andreas Karlsson wrote: > The first example below works while the second one is a syntax error despite > that the documentation > (https://www.postgresql.org/docs/11/sql-createtableas.html) makes it seem > like both should be valid. I do not see any reason

Re: fast defaults in heap_getattr vs heap_deform_tuple

Hi, On 2019-02-06 10:25:56 +, Andrew Gierth wrote: > > "Andres" == Andres Freund writes: > > >> Cool. Here's the patch that I, after some commit message polishing, > >> plan to commit to 11 and master to fix the issue at hand. > > Andres> And pushed. > > Sorry I didn't spot this

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

On Wed, Feb 06, 2019 at 10:50:27AM +0100, Daniel Gustafsson wrote: > I still think we should enforce one-or-more matching on the OWNER part as > well, > since matching zero would be a syntax error. There are more .* matches but > I’ve only touched the ones which match SQL, since there is a

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

On Wed, 6 Feb 2019 at 21:39, Michael Paquier wrote: > And done after checking the whole set. Thanks for pushing. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: Documentation and code don't agree about partitioned table UPDATEs

On Wed, 6 Feb 2019 at 16:20, Amit Kapila wrote: > I agree that the docs need to be updated and this patch should be > backpatched as well. However, I think the older wording was more > descriptive and clear, so I have modified your patch a bit to retain > part of old wording, see the result as

Re: Fix optimization of foreign-key on update actions

> "Laurenz" == Laurenz Albe writes: Laurenz> Andrew Gierth wrote: >> SQL2016, 15.17 Execution of referential actions >> >> 10) If a non-null value of a referenced column RC in the referenced >> table is updated to a value that is distinct from the current value >> of RC, then, >>

Re: fast defaults in heap_getattr vs heap_deform_tuple

> "Andres" == Andres Freund writes: >> Cool. Here's the patch that I, after some commit message polishing, >> plan to commit to 11 and master to fix the issue at hand. Andres> And pushed. Sorry I didn't spot this earlier, but... in the backpatch to v11, is the expansion of the trigger

Re: Add pg_partition_root to get top-most parent of a partition tree

On Wed, Feb 06, 2019 at 05:26:48PM +0900, Amit Langote wrote: > Some minor comments on v4: Thanks for the review. > +/* > + * Perform several checks on a relation on which is extracted some > + * information related to its partition tree. > > This is a bit unclear to me. How about: > > Checks

Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist

The patchset had a problem with all-zero pages, has appeared at index build stage: the generic_log_relation() routine sends all pages into the WAL. So lsn field at all-zero page was initialized and the PageIsVerified() routine detects it as a bad page. The solution may be: 1. To improve index

Re: Bogus lateral-reference-propagation logic in create_lateral_join_info

On 2019/02/06 12:11, Tom Lane wrote: > Yeah, I misspoke above, it's in partition_join not partition_prune, > specifically > > DELETE FROM prt1_l > WHERE EXISTS ( > SELECT 1 > FROM int4_tbl, > LATERAL (SELECT int4_tbl.f1 FROM int8_tbl LIMIT 2) ss > WHERE prt1_l.c IS NULL); > >

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

> On 6 Feb 2019, at 09:39, Michael Paquier wrote: > And done after checking the whole set. I still think we should enforce one-or-more matching on the OWNER part as well, since matching zero would be a syntax error. There are more .* matches but I’ve only touched the ones which match SQL,

Re: pg11.1: dsa_area could not attach to segment

On Wed, Feb 6, 2019 at 4:22 PM Thomas Munro wrote: > On Wed, Feb 6, 2019 at 1:10 PM Justin Pryzby wrote: > > This is a contrived query which I made up to try to exercise/stress bitmap > > scans based on Thomas's working hypothesis for this error/bug. This seems > > to > > be easier to hit than

Re: Too rigorous assert in reorderbuffer.c

Alvaro Herrera writes: > note the additional pg_temp_XYZ row in the middle. This is caused by > the rewrite in ALTER TABLE. Peter E fixed that in Pg11 in commit > 325f2ec55; I don't think there's much to do in the backbranches other > than hide the pesky record to avoid it breaking the test.

Re: Feature: temporary materialized views

On Tue, Feb 05, 2019 at 06:56:00PM +0100, Andreas Karlsson wrote: > I guess that I could fix that for the second case as soon as I understand > how much of the portal stuff can be skipped in ExecuteQuery(). But I am not > sure what we should do with EXPLAIN ANALYZE ... NO DATA. It feels like a >

Re: fast defaults in heap_getattr vs heap_deform_tuple

On 2019-02-05 08:57:05 -0800, Andres Freund wrote: > Hi, > > On 2019-02-05 10:14:48 -0500, Andrew Dunstan wrote: > > > > On 2/1/19 5:49 PM, Andres Freund wrote: > > > Hi, > > > > > > On 2019-02-01 08:24:04 -0800, Andres Freund wrote: > > > > > > Andrew, I think it'd be good to do a ground up

Re: Fix optimization of foreign-key on update actions

Andrew Gierth wrote: > SQL2016, 15.17 Execution of referential actions > > 10) If a non-null value of a referenced column RC in the referenced > table is updated to a value that is distinct from the current value > of RC, then, > > [snip all the stuff about how ON UPDATE actions

Re: Early WIP/PoC for inlining CTEs

On Sat, Feb 2, 2019 at 02:01:01PM -0500, Tom Lane wrote: > I wrote: > > I propose that we implement and document this as > > WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query ) > > which is maybe a bit clunky but not awful, and it would leave room > > to generalize it to "AS [ optionname

Re: Cache relation sizes?

On 2019-02-06 08:50:45 +, Jamison, Kirk wrote: > On February 6, 2019, 08:25AM +, Kyotaro HORIGUCHI wrote: > > >At Wed, 6 Feb 2019 06:29:15 +, "Tsunakawa, Takayuki" > > wrote: > >> Although I haven't looked deeply at Thomas's patch yet, there's currently > >> no place to store the

RE: Cache relation sizes?

On February 6, 2019, 08:25AM +, Kyotaro HORIGUCHI wrote: >At Wed, 6 Feb 2019 06:29:15 +, "Tsunakawa, Takayuki" > wrote: >> Although I haven't looked deeply at Thomas's patch yet, there's currently no >> place to store the size per relation in shared memory. You have to wait for >> the

Re: Protect syscache from bloating with negative cache entries

On 2019-02-06 17:37:04 +0900, Kyotaro HORIGUCHI wrote: > At Wed, 06 Feb 2019 15:16:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20190206.151653.117382256.horiguchi.kyot...@lab.ntt.co.jp> > > > The two should have the same extent of impact on performance when > > > disabled.

Re: Protect syscache from bloating with negative cache entries

At Wed, 06 Feb 2019 15:16:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190206.151653.117382256.horiguchi.kyot...@lab.ntt.co.jp> > > The two should have the same extent of impact on performance when > > disabled. I'll take numbers briefly using pgbench. (pgbench -j 10 -c 10 -T

Re: Tighten up a few overly lax regexes in pg_dump's tap tests

On Tue, Feb 05, 2019 at 04:26:18PM +0900, Michael Paquier wrote: > On Tue, Feb 05, 2019 at 05:46:55PM +1300, David Rowley wrote: >> I did leave a couple untouched as there was quite a bit of escaping >> going on already. I didn't think switching between \Q and \E would >> have made those ones any

  1   2   >