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] [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,

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

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

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

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 >

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

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

[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

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.

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

[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

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

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

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

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

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

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

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

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

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

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 ->

Re: [HACKERS] Commitfest 201709 is now closed

On 2017/10/03 7:16, Michael Paquier wrote: > 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,

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

On Tue, Oct 3, 2017 at 8:31 AM, Amit Kapila wrote: > On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich > wrote: >> Hi, >> >> doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced >> a couple of parallel worker core dumps with the

Re: [HACKERS] PoC: full merge join on comparison clause

On Thu, Sep 28, 2017 at 8:57 PM, Alexander Kuzmenkov wrote: > Hi Ashutosh, > > Thanks for the review. > > Jeff, I'm copying you because this is relevant to our discussion about what > to do with mergeopfamilies when adding new merge join types. > > You have renamed

Re: [HACKERS] Conversion error

Tatsuo Ishii writes: > I saw this while restoring 9.6 database to 10.0 database. > \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported > Is this expected? I saw nothing releated to this in the release notes. Don't think that's ever been supported.

Re: [HACKERS] Possible SSL improvements for a newcomer to tackle

On Tue, Oct 3, 2017 at 1:15 PM, Zeus Kronion wrote: > I previously made one minuscule contribution to the project two years ago. > I'm interested in doing some more, and I'm trying to figure out what to > focus on. Two SSL-related projects caught my attention: > 1) Allow

Re: [HACKERS] Conversion error

> Tatsuo Ishii writes: >> I saw this while restoring 9.6 database to 10.0 database. >> \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported >> Is this expected? I saw nothing releated to this in the release notes. > > Don't think that's ever been

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

Amit Kapila writes: > Any other ideas? Given that the crash is so far down inside __dlopen(), and that there's a clear reference to the string we presumably passed to that: #11 0x7f518485e489 in _dl_open (file=0x55b692f2d2b0

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

Andres Freund writes: > On 2017-10-02 18:33:17 -0400, Tom Lane wrote: >> I'm kind of surprised that machine B doesn't show obvious tanking in this >> test given that msync() makes it suck so badly at copying a database. >> I wonder what is different from the kernel's

Re: [HACKERS] 64-bit queryId?

On Tue, Oct 3, 2017 at 9:07 AM, Alexander Korotkov wrote: > +1, > I see 3 options there: > 1) Drop high-order bit, as you proposed. > 2) Allow negative queryIds. > 3) Implement unsigned 64-type. > > #1 causes minor loss of precision which looks rather insignificant in

Re: [HACKERS] Logging idle checkpoints

On Tue, Oct 3, 2017 at 12:01 AM, Stephen Frost wrote: > I certainly don't care for the idea of adding log messages saying we > aren't doing anything just to match a count that's incorrectly claiming > that checkpoints are happening when they aren't. > > The down-thread

Re: [HACKERS] Logging idle checkpoints

At Tue, 3 Oct 2017 10:23:08 +0900, Michael Paquier wrote in > On Tue, Oct 3, 2017 at 12:01 AM, Stephen Frost wrote: > > I certainly don't care for the idea of adding log messages

[HACKERS] Possible SSL improvements for a newcomer to tackle

I previously made one minuscule contribution to the project two years ago. I'm interested in doing some more, and I'm trying to figure out what to focus on. Two SSL-related projects caught my attention: 1) Allow automatic selection of SSL client certificates from a certificate store

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

[HACKERS] Conversion error

I saw this while restoring 9.6 database to 10.0 database. \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported Is this expected? I saw nothing releated to this in the release notes. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English:

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

Hi, Sorry, I saw this once but somehow my attension was blown away on the way. At Tue, 3 Oct 2017 02:41:34 +0300, Alexander Korotkov wrote in > On Tue, Oct 3, 2017 at 12:20 AM, Maksim Milyutin

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

On Tue, Oct 3, 2017 at 1:30 AM, Robert Haas wrote: > 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

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

On Tue, Oct 3, 2017 at 12:54 AM, Alvaro Herrera wrote: > 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

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

