Re: WIP: Covering + unique indexes.

Thank you, pushed. Actually, I see one tiny issue with extra '*' characters here: +* The number of attributes won't be explicitly represented if the +* negative infinity tuple was generated during a page split that +* occurred with a version of Postgres

RE: Speedup of relation deletes during recovery

From: Fujii Masao [mailto:masao.fu...@gmail.com] > Yeah, it's worth working on this problem. To decrease the number of scans > of > shared_buffers, you would need to change the order of truncations of files > and > WAL logging. In RelationTruncate(), currently WAL is logged after FSM and > VM >

Re: [HACKERS] Runtime Partition Pruning

Hi David. On 2018/04/19 9:04, David Rowley wrote: > On 19 April 2018 at 03:13, Robert Haas wrote: >> On Mon, Apr 16, 2018 at 10:46 PM, David Rowley >> wrote: >>> The patch does happen to improve performance slightly, but that is >>> most

RE: reloption to prevent VACUUM from truncating empty pages at the end of relation

From: Fujii Masao [mailto:masao.fu...@gmail.com] > a very long time before accessing to the relation. Which would cause the > response-time spikes, for example, I observed such spikes several times > on > the server with shared_buffers = 300GB while running the benchmark. FYI, a long transaction

Is a modern build system acceptable for older platforms

There have been several discussions of replacing PG's autoconf + src/tools/msvc system. The last example is happening now at the bottom of the Setting rpath on llvmjit.so thread. I see potentially big advantages to moving but also to PG's conservative approach that keeps it running on edge and

Re: Corrupted btree index on HEAD because of covering indexes

Will see... Michael Paquier wrote: Hi all, I was just testing the VACUUM truncation logic, and bumped into what looks like a corrupted btree index. Here is a reproducer: create table aa (a int primary key, b bool); insert into aa values (generate_series(1,100), false); checkpoint; update

Corrupted btree index on HEAD because of covering indexes

Hi all, I was just testing the VACUUM truncation logic, and bumped into what looks like a corrupted btree index. Here is a reproducer: create table aa (a int primary key, b bool); insert into aa values (generate_series(1,100), false); checkpoint; update aa set b = false where a > 50; --

Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

On Wed, Apr 18, 2018 at 04:49:17PM -0400, Tom Lane wrote: > Just to throw out a possibly-crazy idea: maybe we could fix this by > PANIC'ing if truncation fails, so that we replay the row deletions from > WAL. Obviously this would be intolerable if the case were frequent, > but we've had only two

RE: Built-in connection pooling

From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru] Oracle, for example, you can create dedicated and non-dedicated backends. > I wonder why we do not want to have something similar in Postgres. Yes, I want it, too. In addition to dedicated and shared server processes, Oracle provides

Re: Should we add GUCs to allow partition pruning to be disabled?

On Thu, Apr 19, 2018 at 2:54 AM, David Rowley wrote: > If we just did it at plan time then > pre-PREPAREd queries might still prune. That does not seem very > useful if it's being disabled due to the discovery of some bug. > As you have pointed out upthread, that's

Re: Postgres 10 problem with UNION ALL of null value in "subselect"

2018-04-19 5:01 GMT+02:00 Kyotaro HORIGUCHI : > At Mon, 16 Apr 2018 18:39:24 +0530, Ashutosh Bapat < > ashutosh.ba...@enterprisedb.com> wrote in

Is there a memory leak in commit 8561e48?

in commit 8561e48, _SPI_stack alloc from TopMemoryContext. But AtEOXact_SPI just set _SPI_stack = NULL. Is this a memory leak?

Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process

On Wed, Apr 18, 2018 at 6:55 PM, Thomas Munro wrote: > Here's a draft patch that does that. Here's a better one (the previous version could read past the end of the occurred_events array). -- Thomas Munro http://www.enterprisedb.com

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On Wed, Apr 18, 2018 at 5:04 PM, Thomas Munro wrote: > On Wed, Apr 11, 2018 at 10:22 PM, Heikki Linnakangas wrote: >>> On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund >>> wrote: That person said he'd work on adding an

Re: Postgres 10 problem with UNION ALL of null value in "subselect"

At Mon, 16 Apr 2018 18:39:24 +0530, Ashutosh Bapat wrote in

Re: Adding an LWLockHeldByMe()-like function that reports if any buffer content lock is held

