Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

> On 22 Sep 2017, at 18:57, Melanie Plageman wrote: > > On Tue, Sep 19, 2017 at 4:15 PM, Melanie Plageman > wrote: > The latest patch applies cleanly and builds (I am also seeing the failing TAP > tests), however, I have a concern. With a single server set up,

Re: [HACKERS] document and use SPI_result_code_string()

> On 06 Sep 2017, at 14:25, Tom Lane wrote: > > Michael Paquier writes: >> Fine for 0002. This reminds me of LockGXact and RemoveGXact in >> twophase.c, as well as _hash_squeezebucket that have some code paths >> that cannot return... Any thoughts about having some kind of >> PG_NOTREACHED defin

Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

> On 29 Aug 2017, at 17:21, Robert Haas wrote: > > On Tue, Aug 22, 2017 at 2:23 AM, Simon Riggs wrote: >> Yes, we can. I'm not sure why you would do this only for VACUUM >> though? I see many messages in various places that need same treatment > > I'm skeptical about the idea of doing this too

Re: [HACKERS] [PATCH] Improve geometric types

Hello. Thank you for the new version. 0001: applies cleanly. regress passed. this mainly refactoring geo_ops.c and replacing pg_hypot with hypot(3). 0002: applies cleanly. regress passed. this just replaces float-ops macros into inline functions. 0003: applies cleanly. regress passed.

Re: [HACKERS] Parallel COPY FROM execution

> On 11 Aug 2017, at 20:07, Robert Haas wrote: > > On Fri, Aug 11, 2017 at 9:55 AM, Alex K wrote: >> - I have used both Latch and ConditionalVariable for the same >> purpose–wait until some signal >> occurs–and for me as an end user they perform quite similar. I >> looked into the condition_var

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

> On 13 Sep 2017, at 07:44, Vaishnavi Prabakaran > wrote: > > On Wed, Sep 13, 2017 at 3:33 PM, Craig Ringer > wrote: > > I really do not like calling it "commit" as that conflates with a database > commit. > > A batch can embed multiple BEGINs and COMMITs. It's

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

> On 28 Jul 2017, at 16:46, Robert Haas wrote: > > On Fri, Jul 28, 2017 at 12:39 AM, Pavan Deolasee > wrote: >> I see your point. But I would like to think this way: does the technology >> significantly help many common use cases, that are currently not addressed >> by HOT? It probably won't hel

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

> On 20 Sep 2017, at 00:29, Jacob Champion wrote: > > On Wed, Sep 6, 2017 at 8:37 AM, Jacob Champion wrote: >> On Tue, Sep 5, 2017 at 10:49 PM, Michael Paquier >> wrote: >>> In short, it seems to me that this patch should be rejected in its >>> current shape. >> >> Is the half of the patch tha

Re: [HACKERS] Making clausesel.c Smarter

> On 07 Sep 2017, at 09:30, Daniel Gustafsson wrote: > >> On 06 Sep 2017, at 07:13, David Rowley wrote: >> >> On 6 September 2017 at 00:43, Daniel Gustafsson wrote: >>> This patch was moved to the currently open Commitfest. Given the above >>> comment, is the last patch in this thread still u

Re: [HACKERS] Hooks to track changed pages for backup purposes

> On 13 Sep 2017, at 15:01, Tomas Vondra wrote: > > On 09/13/2017 07:53 AM, Andrey Borodin wrote: >>> * I see there are conditions like this: >>> >>>if(xlogreader->blocks[nblock].forknum == MAIN_FORKNUM) >>> >>> Why is it enough to restrict the block-tracking code to main fork? >>> Aren't w

Re: [HACKERS] Transactions involving multiple postgres foreign servers

> On 02 Oct 2017, at 08:31, Masahiko Sawada wrote: > > On Sat, Sep 30, 2017 at 12:42 AM, Robert Haas wrote: >> On Wed, Sep 27, 2017 at 11:15 PM, Masahiko Sawada >> wrote: >>> I think that making a resolver process have connection caches to each >>> foreign server for a while can reduce the ove

