Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

On Tue, Dec 6, 2016 at 4:38 PM, Fujii Masao wrote: > I changed the order of descriptions of the walsender state in > intuitive one rather than alphabetical one. Also I enhanced > the description of "potential" state. > > Could you review the latest patch? Fine for me. The

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

On Tue, Dec 6, 2016 at 2:13 PM, Michael Paquier wrote: > On Tue, Dec 6, 2016 at 1:54 PM, Fujii Masao wrote: >> + backup: The WAL sender is sending a backup. >> >> Seems it's better to use "This WAL sender" rather than "The WAL sender"

Re: [HACKERS] Random number generation, take two

On Tue, Dec 6, 2016 at 10:31 AM, Tom Lane wrote: > I wrote: >> Heikki Linnakangas writes: >>> Tom: I expect pademelon to fail at the configure step, complaining that >>> "no source of strong random numbers was found". Let's wait for one >>> cycle, to verify

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

On Mon, Dec 5, 2016 at 6:09 PM, Michael Paquier wrote: > On Mon, Dec 5, 2016 at 5:11 PM, Heikki Linnakangas wrote: >> I'm afraid if we just start using EVP_CIPHER_CTX_new(), we'll leak the >> context on any error. We had exactly the same problem with

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Hello Robert, Given the experience with pgbench and the psql context, I do not think that it would really need to go beyond step 2 above, but I agree that I may be wrong and it is best to be prepared for that from the start. Given the complexity and effort involved with (5), it seems wise to

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 9:54 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > The concern is that "scan every row" could be very expensive - though in > writing this I'm thinking that you'd quickly find a non-match even in a > large dataset - and so a less perfect but still valid

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

On Tue, Dec 6, 2016 at 1:54 PM, Fujii Masao wrote: > + backup: The WAL sender is sending a backup. > > Seems it's better to use "This WAL sender" rather than "The WAL sender" > like the descriptions of other fields. > > There are two descriptions of "streaming"

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

On Fri, Nov 11, 2016 at 10:03 PM, Michael Paquier wrote: > On Thu, Nov 10, 2016 at 10:35 PM, Fujii Masao wrote: >> On Wed, Nov 9, 2016 at 2:33 PM, Michael Paquier >> wrote: >>> Hi all, >>> >>> The documentation does

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

feel free to s/typemod/typmod/ ... my fingers don't want to drop the "e" On Mon, Dec 5, 2016 at 9:17 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston" < > david.g.johns...@gmail.com> wrote in

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 18:59:42 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Mon, Nov 28, 2016 at 8:03 PM, Masahiko Sawada wrote: > On Sat, Nov 26, 2016 at 10:27 PM, Michael Paquier > wrote: >> On Tue, Nov 15, 2016 at 7:08 PM, Masahiko Sawada >> wrote: >>> Attached latest version patch

Re: [HACKERS] Logical Replication WIP

On 2016-12-02 12:37:49 -0500, Peter Eisentraut wrote: > On 11/20/16 1:02 PM, Petr Jelinek wrote: > > 0001: > > This is the reworked approach to temporary slots that I sent earlier. > > Andres, you had expressed an interest in this. Will you be able to > review it soon? Yep. Needed to get that

[HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi Everyone, TL;DR: Making things faster. Architectural evalation. as some of you might be aware I've been working on making execution of larger queries in postgresl faster. While working on "batched execution" I came to the conclusion that, while necessary, isn't currently showing a large

[HACKERS] Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples

Tom Lane wrote: > Alvaro Herrera writes: > > Permit dump/reload of not-too-large >1GB tuples > > I apologize for not having paid close enough attention earlier, but: > this patch is absolutely unacceptable for the back branches and MUST > be reverted there. Adding

Re: [HACKERS] [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples

Alvaro Herrera writes: > Permit dump/reload of not-too-large >1GB tuples I apologize for not having paid close enough attention earlier, but: this patch is absolutely unacceptable for the back branches and MUST be reverted there. Adding another field to StringInfoData

Re: [HACKERS] Tackling JsonPath support

On 11/28/16 12:38 PM, Nico Williams wrote: The internal representation of JSON data is bound to be completely different, no doubt Actually, that could be a good thing. The internal storage of JSONB is optimized for compress-ability, but that imposes a substantial overhead to calls that are

Re: [HACKERS] [COMMITTERS] pgsql: Add support for restrictive RLS policies

On 2016-12-05 20:51:02 +, Stephen Frost wrote: > Add support for restrictive RLS policies > Modified Files > -- > src/backend/nodes/copyfuncs.c | 1 + > src/backend/nodes/equalfuncs.c| 1 + > src/backend/parser/gram.y | 43 +++-- >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 6:36 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston" < > david.g.johns...@gmail.com> wrote in v8nr0FsCFrQ=oo1dkp...@mail.gmail.com> > > On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On 6 December 2016 at 04:52, David G. Johnston wrote: > Can we be precise enough to perform #2 if the top-level (or immediate > parent) command is an INSERT - the existing table is going to enforce its > own typemod anyway, otherwise go with #1? We already routinely

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Hello, At Mon, 5 Dec 2016 14:42:39 -0700, "David G. Johnston" wrote in

Re: [HACKERS] Random number generation, take two

I wrote: > Heikki Linnakangas writes: >> Tom: I expect pademelon to fail at the configure step, complaining that >> "no source of strong random numbers was found". Let's wait for one >> cycle, to verify that it does fail like that. After that, can you add >> the

Re: [HACKERS] commitfest 2016-11 status summary

On 12/5/16 3:27 PM, Robert Haas wrote: On Mon, Dec 5, 2016 at 12:50 AM, Haribabu Kommi wrote: Moved to next CF with needs review. 1. patch doesn't receive any full review in the commitfest 2. Patch received feedback at the end of commitfest. The number of patches

Re: [HACKERS] Separate connection handling from backends

On 12/5/16 2:14 PM, David Fetter wrote: One solution to this would be to segregate connection handling from actual backends, somewhere along the lines of separating the main loop from the switch() that handles libpq commands. Benefits: [interesting stuff elided] What do you see as the

Re: [HACKERS] raw output from copy

2016-12-05 22:45 GMT+09:00 Pavel Stehule : > > There are more goals: > > 1. user friendly import of text or binary data - import text data (with > psql) from file is possible - but you have to load a content to psql > variable. For binary data you should to use workaround

Re: [HACKERS] Logical Replication WIP

On 04/12/16 02:06, Peter Eisentraut wrote: > I massaged the temporary replication slot patch a bit. I changed the > column name in pg_stat_replication_slots from "persistent" to > "temporary" and flipped the logical sense, so that it is consistent with > the creation commands. I also adjusted

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 2:22 PM, Tom Lane wrote: > "David G. Johnston" writes: > > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: > >> In order to fix this, we first have to decide what the semantics ought > >> to be. I think

Re: [HACKERS] commitfest 2016-11 status summary

On Mon, Dec 5, 2016 at 12:50 AM, Haribabu Kommi wrote: > Moved to next CF with needs review. > 1. patch doesn't receive any full review in the commitfest > 2. Patch received feedback at the end of commitfest. The number of patches that got this treatment seems quite

Re: [HACKERS] commitfest 2016-11 status summary

On Tue, Dec 6, 2016 at 12:59 AM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: > > On Mon, Dec 5, 2016 at 11:56 AM, Michael Paquier > > wrote: > > > On Mon, Dec 5, 2016 at 2:50 PM, Haribabu Kommi < >

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

"David G. Johnston" writes: > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: >> In order to fix this, we first have to decide what the semantics ought >> to be. I think there are two plausible definitions: >> 1. If all the expressions in the

Re: [HACKERS] Indirect indexes

On Tue, Dec 6, 2016 at 4:55 AM, Alvaro Herrera wrote: > Haribabu Kommi wrote: > > > Closed in 2016-11 commitfest with "returned with feedback" status. > > What feedback? Sorry, I was not able to find that there is no feedback on the patch earlier. Thanks for your

Re: [HACKERS] [sqlsmith] Crash in gather_readnext

On Mon, Dec 5, 2016 at 3:07 PM, Andreas Seltenreich wrote: > on master as of a0ae54d, there's a 1 in 10e6 chance sqlsmith catches > gather_readnext reading beyond the gatherstate->readers array with > readers[gatherstate->readnext]. Sample backtrace below. > > As readnext is

Re: [HACKERS] missing optimization - column <> column

Actually there are lots of things that can be done with this sort of theorem proving. And NULL is a plenty good answer for a filter, just not for a check constraint. Amongst them INSERT through UNION ALL for symmetric views which can be handy for FDW partitioned tables. One such implementation

Re: [HACKERS] missing optimization - column <> column

On Mon, Dec 5, 2016 at 7:02 PM, Corey Huinker wrote: > >> Would it be worth replacing the condition with the equivalent? >> I mean would that help optimizing better some queries when it knows that >> a is (not) nullable or when "a" is more complicated expression? >> >> a

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: > I looked into the issue reported in bug #14448, > https://www.postgresql.org/message-id/20161205143037. > 4377.60754%40wrigleys.postgresql.org > > The core of it seems to be that expandRTE() will report the type and > typmod

Re: [HACKERS] Cache Hash Index meta page.

On Mon, Dec 5, 2016 at 2:58 PM, Mithun Cy wrote: > On Thu, Dec 1, 2016 at 8:10 PM, Jesper Pedersen < > jesper.peder...@redhat.com> wrote: > >As the concurrent hash index patch was committed in 6d46f4 this patch > needs a rebase. > > Thanks Jesper, > > Adding the

Re: [HACKERS] Separate connection handling from backends

On Mon, Dec 05, 2016 at 01:48:03PM -0600, Jim Nasby wrote: > max_connections is a frequent point of contention between users and > developers. Users want to set it high so they don't have to deal with Yet > More Software (pgpool or pgBouncer); PG developers freak out because > backends are pretty

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 2:32 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: >>> Also, given that the idea of >>> DSA seems to be to support a number of different use-cases, I'm not >>>

Re: [HACKERS] Creating a DSA area to provide work space for parallel execution

On Thu, Dec 1, 2016 at 6:35 AM, Thomas Munro wrote: > On Sat, Nov 26, 2016 at 1:55 AM, Thomas Munro > wrote: >> Here's a new version to apply on top of dsa-v7.patch. > > Here's a version to go with dsa-v8.patch. Thomas has spent a

[HACKERS] Typmod associated with multi-row VALUES constructs

I looked into the issue reported in bug #14448, https://www.postgresql.org/message-id/20161205143037.4377.60754%40wrigleys.postgresql.org The core of it seems to be that expandRTE() will report the type and typmod of a column of a VALUES construct as being exprType() and exprTypmod() of the

[HACKERS] [sqlsmith] Crash in gather_readnext

Hi, on master as of a0ae54d, there's a 1 in 10e6 chance sqlsmith catches gather_readnext reading beyond the gatherstate->readers array with readers[gatherstate->readnext]. Sample backtrace below. As readnext is never explicitly initialized, I think what happens is that a rescan gets less

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Dec 6, 2016 at 1:28 AM, Mithun Cy wrote: > > *Clients * > > *Cache Meta Page patch * > > *Base code with amits changes* > > * %imp* > > 1 > > 17062.513102 > > 17218.353817 > > -0.9050848685 > > 8 > > 138525.808342 > > 128149.381759

Re: [HACKERS] Cache Hash Index meta page.

On Thu, Dec 1, 2016 at 8:10 PM, Jesper Pedersen wrote: >As the concurrent hash index patch was committed in 6d46f4 this patch needs a rebase. Thanks Jesper, Adding the rebased patch. I have re-run the pgbench readonly tests with below modification. "alter table

[HACKERS] Separate connection handling from backends

max_connections is a frequent point of contention between users and developers. Users want to set it high so they don't have to deal with Yet More Software (pgpool or pgBouncer); PG developers freak out because backends are pretty heavyweight, there's some very hot code that's sensitive to the

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

Robert Haas writes: > On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: >> Also, given that the idea of >> DSA seems to be to support a number of different use-cases, I'm not >> sure that it's useful to have a knob that limits the total consumption >>

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Dec 5, 2016 at 1:59 PM, Mithun Cy wrote: > On Mon, Dec 5, 2016 at 11:23 PM, Robert Haas wrote: >>I think that you need a restoreErrorMessage call here: >>/* Skip any remaining addresses for this host. */ >>

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Dec 5, 2016 at 12:41 PM, Tom Lane wrote: >>> Given your later argumentation, I wonder why we're trying to implement >>> any kind of limit at all,

Re: [HACKERS] missing optimization - column <> column

> > > Would it be worth replacing the condition with the equivalent? > I mean would that help optimizing better some queries when it knows that a > is (not) nullable or when "a" is more complicated expression? > > a <> a: (a IS NULL) AND NULL > a = a : (a IS NOT NULL) OR NULL > I

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Dec 5, 2016 at 11:23 PM, Robert Haas wrote: >I think that you need a restoreErrorMessage call here: >/* Skip any remaining addresses for this host. */ >conn->addr_cur = NULL; >if

Re: [HACKERS] Broken SSL tests in master

On Fri, Dec 2, 2016 at 9:18 AM, Mithun Cy wrote: >On Fri, Dec 2, 2016 at 2:26 AM, Robert Haas wrote: >>Yeah, we should change that. Are you going to write a patch? > Thanks, will work on this will produce a patch to patch to fix. This is

Re: [HACKERS] Add support for restrictive RLS policies

* Stephen Frost (sfr...@snowman.net) wrote: > Updated patch attached. Erp, actually attached this time. Thanks again! Stephen From 27e5fdac801cecc5ac33daccf979bbc59458dbbc Mon Sep 17 00:00:00 2001 From: Stephen Frost Date: Thu, 1 Sep 2016 02:11:30 -0400 Subject: [PATCH] Add

Re: [HACKERS] Add support for restrictive RLS policies

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > This note reads a little awkwardly to me. I think I would write it as: > > Note that ALTER POLICY only allows the set of roles > to which the policy applies and the USING and > WITH CHECK expressions to be modified. To change

Re: [HACKERS] strange case of kernel performance regression (4.3.x and newer)

On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra wrote: > Over the past couple of days I've been doing a bit of benchmarking for the > "group clog" patch [1], and I've ran into what I suspect might be a fairly > serious performance regression on newer kernels

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

Robert Haas writes: > On Mon, Dec 5, 2016 at 12:41 PM, Tom Lane wrote: >> Given your later argumentation, I wonder why we're trying to implement >> any kind of limit at all, rather than just operating on the principle >> that it's the kernel's problem

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 12:41 PM, Tom Lane wrote: > Robert Haas writes: >> It's not quite the same thing, because control->max_total_segment_size >> is a total of the memory used by all allocations plus the associated >> bookkeeping overhead, not the

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On 05/12/16 17:00, Mithun Cy wrote: [...] errorMessage even outside PQconnectPoll. But that seems not required. Attacting the new patch which fixes the same. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com [...] Is that meant to be

Re: [HACKERS] Indirect indexes

Haribabu Kommi wrote: > Closed in 2016-11 commitfest with "returned with feedback" status. What feedback? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Time to retire Windows XP buildfarm host?

Robert Haas writes: > pademelon is a good example. I don't mind keeping that working if Tom > is willing to maintain it, but here's the thing: if a certain > portability "problem" only shows up on machines running 20-year-old > operating systems, how much of a problem is

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Sun, Dec 4, 2016 at 11:00 PM, Mithun Cy wrote: > On Fri, Dec 2, 2016 at 8:54 PM, Robert Haas wrote: >> Couldn't this just be a variable in PQconnectPoll(), instead of adding >> a new structure member? > > I have fixed same with a local

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 05, 2016 at 11:52:57AM -0500, Tom Lane wrote: > Another point here is that packagers such as Red Hat strenuously dislike > such source-code-level wrapping of other projects, because that means that > they have to rebuild multiple packages to fix any bugs found in the > wrapped code.

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

Robert Haas writes: > It's not quite the same thing, because control->max_total_segment_size > is a total of the memory used by all allocations plus the associated > bookkeeping overhead, not the amount of memory used by a single > allocation. Really? Why doesn't it start

Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

On Sat, Dec 3, 2016 at 2:16 AM, Fabien COELHO wrote: >> My guess is that something comparable to where pgbench is would be a >> reasonable target --- not least because I think we should strive to >> reduce unnecessary differences between psql and pgbench metalanguages. >> >>

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Sat, Dec 3, 2016 at 10:30 AM, Dilip Kumar wrote: >> I'll post my new expression evaluation stuff - which doesn't do this >> atm, but makes ExecQual faster in other ways - later this week. If we >> could get the planner (or parse-analysis?) to set an OpExpr flag that >>

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 11:37 AM, Tom Lane wrote: >>> Introduce dynamic shared memory areas. > > gaur finds another problem with dsa.c: it uses SIZE_MAX which AFAICS > is not required to exist by POSIX. > > We could adopt the timezone code's workaround > > #ifndef SIZE_MAX >

Re: [HACKERS] Time to retire Windows XP buildfarm host?

On Mon, Dec 5, 2016 at 11:46 AM, Andres Freund wrote: > I think it might be good to introduce a general formal policy of > de-supporting platforms a year or three after their OS support > ended. I agree. If possible, I'd like it to be more like 3 years than 1 year but that

Re: [HACKERS] pg_dump / copy bugs with "big lines" ?

Daniel Verite wrote: > My tests are OK too but I see an issue with the code in > enlargeStringInfo(), regarding integer overflow. Rats. I'll have a look later. You're probably right. In the meantime I added this problem to the Open Items wiki page for pg10, which I just created:

Re: [HACKERS] Tackling JsonPath support

Robert Haas writes: > On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams wrote: >> What we do in Heimdal, OpenAFS, and other open source projects, some >> times, is include a copy / git submodule / similar of some such external >> dependencies. Naturally

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 5, 2016 at 11:42 AM, Nico Williams wrote: >> Library integrations are tricky but, since you wrote JQ and seem > > Just to be clear, Stephen Dolan wrote jq. I've added to, and maintained > jq, to be sure, but I would not want to take credit from Stephen. Ah,

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts

On Fri, Dec 2, 2016 at 10:04 PM, Amit Kapila wrote: >> Here we shouldn't be accessing meta page after releasing the lock as >> concurrent activity can change these values. This can be fixed by >> storing these values in local variables before releasing the lock and >>

Re: [HACKERS] The max value of autovacuum_vacuum/analyze_scale_factor.

On Mon, Dec 5, 2016 at 9:15 PM, Ashutosh Bapat wrote: > On Mon, Dec 5, 2016 at 4:44 PM, Masahiko Sawada wrote: >> Hi all, >> >> Is there any reason why the max values of >> autovacuum_vacuum/analyze_scale_factor are 100.0? These max values

Re: [HACKERS] Time to retire Windows XP buildfarm host?

Hi, On 2016-12-05 10:56:00 -0500, Andrew Dunstan wrote: > Windows XP has been past end of life for quite some time. Nevertheless I > have kept my instance running with three buildfarm members: frogmouth, > currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but I'm > not 100%

Re: [HACKERS] Tackling JsonPath support

On Mon, Dec 05, 2016 at 11:28:31AM -0500, Robert Haas wrote: > The overall need is that it needs to be possible for PostgreSQL to > throw an ERROR, and thus longjmp, without leaking resources. As long as one can interpose jump buffers, that should be possible. > Sometimes those errors happen

Re: [HACKERS] Time to retire Windows XP buildfarm host?

On 12/05/2016 11:17 AM, Tom Lane wrote: Andrew Dunstan writes: Windows XP has been past end of life for quite some time. Nevertheless I have kept my instance running with three buildfarm members: frogmouth, currawong and brolga. Howeever, a recent commit (apparently

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

>> Introduce dynamic shared memory areas. gaur finds another problem with dsa.c: it uses SIZE_MAX which AFAICS is not required to exist by POSIX. We could adopt the timezone code's workaround #ifndef SIZE_MAX #define SIZE_MAX ((size_t) -1) #endif but I don't find that particularly nice, and in

Re: [HACKERS] Hash Indexes

On Fri, Dec 2, 2016 at 10:54 PM, Amit Kapila wrote: > On Sat, Dec 3, 2016 at 12:13 AM, Robert Haas wrote: >> On Fri, Dec 2, 2016 at 1:54 AM, Amit Kapila wrote: I want to split when the average bucket contains 10

Re: [HACKERS] Tackling JsonPath support

On Fri, Dec 2, 2016 at 4:32 PM, Nico Williams wrote: > On Fri, Dec 02, 2016 at 08:53:33AM -0500, Robert Haas wrote: >> On Tue, Nov 29, 2016 at 11:50 AM, Christian Convey >> wrote: >> > I think I can satisfy (3) with a PG extension which provides

Re: [HACKERS] Time to retire Windows XP buildfarm host?

Andrew Dunstan writes: > Windows XP has been past end of life for quite some time. Nevertheless I > have kept my instance running with three buildfarm members: frogmouth, > currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but > I'm not 100% sure)

Re: [HACKERS] missing optimization - column <> column

On Mon, Dec 5, 2016 at 3:24 PM, Tom Lane wrote: > Pavel Stehule writes: > > I found some crazy queries in one customer application. These queries are > > stupid, but it was surprise for me so there are not some simple > optimization > > > create

Re: [HACKERS] [COMMITTERS] pgsql: Add max_parallel_workers GUC.

On Sat, Dec 3, 2016 at 11:43 AM, Tom Lane wrote: > Robert Haas writes: >> On Dec 2, 2016, at 5:45 PM, Tom Lane wrote: >>> Might work. We've had very bad luck with GUC variables with >>> interdependent defaults, but maybe the

[HACKERS] Time to retire Windows XP buildfarm host?

Windows XP has been past end of life for quite some time. Nevertheless I have kept my instance running with three buildfarm members: frogmouth, currawong and brolga. Howeever, a recent commit (apparently fa2fa99, but I'm not 100% sure) started causing a compiler segmentation fault on

Re: [HACKERS] missing optimization - column <> column

2016-12-05 16:41 GMT+01:00 Stephen Frost : > Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > 2016-12-05 16:23 GMT+01:00 Stephen Frost : > > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > > > I found some crazy queries in one customer

Re: [HACKERS] missing optimization - column <> column

Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2016-12-05 16:23 GMT+01:00 Stephen Frost : > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > > I found some crazy queries in one customer application. These queries are > > > stupid, but it was surprise for me so

Re: [HACKERS] missing optimization - column <> column

2016-12-05 16:23 GMT+01:00 Stephen Frost : > Pavel, > > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > I found some crazy queries in one customer application. These queries are > > stupid, but it was surprise for me so there are not some simple > optimization > > > >

Re: [HACKERS] missing optimization - column <> column

2016-12-05 16:24 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > I found some crazy queries in one customer application. These queries are > > stupid, but it was surprise for me so there are not some simple > optimization > > > create table foo(a

Re: [HACKERS] missing optimization - column <> column

Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > I found some crazy queries in one customer application. These queries are > stupid, but it was surprise for me so there are not some simple optimization > > create table foo(a int); > insert into foo select generate_series(1,10); >

Re: [HACKERS] missing optimization - column <> column

Pavel Stehule writes: > I found some crazy queries in one customer application. These queries are > stupid, but it was surprise for me so there are not some simple optimization > create table foo(a int); > insert into foo select generate_series(1,10); > analyze foo;

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 10:09 AM, Tom Lane wrote: > Michael Paquier writes: >> This commit is generating a warning when compiling on my Win7 dev box: > > dromedary has this: > > ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith >

[HACKERS] missing optimization - column <> column

Hi I found some crazy queries in one customer application. These queries are stupid, but it was surprise for me so there are not some simple optimization create table foo(a int); insert into foo select generate_series(1,10); analyze foo; explain select * from foo where a <> a; It does full

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

Robert Haas writes: > Hmm, I'm not sure I understand that warning. I think the complaint is > about this line of code: > Sizethreshold = 1 << (bin - 1); > "bin" is declared as "Size", and threshold is also declared as "Size", > so what's the problem? The

Re: [HACKERS] Random number generation, take two

Heikki Linnakangas writes: > Tom: I expect pademelon to fail at the configure step, complaining that > "no source of strong random numbers was found". Let's wait for one > cycle, to verify that it does fail like that. After that, can you add > the --disable-strong-random flag

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 7:18 AM, Michael Paquier wrote: > On Fri, Dec 2, 2016 at 9:36 AM, Robert Haas wrote: >> Introduce dynamic shared memory areas. >> >> Programmers discovered decades ago that it was useful to have a simple >> interface for

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

Michael Paquier writes: > This commit is generating a warning when compiling on my Win7 dev box: dromedary has this: ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security

Re: [HACKERS] Dynamic shared memory areas

On Fri, Dec 2, 2016 at 3:46 PM, Thomas Munro wrote: > Here's a patch to provide the right format string for dsa_pointer to > printf-like functions, which clears a warning coming from dsa_dump (a > debugging function) on 32 bit systems. Committed. -- Robert Haas

Re: [HACKERS] commitfest 2016-11 status summary

* Amit Kapila (amit.kapil...@gmail.com) wrote: > On Mon, Dec 5, 2016 at 11:56 AM, Michael Paquier > wrote: > > On Mon, Dec 5, 2016 at 2:50 PM, Haribabu Kommi > > wrote: > >> I definitely may missed judging the current state of the patch.

Re: [HACKERS] raw output from copy

Hi 2016-12-05 14:19 GMT+01:00 Kohei KaiGai : > Sorry for my late response. > > I've briefly checked a series of discussion in the past. > I understood the target/purpose of this patch is provision of a fast > interface > to import/export a particular cell of a relation, by

Re: [HACKERS] raw output from copy

Sorry for my late response. I've briefly checked a series of discussion in the past. I understood the target/purpose of this patch is provision of a fast interface to import/export a particular cell of a relation, by skip of text<->binary transformation. Its typical use case are XML and JSON data

Re: [HACKERS] Document how to set up TAP tests for Perl 5.8.8

On 5 December 2016 at 19:17, Dagfinn Ilmari Mannsåker wrote: > This is not the correct invocation of cpanm: it just takes a list of > module names. This will pull in the 'install' module, which is > harmless, but unnecessary: https://metacpan.org/pod/install. Ha. Good catch.

[HACKERS] Re: [HACKERS] Re: [HACKERS] 答复: [HACKERS] postgres 1 个(共 2 个) can pg 9.6 vacuum freeze skip page on index?

On Fri, Dec 2, 2016 at 3:50 AM, Robert Haas wrote: > On Thu, Dec 1, 2016 at 1:39 PM, Tom Lane wrote: >> Robert Haas writes: >>> I think that the indexes only need to be scanned if the VACUUM finds >>> dead tuples. But even 1

Re: [HACKERS] [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Fri, Dec 2, 2016 at 9:36 AM, Robert Haas wrote: > Introduce dynamic shared memory areas. > > Programmers discovered decades ago that it was useful to have a simple > interface for allocating and freeing memory, which is why malloc() and > free() were invented.

Re: [HACKERS] The max value of autovacuum_vacuum/analyze_scale_factor.

On Mon, Dec 5, 2016 at 4:44 PM, Masahiko Sawada wrote: > Hi all, > > Is there any reason why the max values of > autovacuum_vacuum/analyze_scale_factor are 100.0? These max values are > defined since when the parameters has been introduced but I think that > 1.0 is enough.

Re: [HACKERS] Random number generation, take two

On Mon, Dec 5, 2016 at 8:45 PM, Heikki Linnakangas wrote: > On 11/30/2016 03:22 PM, Michael Paquier wrote: >> I could live with that. Your patch is not complete though, you need to >> add pg_strong_random.c into the array @pgportfiles in Mkvcbuild.pm. >> You also need to remove

  1   2   >