On Wed, Apr 18, 2018 at 6:53 PM, Michael Paquier wrote: >> I'm curious about what we'll find by just by adding >> Assert(!AnyBufferLockHeldByMe()) to the top of >> heap_tuple_fetch_attr(). AssertNotInCriticalSection() certainly found >> several bugs when it was first added. >

Re: VM map freeze corruption

On Wed, Apr 18, 2018 at 10:36 PM, Alvaro Herrera wrote: > Pavan Deolasee wrote: >> On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote: > >> > My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId() >> > returns FRM_NOOP if the MultiXACT

Re: Speedup of relation deletes during recovery

On Thu, Apr 19, 2018 at 01:52:26AM +0900, Fujii Masao wrote: > No. But after my colleague truncated more than one hundred tables on > the server with shared_buffers = 300GB, the recovery could not finish > even after 10 minutes since the startup of the recovery. So I had to > shutdown the server

Re: Adding an LWLockHeldByMe()-like function that reports if any buffer content lock is held

On Wed, Apr 18, 2018 at 06:44:00PM -0700, Peter Geoghegan wrote: > What I have in mind here is something that's a bit like > AssertNotInCriticalSection(). We don't need to pepper > AssertNotInCriticalSection() everywhere in practice, because calling > palloc() is a pretty good proxy for "function

Re: ON CONFLICT DO UPDATE for partitioned tables

On 2018/04/18 22:40, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2018/04/18 0:04, Alvaro Herrera wrote: >>> Amit Langote wrote: >>> I just confirmed my hunch that this wouldn't somehow do the right thing when the OID system column is involved. Like this case: >>> >>> This looks

Re: Problem while setting the fpw with SIGHUP

On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote: > I would just document the risks. If the documentation says that you > can't rely on the value until after the next checkpoint, or whatever > the rule is, then I think we're fine. I don't think that we really > have the infrastructure

Re: Adding an LWLockHeldByMe()-like function that reports if any buffer content lock is held

On Wed, Apr 18, 2018 at 5:46 PM, Michael Paquier wrote: > Personally, I favor approaches like that, because it allows to catch up > problems in using some APIs when people working on a patch miss any kind > of warning comments at the top of the function or within it which >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Wed, Apr 18, 2018 at 07:41:44PM +0530, Amit Kapila wrote: > I think it makes sense to pursue that approach, but it might be worth > considering some alternative till we have it. I remember last time > (in 2015) we have discussed some another solution [1] to this problem > (or similar) and we

Re: Adding an LWLockHeldByMe()-like function that reports if any buffer content lock is held

On Wed, Apr 18, 2018 at 04:53:29PM -0700, Peter Geoghegan wrote: > It occurred to me that it would be nice to be able to > Assert(!AnyBufferLockHeldByMe()) at a certain point within > index_form_tuple(), to make sure that our assumptions hold. If > index_truncate_tuple() (or any other function)

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On 19 April 2018 at 07:31, Mark Kirkwood wrote: > On 19/04/18 00:45, Craig Ringer wrote: > >> >> I guarantee you that when you create a 100GB EBS volume on AWS EC2, >> you don't get 100GB of storage preallocated. AWS are probably pretty >> good about not running out

Re: Proposal: Adding json logging

On Wed, Apr 18, 2018 at 12:10:47PM -0700, Christophe Pettus wrote: > On Apr 18, 2018, at 11:59, Robert Haas wrote: >> For the record, I'm tentatively in favor of including something like >> this in contrib. > > I'm much less fussed by this in contrib/ (with the same

Re: Proposal: Adding json logging

On Wed, Apr 18, 2018 at 02:59:26PM -0400, Robert Haas wrote: > > Note that logging_collector should be enabled in postgresql.conf to > ensure consistent log outputs. As JSON strings are longer than normal > logs generated by PostgreSQL, this module increases the odds of malformed > log

Re: Fix for documentation of Covering Indexes

On Wed, Apr 18, 2018 at 05:52:01AM -0400, Heikki Linnakangas wrote: > Committed, thanks! Thanks for the commit. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] Runtime Partition Pruning

On 19 April 2018 at 12:04, David Rowley wrote: > insert into p select x,x from generate_Series(1,1000) x; > insert into t1 select x from generate_series(1,1000) x; Correction. These were meant to read: insert into p select x,x from generate_Series(1,1000) x;