Re: [HACKERS] GSoC 2017: weekly progress reports (week 8)

> On 29 Sep 2017, at 00:59, Alexander Korotkov > wrote: > > On Thu, Sep 28, 2017 at 2:22 PM, Alexander Korotkov > mailto:a.korot...@postgrespro.ru>> wrote: > On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai > wrote: > I am attaching a patch for predicate locking

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi, thanks for the new patch. # The patch is missing xpath_parser.h. That of the first patch was usable. At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule wrote in > Hi > > now xpath and xpath_exists supports default namespace too At Wed, 27 Sep 2017 22:41:52 +0200, Pavel Stehule wrote in

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

2017-10-02 12:22 GMT+02:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Hi, thanks for the new patch. > > # The patch is missing xpath_parser.h. That of the first patch was usable. > > At Thu, 28 Sep 2017 07:59:41 +0200, Pavel Stehule > wrote in mail.gmail.com> > > Hi > > > > now xpat

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

> On 15 Sep 2017, at 16:36, Bossart, Nathan wrote: > > A few general comments. > > While this patch applies, I am still seeing some whitespace errors: > > comment_on_current_database_no_pgdump_v4.1.patch:488: trailing whitespace. > ColId > comment_on_current_database_no_

Re: [HACKERS] generated columns