Andres Freund writes: > On 2017-10-02 19:50:51 -0400, Tom Lane wrote: >> What I saw was that the backend process was consuming 100% of (one) CPU, >> while the I/O transaction rate viewed by "iostat 1" started pretty low >> --- under 10% of what the machine is capable of ---

Re: [HACKERS] Conversion error

> I saw this while restoring 9.6 database to 10.0 database. > > \connect: FATAL: conversion between UTF8 and MULE_INTERNAL is not supported > > Is this expected? I saw nothing releated to this in the release notes. This had been allowed in 9.6. So I think 10.0 silently drops the feature. Best

Re: [HACKERS] 64-bit queryId?

On Tue, Oct 3, 2017 at 12:32 AM, Tom Lane wrote: > 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

Re: [HACKERS] [PATCH] Tests for reloptions

On Sun, Oct 1, 2017 at 5:18 AM, Nikolay Shaplov wrote: > src/backend/access/common/reloptions.c get only 7 lines, it was quite covered > by existing test, but all most of the access methods gets some coverage > increase: > > src/backend/access/brin 1268 -> 1280 (+18) >

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

On Tue, Oct 3, 2017 at 3:04 AM, Andreas Seltenreich wrote: > 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

Re: [HACKERS] path toward faster partition pruning

Hi David. Thanks a lot for your review comments and sorry it took me a while to reply. On 2017/09/28 18:16, David Rowley wrote: > On 27 September 2017 at 14:22, Amit Langote > wrote: >> - 0001 includes refactoring that Dilip proposed upthread [1] (added him as >>

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

On 2017-10-02 19:50:51 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-02 18:33:17 -0400, Tom Lane wrote: > >> I'm kind of surprised that machine B doesn't show obvious tanking in this > >> test given that msync() makes it suck so badly at copying a database. >

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

On Tue, Oct 3, 2017 at 6:54 AM, Tom Lane wrote: > 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

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Thu, Sep 21, 2017 at 8:21 AM, Ashutosh Bapat wrote: > Here's set of rebased patches. The patch with extra tests is not for > committing. All other patches, except the last one, will need to be > committed together. The last patch may be committed along with

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Sep 29, 2017 at 9:12 PM, Robert Haas wrote: > > It's possible that we might find that neither of the above approaches > are practical and that the performance benefits of resolving the > transaction from the original connection are large enough that we want > to try

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

Re: [HACKERS] Commitfest 201709 is now closed

On Tue, Oct 3, 2017 at 3:12 AM, Robert Haas wrote: > 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

[HACKERS] Combining expr{Type,Typmod,Collation}() into one function.

Hi, I'd recently noticed that expr* functions actually show up in profiles because we use them at some very common paths (e.g. ExecTypeFromTLInternal()) and that we commonly call all the three variants from $subject in sequence. Looking at their code I was wondering whether it's reasonable to

Re: [HACKERS] Possible SSL improvements for a newcomer to tackle

Zeus Kronion writes: > 2) I was surprised to learn the following from the docs: >> By default, PostgreSQL will not perform any verification of the server >> certificate. > Is there a technical reason to perform no verification by default? Wouldn't > a safer default be

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Mon, Oct 2, 2017 at 1:43 PM, Bossart, Nathan wrote: > On 9/29/17, 9:33 AM, "Bossart, Nathan" wrote: >> Here's a version without the logging changes in vacuum_rel() and >> analyze_rel(). I’ll look into submitting those in the next commitfest. > >

Re: [HACKERS] Transactions involving multiple postgres foreign servers

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 overhead of

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Mon, Oct 2, 2017 at 8:13 AM, Daniel Gustafsson wrote: > I’ve moved this to the next CF, but since this no longer applies cleanly I’ve > reset it to Waiting for author. Thanks Daniel for the reminder. Attached are rebased patches. This thing rots easily... -- Michael

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] 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.

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

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.

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

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

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

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 > > wrote: > On Fri, Jul 28, 2017 at 7:58 AM, Shubham Barai

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

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

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

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),

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 > >

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

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 > >

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] [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

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.

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

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 >

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

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

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

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 >

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, >

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

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 >

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

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

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. >>

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

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.

[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

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

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

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

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.

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

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" >

[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

[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

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

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,

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

  1   2   >