Re: [HACKERS] Runtime Partition Pruning

On 19 April 2018 at 03:13, Robert Haas wrote: > On Mon, Apr 16, 2018 at 10:46 PM, David Rowley > wrote: >> I did go and start working on a patch to test how possible this would >> be and came up with the attached. I've left a stray >>

Adding an LWLockHeldByMe()-like function that reports if any buffer content lock is held

During recent review of the INCLUDE covering index patch, I pushed to formalize the slightly delicate assumptions that we make around how index_truncate_tuple() is called. It's natural to call index_truncate_tuple() during a page split, when a buffer lock is held. This is what we actually do in

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On 19/04/18 00:45, Craig Ringer wrote: I guarantee you that when you create a 100GB EBS volume on AWS EC2, you don't get 100GB of storage preallocated. AWS are probably pretty good about not running out of backing store, though. Some db folks (used to anyway) advise dd'ing to your freshly

Re: pruning disabled for array, enum, record, range type partition keys

Alvaro Herrera writes: > I now wonder if there's anything else that equivclass.c or indxpath.c > can teach us on this topic. I've been meaning to review this but have been a bit distracted. Will try to look tomorrow. regards, tom lane

Re: Query is over 2x slower with jit=on

On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: > Not convinced that that is true - the issue is more likely that JIT work in > workers is counted as execute time... Gotta add that somehow, not sure what > the best way would be. Oh, that does seem like something that

Re: WIP: Covering + unique indexes.

On Wed, Apr 18, 2018 at 1:45 PM, Peter Geoghegan wrote: > I suggest committing this patch as-is. Actually, I see one tiny issue with extra '*' characters here: > +* The number of attributes won't be explicitly represented if the > +* negative infinity tuple

Re: pruning disabled for array, enum, record, range type partition keys

Amit Langote wrote: > On Thu, Apr 19, 2018 at 12:01 AM, Alvaro Herrera > wrote: > > Makes sense. Still, I was expecting that pruning of hash partitioning > > would also work for pseudotypes, yet it doesn't. > > It does? Aha, so it does. While staring at this new

Re: Should we add GUCs to allow partition pruning to be disabled?

On 18 April 2018 at 21:36, Ashutosh Bapat wrote: > On Wed, Apr 18, 2018 at 5:37 AM, David Rowley >> a) Disable run-time pruning during execution. >> b) Disable run-time pruning during planning. >> c) Both of the above. >> >> The differentiation of the above is

Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

I wrote: > Relation truncation throws away the page image in memory without ever > writing it to disk. Then, if the subsequent file truncate step fails, > we have a problem, because anyone who goes looking for that page will > fetch it afresh from disk and see the tuples as live. > There are WAL

Re: WIP: Covering + unique indexes.

On Wed, Apr 18, 2018 at 1:32 PM, Teodor Sigaev wrote: >> I don't understand. We do check the number of attributes on rightmost >> pages, but we do so separately, in the main loop. For every item that >> isn't the high key. > > Comment added, pls, verify. And refactored

Re: WIP: Covering + unique indexes.

I don't understand. We do check the number of attributes on rightmost pages, but we do so separately, in the main loop. For every item that isn't the high key. Comment added, pls, verify. And refactored _bt_check_natts(), I hope, now it's a bit more readable. 4) BTreeTupSetNAtts - seems, it's

Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

"MauMau" writes: > I'd like to continue to think of a solution and create a patch, based > on the severity and how the customer will respond to our answer. I > have a feeling that we have to say it's a bit serious, since it > requires recovery from a base backup, not just

Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

From: Tom Lane [ re-reads thread... ] The extra assumption you need in order to have trouble is that the blocks in question are dirty in shared buffers and have never been written to disk since their rows were deleted. Then the situation is that the page image on disk shows the rows as live,

Re: Proposal: Adding json logging

John W Higgins wrote: > On Sun, Apr 15, 2018 at 11:08 AM, David Arnold wrote: > > > >This would appear to solve multiline issues within Fluent. > > >https://docs.fluentd.org/v0.12/articles/parser_multiline > > > > I definitely looked at that, but what guarantees do I have

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

I wrote: > Pavan Deolasee writes: >> What if we remember the buffers as seen by count_nondeletable_pages() and >> then just discard those specific buffers instead of scanning the entire >> shared_buffers again? > That's an idea. BTW, before pushing too hard on any of