> On 12 Sep 2017, at 21:35, Jaime Casanova > wrote: > > On 10 September 2017 at 00:08, Jaime Casanova > wrote: >> >> During my own tests, though, i found some problems: > > a few more tests: > > create table t1 ( > id serial, > height_cm int, > height_in int generated always as (height_cm *

Re: [HACKERS] path toward faster partition pruning

On Sun, Oct 1, 2017 at 9:13 PM, Amit Langote wrote: > I agree. Equality checks are going to be common enough to warrant them to > be handled specially, instead of implementing equality-pruning on top of > min/max framework. What you might do is pass and optionally allow a second . Then for the

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Mon, Sep 4, 2017 at 2:14 AM, Michael Paquier wrote: A>> that would trip it. The latter part is still in progress, because I'm > Well, PageGetLSN can be used in some hot code paths, xloginsert.c > being one, so it does not seem wise to me to switch it to something > more complicated than a macro

Re: [HACKERS] [PATCH] Improve geometric types

On Mon, Oct 2, 2017 at 4:23 AM, Kyotaro HORIGUCHI wrote: > For other potential reviewers: > > I found the origin of the function here. > > https://www.postgresql.org/message-id/4a90bd76.7070...@netspace.net.au > https://www.postgresql.org/message-id/AANLkTim4cHELcGPf5w7Zd43_dQi_2RJ_b5_F_idSSbZI%40

Re: [HACKERS] Fix number skipping in to_number

> On 25 Sep 2017, at 02:52, Nathan Wagner wrote: > > On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote: > >> Ok I've made that change in the attached v3. I'm not sure as I'm on >> en_US.UTF-8 locale too. Maybe something Windows specific? > > This patch applies against master (8485a25a

Re: [HACKERS] Add support for tuple routing to foreign partitions

Hi Fujita-san! On 11.09.2017 16:01, Etsuro Fujita wrote: Here is an updated version of the patch. * Query planning: the patch creates copies of Query/Plan with a foreign partition as target from the original Query/Plan for each foreign partition and invokes PlanForeignModify with those copie

Re: [HACKERS][BUG] Cache invalidation for queries that contains const of temporary composite type

On 26.09.2017 23:25, Maksim Milyutin wrote: 25.09.17 20:50, Maksim Milyutin wrote: I have found out the problem when try to sequentially call the function that casts constant to composite type of temporary table that is deleted ateach transaction termination (i.e. at each function call compl

Re: [HACKERS] Parallel Append implementation

On Sun, Oct 1, 2017 at 9:55 AM, Amit Kapila wrote: > Isn't it for both? I mean it is about comparing the non-partial paths > for child relations of the same relation and also when there are > different relations involved as in Union All kind of query. In any > case, the point I was trying to say

Re: [HACKERS] CLUSTER command progress monitor

On Tue, Sep 12, 2017 at 8:20 AM, Tatsuro Yamada wrote: >>> I agree that progress reporting for sort is difficult. So it only reports >>> the phase ("sorting tuples") in the current design of progress monitor of >>> cluster. >>> It doesn't report counter of sort. >> >> Doesn't that make it almost u

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On Sep 28, 2017 4:30 PM, "Alexander Korotkov" wrote: Hi! On Wed, Jun 21, 2017 at 10:52 AM, Shubham Barai wrote: > Hi, > > On 21 June 2017 at 13:11, Heikki Linnakangas wrote: > >> On 06/16/2017 01:24 PM, Shubham Barai wrote: >> >>> @@ -497,6 +499,13 @@ gistplacetopage(Relation rel, Size freesp

Re: [HACKERS] 64-bit queryId?

On Mon, Oct 2, 2017 at 1:22 AM, Robert Haas wrote: > On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark wrote: > > Well these kinds of monitoring systems tend to be used by operations > > people who are a lot more practical and a lot less worried about > > theoretical concerns like that. > > +1, well sa

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Hi, Alexander! Thanks for looking into the patch! On Thu, Sep 28, 2017 at 3:59 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > > In gistdoinsert() you do CheckForSerializableConflictIn() only if page > wasn't exclusively locked before (xlocked is false). > > if (!xlocked) >> { >>

Re: [HACKERS] Fwd: Have a problem with citext

On Oct 1, 2017, at 20:22, Robert Haas wrote: >> Are permissions correct in the citext extension? > > Not to be picky, but couldn't you investigate that a bit before posting here? Normally I would, but my attention is far from Postgres these days, sadly, and I tend to think of citext (IT’S NOT

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Sun, Oct 1, 2017 at 8:36 PM, Daniel Gustafsson wrote: >> On 18 Aug 2017, at 13:39, Claudio Freire wrote: >> >> On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire >> wrote: >>> Indeed they do, and that's what motivated this patch. But I'd need >>> TB-sized tables to set up something like that. I

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Mon, Oct 2, 2017 at 9:09 PM, Robert Haas wrote: > I think the first question we ought to be asking ourselves is whether > any of the PageGetLSN -> BufferGetLSNAtomic changes the patch > introduces are live bugs. If they are, then we ought to fix those > separately (and probably back-patch). I

Re: [HACKERS] parallelize queries containing initplans

On Thu, Sep 14, 2017 at 10:45 PM, Amit Kapila wrote: > The latest patch again needs to be rebased. Find rebased patch > attached with this email. I read through this patch this morning. Copying Tom in the hopes that he might chime in on the following two issues in particular: 1. Is there any

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Mon, Oct 2, 2017 at 10:19 AM, Michael Paquier wrote: > So those bits could be considered for integration. Yes, and they also tend to suggest that the rest of the patch has value. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-h

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Hi, Andrew! On Mon, Oct 2, 2017 at 1:40 PM, Andrew Borodin wrote: > Thanks for looking into the patch! > > On Thu, Sep 28, 2017 at 3:59 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> >> >> In gistdoinsert() you do CheckForSerializableConflictIn() only if page >> wasn't exclusi

Re: [HACKERS] Logging idle checkpoints

Vik, all, * Vik Fearing (vik.fear...@2ndquadrant.com) wrote: > I recently had a sad because I noticed that checkpoint counts were > increasing in pg_stat_bgwriter, but weren't accounted for in my logs > with log_checkpoints enabled. > After some searching, I found that it was the idle checkpoints

Re: [HACKERS] 64-bit queryId?

On 10/01/2017 04:22 PM, Robert Haas wrote: On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark wrote: Well these kinds of monitoring systems tend to be used by operations people who are a lot more practical and a lot less worried about theoretical concerns like that. +1, well said. In context the po

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Mon, Oct 2, 2017 at 11:44 PM, Robert Haas wrote: > On Mon, Oct 2, 2017 at 10:19 AM, Michael Paquier > wrote: >> So those bits could be considered for integration. > > Yes, and they also tend to suggest that the rest of the patch has value. Well, there are cases where you don't need any lockin

Re: [HACKERS] generated columns

On Thu, Aug 31, 2017 at 12:16:43AM -0400, Peter Eisentraut wrote: > In previous discussions, it has often been a source of confusion whether > these generated columns are supposed to be computed on insert/update and > stored, or computed when read. The SQL standard is not explicit, but > appears t

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On Sun, Oct 1, 2017 at 8:27 PM, chenhj wrote: > On 2017-10-01 04:09:19,"Alexander Korotkov" > wrote: > > On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote: > >> On 2017-09-30 02:17:54，"Alexander Korotkov" > > wrote: >> >> >> Great. Now code of this patch looks good for me. >> However, we forgot a

[HACKERS] Commitfest 201709 is now closed

We have now entered October, which marks the end of Commitfest 201709. All patches have now been dealt with and the commitfest is closed. Before starting on moving, and closing, patches the stat for this commitfest were: Needs review: 69. Waiting on Author: 22. Ready for

[HACKERS] Issues with logical replication

I have faced two issues with logical replication. Reproducing scenario: 1. start two Postgres instances (I start both at local machine). 2. Initialize pgbench tables at both instances: pgbench -i -s 10 postgres 3. Create publication of pgbench_accounts table at one node: create publicatio

[HACKERS] Horrible CREATE DATABASE Performance in High Sierra

I just recently "upgraded" to High Sierra and experiencing horrendous CREATE DATABASE performance. Creating a database from a 3G template DB used to take ~1m but post-upgrade is taking ~22m at a sustained write of around 4MB/s. Occasionally, attempting to create an empty database hangs indefinitely

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

Michael Paquier wrote: > On Mon, Oct 2, 2017 at 11:44 PM, Robert Haas wrote: > > On Mon, Oct 2, 2017 at 10:19 AM, Michael Paquier > > wrote: > >> So those bits could be considered for integration. > > > > Yes, and they also tend to suggest that the rest of the patch has value. > > Well, there ar

Re: [HACKERS] Commitfest 201709 is now closed

Daniel Gustafsson writes: > Thanks to everyone who participated, and to everyone who have responded to my > nagging via the CF app email function. This is clearly an awesome community. And thanks to you for your hard work as CFM! That's tedious and largely thankless work, but it's needed to keep

Re: [HACKERS] 64-bit queryId?

On Mon, Oct 2, 2017 at 11:02 AM, Joshua D. Drake wrote: > +1 to both of these as well. OK, so here's a patch. Review appreciated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company 64-bit-queryid-v1.patch Description: Binary data -- Sent via pgsql-ha

Re: [HACKERS] Commitfest 201709 is now closed

On Mon, Oct 2, 2017 at 11:57 AM, Tom Lane wrote: > Daniel Gustafsson writes: >> Thanks to everyone who participated, and to everyone who have responded to my >> nagging via the CF app email function. This is clearly an awesome community. > > And thanks to you for your hard work as CFM! That's te

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Mon, Oct 2, 2017 at 11:05 AM, Michael Paquier wrote: > Well, there are cases where you don't need any locking checks, and the > proposed patch ignores that. I understand that, but shouldn't we then look for a way to adjust the patch so that it doesn't have that issue any longer, rather than ju

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-10-02 23:24:30，"Alexander Korotkov" wrote: On Sun, Oct 1, 2017 at 8:27 PM, chenhj wrote: Now, this patch looks good for me. It applies cleanly, builds cleanly, passes regression tests, new functionality is covered by regression tests. Code is OK for me and docs too. I'm markin

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane wrote: > Robert Haas writes: >> I think the fact that single-target INTO lists and multiple-target >> INTO lists are handled completely differently is extremely poor >> language design. It would have been far better, as you suggested >> downthread, to ha

Re: [HACKERS] Commitfest 201709 is now closed

On Mon, Oct 2, 2017 at 6:57 PM, Tom Lane wrote: > Daniel Gustafsson writes: > > Thanks to everyone who participated, and to everyone who have responded > to my > > nagging via the CF app email function. This is clearly an awesome > community. > > And thanks to you for your hard work as CFM! Tha

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

Robert Haas writes: > On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane wrote: >> That's certainly a case that we ought to support somehow. The problem is >> staying reasonably consistent with the two-decades-old precedent of the >> existing behavior for one target variable. > My point is that you obje

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Fri, Sep 15, 2017 at 6:29 PM, Michael Paquier wrote: > I would like to point out that per the RFC, if the client attempts a > SSL connection with SCRAM and that the server supports channel > binding, then it has to publish the SASL mechanism for channel > binding, aka SCRAM-PLUS. If the client

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane wrote: >>> That's certainly a case that we ought to support somehow. The problem is >>> staying reasonably consistent with the two-decades-old precedent of the >>> existing behavi

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 10/1/17 14:26, Peter Geoghegan wrote: > It does seem too late. It's disappointing that we did not do better > here. This problem was entirely avoidable. I understand where you are coming from. My experience with developing this feature has been that it is quite fragile in some ways. We have h

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

Robert Haas writes: > On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane wrote: >> I'm not sure if that's true or not. I am sure, though, that since >> we've done B for twenty years we can't just summarily change to A. > I agree, but so what? You said that we couldn't adopt Pavel's > proposal for this

Re: [HACKERS] generated columns

I know that for my use-cases, having both options available would be very appreciated. The vast majority of the computed columns I would use in my database would be okay to compute on read. But there are for sure some which would be performance prohibitive to have compute on read, so i'd rather h

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

On Sun, Oct 1, 2017 at 11:53 AM, Shubham Barai wrote: > Yes, page-level predicate locking should happen only when fast update is > off. > Actually, I forgot to put conditions in updated patch. Does everything > else look ok ? > I think that isolation tests should be improved. It doesn't seems t

Re: [HACKERS] Issues with logical replication

On 02/10/17 17:49, Konstantin Knizhnik wrote: > I have faced two issues with logical replication. > Reproducing scenario: > > 1. start two Postgres instances (I start both at local machine). > 2. Initialize pgbench tables at both instances: >     pgbench -i -s 10 postgres > 3. Create publication o

Re: [HACKERS][BUG] Cache invalidation for queries that contains const of temporary composite type

On Mon, Oct 2, 2017 at 3:43 PM, Maksim Milyutin wrote: > On 26.09.2017 23:25, Maksim Milyutin wrote: > > Updated patchset contains more transparent definition of composite type > for constant node and regression test for described above buggy case. > > Is there any interest on the problem in this

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

2017-10-02 18:44 GMT+02:00 Tom Lane : > Robert Haas writes: > > On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane wrote: > >> I'm not sure if that's true or not. I am sure, though, that since > >> we've done B for twenty years we can't just summarily change to A. > > > I agree, but so what? You said t

[HACKERS] Issues with logical replication

I have faced two issues with logical replication. Repro scenario: 1. start two Postgres instances (I start both at local machine). 2. Initialize pgbench tables at both instances: pgbench -i -s 10 postgres 3. Create publication of pgbench_accounts table at one node: create publication pub

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Mon, Oct 2, 2017 at 9:42 AM, Peter Eisentraut wrote: > I understand where you are coming from. My experience with developing > this feature has been that it is quite fragile in some ways. We have > had this out there for testing for many months, and we have fixed many > bugs, and follow-up bu

Re: [HACKERS] list of credits for release notes

On Fri, Sep 29, 2017 at 12:00:05PM -0400, Peter Eisentraut wrote: > On 9/29/17 11:35, Robert Haas wrote: > > On Wed, Sep 27, 2017 at 8:29 PM, Michael Paquier > > wrote: > >> Looking at this list, the first name is followed by the family name, > >> so there are inconsistencies with some Japanese na

Re: [HACKERS] generated columns

On Mon, Oct 02, 2017 at 12:50:14PM -0400, Adam Brusselback wrote: > I know that for my use-cases, having both options available would be very > appreciated. The vast majority of the computed columns I would use in my > database would be okay to compute on read. But there are for sure some > which

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov wrote: > What happen if exactly this "continue" fires? > >> if (GistFollowRight(stack->page)) >> { >> if (!xlocked) >> { >> LockBuffer(stack->buffer, GIST_UNLOCK); >> LockBuffer(stack->buffer, GIST_EXCLUSIVE); >> xlocked = true; >> /* someone migh

Re: [HACKERS] list of credits for release notes

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Fri, Sep 29, 2017 at 12:00:05PM -0400, Peter Eisentraut wrote: > > On 9/29/17 11:35, Robert Haas wrote: > > > On Wed, Sep 27, 2017 at 8:29 PM, Michael Paquier > > > wrote: > > >> Looking at this list, the first name is followed by the family n

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Brent Dearth writes: > I just recently "upgraded" to High Sierra and experiencing horrendous CREATE > DATABASE performance. Creating a database from a 3G template DB used to > take ~1m but post-upgrade is taking ~22m at a sustained write of around > 4MB/s. Occasionally, attempting to create an emp

Re: [HACKERS] generated columns

Nico Williams writes: > On Mon, Oct 02, 2017 at 12:50:14PM -0400, Adam Brusselback wrote: >> So for me, i'd rather default to compute on read, as long storing the >> pre-computed value is an option when necessary. > Sure, I agree. I was just wondering whether there might be any other > differenc

Re: [HACKERS] generated columns

On Mon, Oct 02, 2017 at 02:30:38PM -0400, Tom Lane wrote: > Nico Williams writes: > > On Mon, Oct 02, 2017 at 12:50:14PM -0400, Adam Brusselback wrote: > >> So for me, i'd rather default to compute on read, as long storing the > >> pre-computed value is an option when necessary. > > > Sure, I agr

Re: [HACKERS] generated columns

On Mon, Oct 02, 2017 at 02:30:38PM -0400, Tom Lane wrote: > Nico Williams writes: > > On Mon, Oct 02, 2017 at 12:50:14PM -0400, Adam Brusselback wrote: > >> So for me, i'd rather default to compute on read, as long storing the > >> pre-computed value is an option when necessary. > > > Sure, I agr

Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

On Mon, Oct 2, 2017 at 9:11 PM, Andrew Borodin wrote: > On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov > wrote: > > What happen if exactly this "continue" fires? > > > >> if (GistFollowRight(stack->page)) > >> { > >> if (!xlocked) > >> { > >> LockBuffer(stack->buffer, GIST_UNLOCK); > >> Lock

Re: [HACKERS] generated columns

So yes, distinguishing stored vs. not stored computed columns is useful, especially if the expression can refer to other columns of the same row, though not only then. Examples: -- useful only if stored (assuming these never get updated) inserted_at TIMESTAMP WITHOUT TIME ZONE AS (clo

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

I wrote: > In short, therefore, APFS cannot cope with the way we're using msync(). I experimented with this further by seeing whether the msync() code path is of any value on Sierra either. The answer seems to be "no": cloning a scale-1000 pgbench database takes about 17-18 seconds on my Sierra l

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

On Mon, Oct 2, 2017 at 12:44 PM, Tom Lane wrote: >> And I'm saying - that argument is bogus. Regardless of what people >> want or what we have historically done in the case where the >> record/row is the only INTO target, when there are multiple targets it >> seems clear that they want to match u

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Thanks for this breakdown Tom! FWIW - I'm on Postgres 9.6.5 as bundled with Postgres.app (2.0.5) running on 2013 MBP (2.7GHz i7 / 16GB / SSD) setup. It looks like this might be a priority for an upcoming release, so I might try to hold out for downstream, but thanks for the patch. It will help if

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On 2017-10-02 15:42:25 -0400, Tom Lane wrote: > I wrote: > > In short, therefore, APFS cannot cope with the way we're using msync(). > > I experimented with this further by seeing whether the msync() code path > is of any value on Sierra either. The answer seems to be "no": cloning > a scale-1000

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Andres Freund writes: > On 2017-10-02 15:42:25 -0400, Tom Lane wrote: >> I experimented with this further by seeing whether the msync() code path >> is of any value on Sierra either. The answer seems to be "no": cloning >> a scale-1000 pgbench database takes about 17-18 seconds on my Sierra >> la

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On 2017-10-02 15:54:43 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-02 15:42:25 -0400, Tom Lane wrote: > >> I experimented with this further by seeing whether the msync() code path > >> is of any value on Sierra either. The answer seems to be "no": cloning > >> a scale-1000 pgben

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Andres Freund writes: > On 2017-10-02 15:54:43 -0400, Tom Lane wrote: >> Should I expect there to be any difference at all? We don't enable >> *_flush_after by default on non-Linux platforms. > Right, you'd have to enable that. But your patch would neuter an > intentionally enabled config too, n

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

On 2017-10-02 15:59:05 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-02 15:54:43 -0400, Tom Lane wrote: > >> Should I expect there to be any difference at all? We don't enable > >> *_flush_after by default on non-Linux platforms. > > > Right, you'd have to enable that. But your p

Re: [HACKERS] 64-bit queryId?

On 03/10/17 04:02, Joshua D. Drake wrote: On 10/01/2017 04:22 PM, Robert Haas wrote: On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark wrote: Well these kinds of monitoring systems tend to be used by operations people who are a lot more practical and a lot less worried about theoretical concerns like

[HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

Hi, low-memory testing with REL_10_STABLE at 1f19550a87 produced the following PANIC: stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397 I was about to wrap the pstrdup()s with a PG_TRY block, but I can't find a spinlock being released in a PG_CATCH block anywhere, so ma

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

On Tue, Oct 3, 2017 at 9:56 AM, Andreas Seltenreich wrote: > low-memory testing with REL_10_STABLE at 1f19550a87 produced the > following PANIC: > > stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397 > > I was about to wrap the pstrdup()s with a PG_TRY block, but I can't f

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

On 2017-10-02 22:56:49 +0200, Andreas Seltenreich wrote: > Hi, > > low-memory testing with REL_10_STABLE at 1f19550a87 produced the > following PANIC: > > stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397 Ugh. > I was about to wrap the pstrdup()s with a PG_TRY block, b

Re: [HACKERS] list of credits for release notes

> On Wed, Sep 27, 2017 at 8:29 PM, Michael Paquier > wrote: >> Looking at this list, the first name is followed by the family name, >> so there are inconsistencies with some Japanese names: >> - Fujii Masao should be Masao Fujii. >> - KaiGai Kohei should be Kohei Kaigai. > > But his emails say Fu

Re: [HACKERS] 64-bit queryId?

On Mon, Oct 2, 2017 at 9:10 AM, Robert Haas wrote: > On Mon, Oct 2, 2017 at 11:02 AM, Joshua D. Drake > wrote: >> +1 to both of these as well. > > OK, so here's a patch. Review appreciated. You need to change the SQL interface as well, although I'm not sure exactly how. The problem is that you

Re: [HACKERS][BUG] Cache invalidation for queries that contains const of temporary composite type

Hi, Alexander! Thanks for the comments. 02.10.17 20:02, Alexander Korotkov wrote: Please, register this patch at upcoming commitfest to ensure it wouldn't be forgotten. Regression test changes (both .sql and .out) are essential parts of the patch.  I see no point in posting them separately. 

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

Andres Freund writes: > On 2017-10-02 22:56:49 +0200, Andreas Seltenreich wrote: >> low-memory testing with REL_10_STABLE at 1f19550a87 produced the >> following PANIC: >> stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397 > Ugh. Egad. > Yes, that'd be a bad idea. It's not

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

On 2017-10-02 17:30:25 -0400, Tom Lane wrote: > Andres Freund writes: > > Yes, that'd be a bad idea. It's not great to have memcpys in a critical > > section, but it's way better than pallocs. So we need to use some local > > buffers that this get copied to. > > Or replace the spinlock with an LW

Re: [HACKERS] 64-bit queryId?

Peter Geoghegan writes: > You need to change the SQL interface as well, although I'm not sure > exactly how. The problem is that you are now passing a uint64 queryId > to Int64GetDatumFast() within pg_stat_statements_internal(). That > worked when queryId was a uint32, because you can easily repre

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

Andres Freund writes: > On 2017-10-02 17:30:25 -0400, Tom Lane wrote: >> Or replace the spinlock with an LWLock? > That'd probably be a good idea, but I'm loathe to do so in the back > branches. Not at this callsite, but some others, there's some potential > for contention. If this is the only p

[HACKERS] [sqlsmith] crash in RestoreLibraryState during low-memory testing

Hi, doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced a couple of parallel worker core dumps with the backtrace below. Although most of the backtrace is inside the dynamic linker, it looks like it was passed a pointer to gone-away shared memory. regards, Andreas Core was ge

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-09-28 19:06:27 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-28 18:52:28 -0400, Tom Lane wrote: > >> Uh, what? Access to fmgr_nbuiltins shouldn't be part of any critical path > >> anymore after this change. > > > Indeed. But the size of the the oid -> fmgr_builtins index

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

I wrote: > If this is the only problem then I'd agree we should stick to a spinlock > (I assume the strings in question can't be very long). I was thinking > more about what to do if we find other violations that are harder to fix. I took a quick look through walreceiver.c, and there are a couple

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

Andres Freund writes: > Done that way. It's a bit annoying, because we've to take care to > initialize the "unused" part of the array with a valid signalling it's > an unused mapping. Can't use 0 for that because fmgr_builtins[0] is a > valid entry. The prototype code I posted further upthread ju

Re: [HACKERS] Binary search in fmgr_isbuiltin() is a bottleneck.

On 2017-10-02 17:57:51 -0400, Tom Lane wrote: > Andres Freund writes: > > Done that way. It's a bit annoying, because we've to take care to > > initialize the "unused" part of the array with a valid signalling it's > > an unused mapping. Can't use 0 for that because fmgr_builtins[0] is a > > valid

Re: [HACKERS] Commitfest 201709 is now closed

On Tue, Oct 3, 2017 at 1:23 AM, Alexander Korotkov wrote: > On Mon, Oct 2, 2017 at 6:57 PM, Tom Lane wrote: >> >> Daniel Gustafsson writes: >> > Thanks to everyone who participated, and to everyone who have responded >> > to my >> > nagging via the CF app email function. This is clearly an aweso

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Andres Freund writes: > To demonstrate what I'm observing here, on linux with a fairly fast ssd: > ... I tried to replicate this test as closely as I could on the Mac hardware I have laying about. I only bothered with the synchronous_commit=off case, though, since you say that shows the worst ef

Re: [HACKERS] list of credits for release notes

On Mon, Oct 2, 2017 at 02:12:50PM -0400, Stephen Frost wrote: > > How should this be handled for the Postgres 11 release notes? > > Ideally, we would let the individuals choose how to be recognized in > release notes, and anywhere else we recognize them. We have the start > of that in https://po

Re: [HACKERS] Horrible CREATE DATABASE Performance in High Sierra

Hi, On 2017-10-02 18:33:17 -0400, Tom Lane wrote: > Andres Freund writes: > > To demonstrate what I'm observing here, on linux with a fairly fast ssd: > > ... > > I tried to replicate this test as closely as I could on the Mac hardware > I have laying about. Thanks! > I only bothered with the

Re: [HACKERS][BUG] Cache invalidation for queries that contains const of temporary composite type

On Tue, Oct 3, 2017 at 12:20 AM, Maksim Milyutin wrote: > I have tested the following case: > > create type pair as (x int, y int); > prepare test as select json_populate_record(null::pair, '{"x": 1, "y": > 2}'::json); > drop type pair cascade; > > execute test; > > -- The following output is obt

  1   2   >