Re: Proposal: Adding json logging

Excellent phrasing (thanks to Christophe!): "There is a large class of log analysis tool out there that has trouble with multiline formats and we should be good ecosystem players" > I'm much less fussed by this in contrib/ (with the same concern you noted), at a minimum as an example of how to do

Re: Query is over 2x slower with jit=on

On April 18, 2018 12:16:35 PM PDT, Robert Haas wrote: >On Wed, Apr 18, 2018 at 11:50 AM, Andres Freund >wrote: >> JIT has cost, and sometimes it's not beneficial. Here our heuristics >> when to JIT appear to be a bit off. In the parallel world it's

Re: Query is over 2x slower with jit=on

On Wed, Apr 18, 2018 at 11:50 AM, Andres Freund wrote: > JIT has cost, and sometimes it's not beneficial. Here our heuristics > when to JIT appear to be a bit off. In the parallel world it's worse > because the JITing is duplicated for parallel workers atm. It seems like

Re: Proposal: Adding json logging

> On Apr 18, 2018, at 11:59, Robert Haas wrote: > > I'm not sure exactly how you intended to this comment, but it seems to > me that whether CSV is ease or hard to parse, somebody might > legitimately find JSON more convenient. Of course. The specific comment I was

Re: Truncation failure in autovacuum results in data corruption (duplicate keys)

"MauMau" writes: > However, I have a question. How does the truncation failure in > autovacuum lead to duplicate keys? The failed-to-be-truncated pages > should only contain dead tuples, so pg_dump's table scan should ignore > dead tuples in those pages. [ re-reads

Re: Proposal: Adding json logging

On Sun, Apr 15, 2018 at 1:07 PM, Christophe Pettus wrote: >> On Apr 15, 2018, at 09:51, David Arnold wrote: >> 1. Throughout this vivid discussion a good portion of support has already >> been manifested for the need of a more structured (machine readable)

Re: Deadlock in multiple CIC.

Alvaro Herrera writes: > Tom Lane wrote: >> Will look into that too. I'm not sure that adding extra expected >> outputs is sane, though --- might be best to just force the intended >> isolation level within those tests. > As I recall (not much, admittedly) that was one

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Pavan Deolasee writes: > What if we remember the buffers as seen by count_nondeletable_pages() and > then just discard those specific buffers instead of scanning the entire > shared_buffers again? That's an idea. > Surely we revisit all to-be-truncated blocks before >

Truncation failure in autovacuum results in data corruption (duplicate keys)

Hello, It seems to me that our customer might have hit an unresolved data corruption issue which is already known in this ML, but I can't figure out why this happened. I'd appreciate if you could give me your thoughts. Depending on the severity of this issue and the customer's request, I think

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Wed, Apr 18, 2018 at 10:50 PM, Fujii Masao wrote: > > > I'm not sure if it's safe to cancel forcibly VACUUM's truncation during > scaning shared_buffers. That scan happens after WAL-logging and before > the actual truncation. > > Ah ok. I misread your proposal. This is

Re: WIP: Covering + unique indexes.

(() On Wed, Apr 18, 2018 at 10:10 AM, Teodor Sigaev wrote: > I mostly agree with your patch, nice work, but I have some notices for your > patch: Thanks. > 1) > bt_target_page_check(): > if (!P_RIGHTMOST(topaque) && > !_bt_check_natts(state->rel, state->target,

Re: pgindent run soon?

Teodor Sigaev writes: >> If there are large refactoring or bug-fix patches that haven't landed >> yet, then it'd be appropriate to wait for those to get in, but I'm not >> aware of such at the moment. > Pls, wait >

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Wed, Apr 18, 2018 at 11:29 PM, Pavan Deolasee wrote: > > > On Tue, Apr 17, 2018 at 11:05 PM, Fujii Masao wrote: >> >> Hi, >> >> I'd like to propose to add $SUBJECT for performance improvement. >> >> When VACUUM tries to truncate the trailing

Re: pgindent run soon?

If there are large refactoring or bug-fix patches that haven't landed yet, then it'd be appropriate to wait for those to get in, but I'm not aware of such at the moment. Pls, wait https://www.postgresql.org/message-id/9c63951d-7696-ecbb-b832-70db7ed3f39b%40sigaev.ru Thank you. -- Teodor

Re: WIP: Covering + unique indexes.

I mostly agree with your patch, nice work, but I have some notices for your patch: 1) bt_target_page_check(): if (!P_RIGHTMOST(topaque) && !_bt_check_natts(state->rel, state->target, P_HIKEY)) Seems not very obvious: it looks like we don't need to check nattrs on rightmost page.

Re: Query is over 2x slower with jit=on

On April 18, 2018 9:50:48 AM PDT, Chapman Flack wrote: >On 04/18/2018 12:27 PM, Simon Riggs wrote: > >> Please change the name of the "JIT" parameter to something meaningful >> to humans before this gets too far into the wild. >> >> SSL is somewhat understandable because

Re: Speedup of relation deletes during recovery

On Wed, Apr 18, 2018 at 10:44 AM, Michael Paquier wrote: > On Wed, Apr 18, 2018 at 12:46:58AM +0900, Fujii Masao wrote: >> Yes, I think. And, I found that smgrdounlinkfork() is also dead code. >> Per the discussion [1], this unused function was left intentionally. >> But it's

Re: Query is over 2x slower with jit=on

On 04/18/2018 12:27 PM, Simon Riggs wrote: > Please change the name of the "JIT" parameter to something meaningful > to humans before this gets too far into the wild. > > SSL is somewhat understandable because its not a Postgres-private term. JIT is hardly a Postgres-private term. It's a

Re: Deadlock in multiple CIC.

Tom Lane wrote: > *** /home/postgres/pgsql/src/test/isolation/expected/lock-update-delete_1.out > Mon Feb 12 14:53:46 2018 > --- > /home/postgres/pgsql/src/test/isolation/output_iso/results/lock-update-delete.out >Wed Apr 18 11:30:23 2018 > *** > *** 150,156 > > t

Re: Query is over 2x slower with jit=on

On 18 April 2018 at 16:50, Andres Freund wrote: > On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: >> With jit=on: >> https://explain.depesz.com/s/vYB >> Planning Time: 0.336 ms >> JIT: >> Functions: 716 >> Generation Time: 78.404 ms >> Inlining: false >>

Sv: Re: Query is over 2x slower with jit=on

På onsdag 18. april 2018 kl. 17:50:55, skrev Andres Freund >: On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With jit=on: > https://explain.depesz.com/s/vYB > Planning Time: 0.336 ms >  JIT: >   Functions: 716 >   Generation Time:

Re: Setting rpath on llvmjit.so?

I talked about autoconf build system, /tools/msvc it's extra home build system. On Thu, 19 Apr 2018, 00:58 Andres Freund, wrote: > On 2018-04-18 15:54:59 +, Yuriy Zhuravlev wrote: > > Current autoconf system not working on Windows at all, what we talk > about? > > We

Re: Setting rpath on llvmjit.so?

> > I also politely decline the offer to be forced to use XCode on mac. Why? We supporting MSVC and not nmake, what difference with xcode? Also, it's just extra benefit from cmake/meson.

Re: Setting rpath on llvmjit.so?

On 2018-04-18 15:54:59 +, Yuriy Zhuravlev wrote: > Current autoconf system not working on Windows at all, what we talk about? We generate windows project files. See src/tools/msvc/ - Andres

Re: Setting rpath on llvmjit.so?

Current autoconf system not working on Windows at all, what we talk about? On Wed, 18 Apr 2018, 23:57 Robert Haas, wrote: > On Tue, Apr 17, 2018 at 4:13 PM, Andres Freund wrote: > > I'd not advocate for this solely based on the age of autoconf. But

Re: Query is over 2x slower with jit=on

On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With jit=on: > https://explain.depesz.com/s/vYB > Planning Time: 0.336 ms > JIT: >  Functions: 716 >  Generation Time: 78.404 ms >  Inlining: false >  Inlining Time: 0.000 ms >  Optimization: false >  Optimization Time: 43.916 ms

Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

On Fri, 2018-04-06 at 13:57 -0700, legrand legrand wrote: > At startup time there are 2 identical plans found in the view > I thought it should have be only one: the "initial" one > (as long as there is no "good" or "bad" one). Yes, those are 'remnants' from the time where I had two columns, one

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On 17 April 2018 at 20:09, Tom Lane wrote: > Alvaro Herrera writes: >> Andres was working on a radix tree structure to fix this problem, but >> that seems to be abandoned now, and it seems a major undertaking. While >> I agree that the proposed

Re: Deadlock in multiple CIC.

I wrote: >>> (A couple of the other isolation tests do fail reliably under this >>> scenario; is it worth hardening them?) >> Yes, I think it's worth making them pass somehow -- see commits >> f18795e7b74c, a0eae1a2eeb6. > Will look into that too. I'm not sure that adding extra expected >

Re: Deadlock in multiple CIC.

Tom Lane wrote: > Anyway, at this point I'm going to give up on the debug logging, revert > 9.4 to its prior state, and then see if the transaction-restart patch > makes the problem go away. Agreed, thanks. > >> (A couple of the other isolation tests do fail reliably under this > >> scenario;

Query is over 2x slower with jit=on

Hi all.   I don't know whether this is expected or not but I'm experiencing over 2x slowdown on a large query in PG-11 with JIT=on.   (query is a prepared statement executed with "explain analyze execute myprepared(arg1, arg2, ..., argn)")   After 10 executions these are the results (the first 5

Re: Deadlock in multiple CIC.

I wrote: >> It's still not entirely clear what's happening on okapi, ... okapi has now passed two consecutive runs with elog(LOG) messages in place between DefineIndex's snapmgr calls. Considering that it had failed 37 of 44 test runs since 47a3a13 went in, I think two successive passes is

Re: pgindent run soon?

On Tue, Apr 17, 2018 at 12:57 PM, Tom Lane wrote: > Now that feature freeze is past, I wonder if it's time to run pgindent. +1 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Runtime Partition Pruning

On Mon, Apr 16, 2018 at 10:46 PM, David Rowley wrote: > I did go and start working on a patch to test how possible this would > be and came up with the attached. I've left a stray > MemoryContextStatsDetail call in there which does indicate that > something is not

Re: pruning disabled for array, enum, record, range type partition keys

On Thu, Apr 19, 2018 at 12:01 AM, Alvaro Herrera wrote: > Amit Langote wrote: > >> On 2018/04/18 7:11, Alvaro Herrera wrote: >> >> @@ -1546,8 +1546,8 @@ match_clause_to_partition_key(RelOptInfo *rel, >>case PARTITION_STRATEGY_HASH: >> cmpfn =

Re: pruning disabled for array, enum, record, range type partition keys

Amit Langote wrote: > On 2018/04/18 7:11, Alvaro Herrera wrote: > > @@ -1546,8 +1546,8 @@ match_clause_to_partition_key(RelOptInfo *rel, >case PARTITION_STRATEGY_HASH: > cmpfn = get_opfamily_proc(part_scheme->partopfamily[partkeyidx], > - op_righttype,

Re: Setting rpath on llvmjit.so?

On Tue, Apr 17, 2018 at 4:13 PM, Andres Freund wrote: > I'd not advocate for this solely based on the age of autoconf. But the > separate windows buildsystem which makes it very hard to build > extensions separately is a good reason on its own. As is the fact that > recursive

Re: Problem while setting the fpw with SIGHUP

On Wed, Apr 18, 2018 at 10:37 AM, Amit Kapila wrote: > On Fri, Apr 13, 2018 at 10:36 PM, Robert Haas wrote: >> On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote: >>> Still does it matter when the change is effective? >>

Re: Problem while setting the fpw with SIGHUP

On Fri, Apr 13, 2018 at 10:36 PM, Robert Haas wrote: > On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote: >> Still does it matter when the change is effective? > > I don't really care deeply about when the change takes effect, but I > do care

Re: Setting rpath on llvmjit.so?

On 4/17/18 16:14, Andres Freund wrote: > I still think cmake is the least unreasonable path going forward. I would rather try to make Meson work and if needed add features back into Meson. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: Documentation for bootstrap data conversion

John Naylor writes: > On 4/9/18, Tom Lane wrote: >> Meh, I think either is fine really. I do recall changing something >> in bki.sgml that referred to both "bootstrap relations" and "bootstrap >> catalogs" in practically the same sentence. I think that

Re: remove quoting hacks and simplify bootscanner.l

John Naylor writes: > For the bootstrap data conversion, it was desirable for postgres.bki > to remain unchanged, so some ugly quoting hacks were added to > genbki.pl to match the quoting conventions in the DATA() lines. At > this point, it's possible (and worthwhile I think)

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Tue, Apr 17, 2018 at 11:05 PM, Fujii Masao wrote: > Hi, > > I'd like to propose to add $SUBJECT for performance improvement. > > When VACUUM tries to truncate the trailing empty pages, it scans > shared_buffers > to invalidate the pages-to-truncate during holding an

Re: Built-in connection pooling

> 18 апр. 2018 г., в 16:24, David Fetter написал(а): > > On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: >> Yandex team is following this approach with theirOdysseus >> (multithreaded version of pgbouncer with many of pgbouncer issues >> fixed). > > Have

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

On Wed, Apr 18, 2018 at 7:46 AM, Andres Freund wrote: > On 2018-04-18 10:46:51 +0900, Michael Paquier wrote: >> On Tue, Apr 17, 2018 at 06:13:31PM -0700, Andres Freund wrote: >> > Not sure what you mean? >> >> Do you need help on it? I suggest that I could undertake the

Re: Postgres stucks in deadlock detection

On 16.04.2018 14:11, Konstantin Knizhnik wrote: On 14.04.2018 10:09, Юрий Соколов wrote: пт, 13 апр. 2018 г., 21:10 Andres Freund >: Hi, On 2018-04-13 19:13:07 +0300, Konstantin Knizhnik wrote: > On 13.04.2018 18:41, Andres

Re: Built-in connection pooling

On 18.04.2018 16:41, Heikki Linnakangas wrote: On 18/04/18 07:52, Konstantin Knizhnik wrote: On 18.04.2018 13:36, Heikki Linnakangas wrote: On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name

Re: Built-in connection pooling

On 18/04/18 07:52, Konstantin Knizhnik wrote: On 18.04.2018 13:36, Heikki Linnakangas wrote: On 18/04/18 06:10, Konstantin Knizhnik wrote: But there are still use cases which can not be covered y external connection pooler. Can you name some? I understand that the existing external

Re: ON CONFLICT DO UPDATE for partitioned tables

Amit Langote wrote: > On 2018/04/18 0:04, Alvaro Herrera wrote: > > Amit Langote wrote: > > > >> I just confirmed my hunch that this wouldn't somehow do the right thing > >> when the OID system column is involved. Like this case: > > > > This looks too big a patch to pursue now. I'm inclined

Re: VM map freeze corruption

Pavan Deolasee wrote: > On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote: > > My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId() > > returns FRM_NOOP if the MultiXACT locked rows haven't committed. This > > results in changed=false and totally_frozen=true(as

Re: Built-in connection pooling

On 18.04.2018 16:24, David Fetter wrote: On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: Yandex team is following this approach with theirOdysseus (multithreaded version of pgbouncer with many of pgbouncer issues fixed). Have they opened the source to Odysseus? If not,

Re: Built-in connection pooling

On 18.04.2018 16:09, Craig Ringer wrote: On 18 April 2018 at 19:52, Konstantin Knizhnik wrote: As far as I know most of DBMSes have some kind of internal connection pooling. Oracle, for example, you can create dedicated and non-dedicated backends. I wonder why we

Re: Built-in connection pooling

On Wed, Apr 18, 2018 at 02:52:39PM +0300, Konstantin Knizhnik wrote: > Yandex team is following this approach with theirOdysseus > (multithreaded version of pgbouncer with many of pgbouncer issues > fixed). Have they opened the source to Odysseus? If not, do they have plans to? Best, David. --

Re: Built-in connection pooling

On 18 April 2018 at 19:52, Konstantin Knizhnik wrote: > As far as I know most of DBMSes have some kind of internal connection > pooling. > Oracle, for example, you can create dedicated and non-dedicated backends. > I wonder why we do not want to have something similar

Re: Oddity in tuple routing for foreign partitions

(2018/04/18 14:44), Amit Langote wrote: On 2018/04/17 16:41, Etsuro Fujita wrote: In the INSERT/COPY-tuple-routing case, as explained by Amit, the RTE at that position in the EState's range table is the one for the partitioned table of a given partition, so the statement would be true. BUT in

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Tue, Apr 17, 2018 at 02:41:42PM -0700, Andres Freund wrote: > On 2018-04-17 17:32:45 -0400, Bruce Momjian wrote: > > On Mon, Apr 9, 2018 at 03:42:35PM +0200, Tomas Vondra wrote: > > > That doesn't seem like a very practical way. It's better than nothing, > > > of course, but I wonder how would

  1   2   >