Re: [HACKERS] installcheck failing on psql_crosstab

On Tue, Jun 7, 2016 at 12:31 PM, Michael Paquier wrote: > On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera > wrote: >> Tom Lane wrote: >>> Alvaro Herrera writes: >> >>> > I can't imagine that the server is avoiding

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

On Fri, Jun 3, 2016 at 11:25 PM, Tom Lane wrote: > Michael Paquier writes: >> Actually, the docs could be more polished. > > I think the docs could stand to be rewritten from scratch ;-). But > upthread there was an offer to work on them if we made

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 03, 2016 at 12:31:44PM -0400, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > > > If a database with the bloom extension installed is dumped and restored, > > > there's an error with

Re: [HACKERS] COMMENT ON, psql and access methods

On Tue, Jun 7, 2016 at 7:35 AM, Alvaro Herrera wrote: > In looking at the DROP ACCESS METHOD completion I noticed that the > words_after_create gadget is a bit buggy: for things with more than one > word in the thing name (such as MATERIALIZED VIEW, USER MAPPING FOR, >

Re: [HACKERS] parallel.c is not marked as test covered

Thanks for this patch. I have reviewed it: On Sun, May 15, 2016 at 12:53:13PM +, Clément Prévost wrote: > After some experiments, I found out that, for my setup (9b7bfc3a88ef7b), a > parallel seq scan is used given both parallel_setup_cost > and parallel_tuple_cost are set to 0 and given

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

At Mon, 06 Jun 2016 11:12:14 -0400, Tom Lane wrote in <17504.1465225...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in > > <11515.1464961...@sss.pgh.pa.us> > >> I

Re: [HACKERS] Typos/Questions in bloom documentation

On Fri, Apr 22, 2016 at 1:25 AM, David G. Johnston wrote: > On Wed, Apr 20, 2016 at 9:18 PM, Amit Langote > wrote: >> I agree it's unclear. Does the following make it any better (updated >> patch attached): I have sent a patch to

Re: [HACKERS] OUT parameter and RETURN table/setof

Existing application code written to call function in Oracle which return no.of rows in out parameter and return-values is cursor-result this need migrate to PostgreSQL, need help here example: (actual function declaration only) *Oracle:* CREATE OR REPLACE PROCEDURE sc_getapppermissionlist (

Re: [HACKERS] IPv6 link-local addresses and init data type

On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane wrote: > Robert Haas writes: >> Yeah, but what if somebody doesn't want to store scopes? > > [ shrug... ] We can invent a "strip_scope()" sort of function, > analogous to the weight-stripping function for

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 6:55 AM, Michael Paquier wrote: > On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote: >> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: Stephen, something is smelling wrong in

Re: [HACKERS] installcheck failing on psql_crosstab

On Tue, Jun 7, 2016 at 12:28 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Alvaro Herrera writes: > >> > I can't imagine that the server is avoiding hash aggregation on a 1MB >> > work_mem limit for data that's a few dozen of bytes. Is it

Re: [HACKERS] Prepared statements and generic plans

Bruce Momjian wrote: > OK, updated version attached. I added "potential" to the first > paragraph, and added "estimated cost" to the later part, fixed the > "cheaper than", and clarified that we add the plan time cost to the > non-generic plan, which is how it can be cheaper than the generic

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada wrote: > On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote: >> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote: >>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 6:34 PM, Robert Haas wrote: > On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier > wrote: >>> Attached is a sample patch that controls full page vacuum by new GUC >>> parameter. >> >> Don't we want a reloption for that? Just

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Sun, Jun 5, 2016 at 11:16 PM, Tom Lane wrote: > Michael Paquier writes: >> Still, on back branches I think that it would be a good idea to have a >> better error message for the ones that already throw an error, like >> "trigger with OID %u does

[HACKERS] installcheck failing on psql_crosstab

Hi all, With a low value of work_mem, like 1MB, I am noticing that the new psql_crosstab is generating a couple of diffs with installcheck (tested only on OSX 10.11): *** *** 127,134 \crosstabview v h i v | h0 | h1 | h2 | h4 | #null#

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier wrote: >> Attached is a sample patch that controls full page vacuum by new GUC >> parameter. > > Don't we want a reloption for that? Just wondering... Why? Just for consistency? I think the bigger question here is

Re: [HACKERS] Reviewing freeze map code

On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote: > On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas wrote: >> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada >> wrote: Can you submit that part as a separate patch? >>>

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

How about silencing the workers on termination? # Build on Windows (with VC?) is very time consuming... At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in <11515.1464961...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > For sure, any of

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

On Sat, Jun 4, 2016 at 1:53 AM, Robert Haas wrote: > > On Thu, May 12, 2016 at 2:07 PM, Tom Lane wrote: > >> Err, wow. That makes my head hurt. Can you explain why this case > >> only arises for appendrel children, and not for plain rels? > > > >

[HACKERS] parallel workers and client encoding

There appears to be a problem with how client encoding is handled in the communication from parallel workers. In a parallel worker, the client encoding setting is inherited from its creating process as part of the GUC setup. So any plain-text stuff the parallel worker sends to its leader is

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 7:46 AM, Robert Haas wrote: > On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada > wrote: >> Attached updated patch. > > The error-checking enhancements here look good to me, except that you > forgot to initialize

Re: [HACKERS] Reviewing freeze map code

On Sat, Jun 4, 2016 at 12:18 AM, Masahiko Sawada wrote: > Attached updated patch. The error-checking enhancements here look good to me, except that you forgot to initialize totalBytesRead. I've committed those changes with a fix for that problem and will look at the rest

[HACKERS] OUT parameter and RETURN table/setof

Hi Is there any option in PGPLSQL which can RETURNS table or SETOF rows along with an OUT parameter? please Thanks Sridhar OpenText

Re: [HACKERS] OUT parameter and RETURN table/setof

On Mon, Jun 6, 2016 at 7:17 AM, Sridhar N Bamandlapally < sridhar@gmail.com> wrote: > Hi > > Is there any option in PGPLSQL which can RETURNS table or SETOF rows along > with an OUT parameter? > > ​No, there would be no point given the internals of how functions work. ​What is it you are

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Sat, Jun 4, 2016 at 10:45 PM, David G. Johnston wrote: > On Tuesday, March 22, 2016, Merlin Moncure wrote: >> >> >> Anyways, here's the patch with documentation adjustments as promised. >> I ended up keeping the 'without result' section because

Re: [HACKERS] Typo in parallel comment of heap_delete()

On Sun, Jun 5, 2016 at 4:39 PM, Jim Nasby wrote: > I'm pretty sure this is a typo... Sure is. Thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Reviewing freeze map code

Masahiko Sawada writes: > On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada wrote: >> So other idea is to have GUC parameter, vacuum_even_frozen_page for example. >> If this parameter is set true (false by default), we do vacuum whole >> table forcibly

Re: [HACKERS] Rename synchronous_standby_names?

On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut wrote: > On 5/31/16 1:47 PM, Jaime Casanova wrote: >> >> Are we going to change synchronous_standby_names? Certainly the GUC is >> not *only* a list of names anymore. >> >> synchronous_standby_config? >>

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: > We should consider single and multiple SRFs in a targetlist as distinct > use-cases; only the latter has got weird properties. > > There are several things we could potentially do with multiple SRFs in > the same targetlist.

Re: [HACKERS] installcheck failing on psql_crosstab

Michael Paquier wrote: > I know that we guarantee that make installcheck may not work on many > target servers as a lot of tests are very GUC-sensitive, but this > looks a bit oversensitive to me, especially knowing that it is the > only diff generated by the whole test suite. > Don't you think

Re: [HACKERS] Reviewing freeze map code

Robert Haas wrote: > My gut feeling on this is to either do nothing or add a VACUUM option > (not a GUC, not a reloption) called even_frozen_pages, default false. > What is your opinion? +1 for that approach -- I thought that was already agreed weeks ago and the only question was what to name

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

On Thu, Jun 2, 2016 at 4:48 PM, Corey Huinker wrote: > A while back, there was a push to make COPY gzip-aware. That didn't happen, > but COPY FROM PROGRAM did, and it scratches the same itch. > > I have a similar need, but with file_fdw foreign tables. I have .csv.gz >

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > At Fri, 03 Jun 2016 09:44:30 -0400, Tom Lane wrote in > <11515.1464961...@sss.pgh.pa.us> >> I think that this one: >>> If the target thread is allocating memory from the heap, the heap >>> lock will not be

Re: [HACKERS] Prepared statements and generic plans

On Mon, Jun 6, 2016 at 07:19:37AM +, Albe Laurenz wrote: > Bruce Momjian wrote: > > OK, updated version attached. I added "potential" to the first > > paragraph, and added "estimated cost" to the later part, fixed the > > "cheaper than", and clarified that we add the plan time cost to the >

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote: > On 2016-06-06 05:34:32 -0400, Robert Haas wrote: >> On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier >> wrote: >> >> Attached is a sample patch that controls full page vacuum by new GUC >> >>

Re: [HACKERS] Reviewing freeze map code

On 2016-06-06 11:37:25 -0400, Robert Haas wrote: > On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote: > > Except that we right now don't have any realistic way to figure out > > whether this new feature actually does the right thing. Which makes > > testing this

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote: > Masahiko Sawada writes: >> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada >> wrote: >>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example. >>> If this

Re: [HACKERS] installcheck failing on psql_crosstab

Alvaro Herrera writes: > Michael Paquier wrote: >> I know that we guarantee that make installcheck may not work on many >> target servers as a lot of tests are very GUC-sensitive, but this >> looks a bit oversensitive to me, especially knowing that it is the >> only diff

Re: [HACKERS] COMMENT ON, psql and access methods

Noah Misch wrote: > The above-described topic is currently a PostgreSQL 9.6 open item. Álvaro, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > 9.6 open item, please let us know.

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 10:18 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> My gut feeling on this is to either do nothing or add a VACUUM option >> (not a GUC, not a reloption) called even_frozen_pages, default false. >> What is your opinion? > > +1 for that approach

Re: [HACKERS] TESTING in src/bin/pg_upgrade has incorrect documentation

On Thu, Jun 2, 2016 at 12:35 PM, Andreas 'ads' Scherbaum wrote: > the TESTING file in src/bin/pg_upgrade talks about a "check.sh script", but > this seems to be a binary (check) now. Nope: [rhaas pgsql]$ git grep -F check.sh [rhaas pgsql]$ -- Robert Haas EnterpriseDB:

[HACKERS] Why we don't have checksums on clog files

Hello! Why we don't have checksums on clog files. We have checksum on pg_control, optional checksumming on data files, some form of checksumming on wal's. But why we don't have any checksumming on clogs. Corruptions on clogs lead to transaction visisbility problems and database consistency

Re: [HACKERS] installcheck failing on psql_crosstab

Tom Lane wrote: > Alvaro Herrera writes: > > Michael Paquier wrote: > >> I know that we guarantee that make installcheck may not work on many > >> target servers as a lot of tests are very GUC-sensitive, but this > >> looks a bit oversensitive to me, especially knowing

Re: [HACKERS] Reviewing freeze map code

Robert Haas writes: > I'm intuitively sympathetic to the idea that we should have an option > for this, but I can't figure out in what case we'd actually tell > anyone to use it. It would be useful for the kinds of bugs listed > above to have VACUUM (rebuild_vm) to blow

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: >> Stephen, something is smelling wrong in checkExtensionMembership() >> since 5d58999, an access method does not have ACLs and I would have >> expected that when this routine is invoked in >> selectDumpableAccessMethod()

[HACKERS] Improve tab completion for USER MAPPING

Hi all, I found that the tab completion for USER MAPPING doesn't work fine. For example, The below is no problem. postgres=# create user[TAB] user user mapping for But this doesn't work fine. (Note that there is a white space between 'user' and [TAB]) postgres=# create user [TAB]

Re: [HACKERS] installcheck failing on psql_crosstab

Tom Lane wrote: > Alvaro Herrera writes: > > I can't imagine that the server is avoiding hash aggregation on a 1MB > > work_mem limit for data that's a few dozen of bytes. Is it really doing > > that? > > Yup: Aha. Thanks for testing. > Now that you mention it,

Re: [HACKERS] Reviewing freeze map code

Robert Haas writes: > On Mon, Jun 6, 2016 at 11:28 AM, Andres Freund wrote: >> Except that we right now don't have any realistic way to figure out >> whether this new feature actually does the right thing. > I just don't see how running VACUUM on the

Re: [HACKERS] installcheck failing on psql_crosstab

I wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Presumably what is happening is that the planner is switching from hash >>> to sort aggregation. >> I can't imagine that the server is avoiding hash aggregation on a 1MB >> work_mem limit for data that's a few

Re: [HACKERS] Reviewing freeze map code

On 2016-06-06 05:34:32 -0400, Robert Haas wrote: > On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier > wrote: > >> Attached is a sample patch that controls full page vacuum by new GUC > >> parameter. > > > > Don't we want a reloption for that? Just wondering... > > Why?

Re: [HACKERS] New design for FK-based join selectivity estimation

Tomas Vondra writes: > One of the recent issues with the current design was handling of > inheritance / appendrels. ISTM the proposed design has the same issue, > no? What happens if the relations are partitioned? I haven't thought about inheritance in this

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

... BTW, another thought occurred to me yesterday: it seems like the existing code hasn't thought through its behavior for multiple foreign keys very carefully. That is, suppose we have both "A.J references B.K" and "A.X references B.Y", as separate FKs not a single multicolumn FK. The current

Re: [HACKERS] Changed SRF in targetlist handling

On 06/06/16 18:30, David G. Johnston wrote: > To clarify, the present behavior is basically a combination of both of > Robert's results. > > If the SRFs return the same number of rows the first (zippered) result > is returned without an NULL padding. > > If the SRFs return a different number of

Re: [HACKERS] Changed SRF in targetlist handling

"David G. Johnston" writes: > If the SRFs return a different number of rows the LCM behavior kicks in and > you get Robert's second result. Only if the periods of the SRFs are relatively prime. That is, neither of his examples demonstrate the full weirdness of the

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On 06/06/2016 06:15 PM, Tom Lane wrote: Tomas Vondra writes: On 06/04/2016 08:15 PM, Tom Lane wrote: * Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs, not just constraint OIDs. It's insane that the relcache scans pg_constraint to collect

Re: [HACKERS] Changed SRF in targetlist handling

Robert Haas writes: > On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: >> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would >> have the same behavior as before if the SRFs all return the same number >> of rows, and otherwise would

Re: [HACKERS] Prepared statements and generic plans

On Mon, Jun 6, 2016 at 11:45 AM, Bruce Momjian *EXTERN* wrote: > > One more thing --- there was talk of moving some of this into chapter > 66, but as someone already mentioned, there are no subsections there > because it is a dedicated topic: > > 66. How the Planner

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote: > Robert Haas writes: > > On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: > >> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would > >> have the same behavior as

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

I'm fine with the code being released under the PostgreSQL license. Thanks, Adam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Tomas Vondra writes: > On 06/04/2016 08:15 PM, Tom Lane wrote: >> * Make RelationGetFKeyList cache a list of ForeignKeyOptInfo structs, >> not just constraint OIDs. It's insane that the relcache scans >> pg_constraint to collect those OIDs and then the planner

Re: [HACKERS] Reviewing freeze map code

Robert Haas writes: > On Mon, Jun 6, 2016 at 9:53 AM, Tom Lane wrote: >> Taking out GUCs is not >> easier than taking out statement parameters; you risk breaking >> applications either way. > Agreed, but that doesn't really answer the question of which

Re: [HACKERS] Reviewing freeze map code

On Fri, Jun 3, 2016 at 11:41 PM, Robert Haas wrote: > (Status update for Noah: I expect Masahiko Sawada will respond > quickly, but if not I'll give some kind of update by Monday COB > anyhow.) I believe this open item is now closed, unless Andres has more comments or

Re: [HACKERS] installcheck failing on psql_crosstab

Alvaro Herrera writes: > Tom Lane wrote: >> Presumably what is happening is that the planner is switching from hash >> to sort aggregation. > I can't imagine that the server is avoiding hash aggregation on a 1MB > work_mem limit for data that's a few dozen of bytes. Is

Re: [HACKERS] Changed SRF in targetlist handling

Robert Haas writes: > ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1. > I really don't like #1 much - I think I'd almost rather do nothing. FWIW, that's about my evaluation of the alternatives as well. I fear that #1 would get a lot of pushback. If we think

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote: >> > Why would they have to write the complex query? Wouldn't they just >> > need to run that we wrote for them? > > Then write that query. Verify that that query performs halfway > reasonably fast. Document that it should

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 2:31 PM, Alvaro Herrera wrote: > Robert Haas wrote: > > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote: > > > Robert Haas writes: > > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 2:53 PM, Tom Lane wrote: > Now, if we decide to try to rewrite tlist SRFs as LATERAL, it would likely > behoove us to do that rewrite before expanding * not after, so that we can > eliminate the multiple evaluation of foo() that happens currently. (That

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Fri, Jun 3, 2016 at 11:13 PM, Robert Haas wrote: >> I think the workers should stop processing tuples after the tuple queues got >> detached. This will not only handle above situation gracefully, but will >> allow to speed up the queries where Limit clause is present on

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

I wrote: > Tomasz Ostrowski writes: >> I suppose this is a bug - an analyze, which does not analyze all >> columns, should not reset pg_stat_user_tables(n_mod_since_analyze). What >> do you think? > I'm inclined to think that this is a reasonable complaint. A usage >

Re: [HACKERS] Reviewing freeze map code

Hi, On 2016-06-06 15:16:10 -0400, Robert Haas wrote: > On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote: > >> > Why would they have to write the complex query? Wouldn't they just > >> > need to run that we wrote for them? > > > > Then write that query. Verify that that

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Sat, Jun 4, 2016 at 2:57 AM, Amit Kapila wrote: > In the above change, you are first adding bytes_written and then doing the > SHM_MQ_DETACHED check, whereas other place the check is done first which > seems to be right. I think it doesn't matter either way, but it is

Re: [HACKERS] Changed SRF in targetlist handling

Alvaro Herrera writes: > Robert Haas wrote: >> On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote: >>> No, because then you get the cross-product of multiple SRFs, not the >>> run-in-lockstep behavior. >> Oh. I assumed that was the expected behavior.

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would >>> have the same behavior as before

Re: [HACKERS] hstore: add hstore_length function

On Fri, Jun 3, 2016 at 7:58 AM, Korbin Hoffman wrote: > > Hi there- > > I've attached a small patch exposing HS_COUNT to the user as > "hstore_length(hstore)". Documentation, upgrade sql files, and a few > tests are also included. > > Almost every hstore function calls HS_COUNT, but I

Re: [HACKERS] Changed SRF in targetlist handling

Robert Haas wrote: > On Mon, Jun 6, 2016 at 11:50 AM, Tom Lane wrote: > > Robert Haas writes: > >> On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote: > >>> 2. Rewrite into LATERAL ROWS FROM (srf1(), srf2(), ...). This would > >>>

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On 06/06/2016 07:40 PM, Tom Lane wrote: Tomas Vondra writes: On 06/06/2016 06:15 PM, Tom Lane wrote: This checks that you found a joinclause mentioning foreignrel. But foreignrel need have nothing to do with the foreign key; it could be any table in the query.

Re: [HACKERS] Reviewing freeze map code

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote: > >> In terms of diagnostic tools, you can get the VM bits and > >> page-level bits using the pg_visibility extension; I wrote it > >> precisely because of concerns like the

Re: [HACKERS] Reviewing freeze map code

On 2016-06-06 14:24:14 -0400, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: > > On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote: > > >> In terms of diagnostic tools, you can get the VM bits and > > >> page-level bits using the pg_visibility

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Tomas Vondra writes: > On 06/06/2016 06:15 PM, Tom Lane wrote: >> This checks that you found a joinclause mentioning foreignrel. But >> foreignrel need have nothing to do with the foreign key; it could be any >> table in the query. > I don't follow. How could it

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

[ redirecting to -hackers ] Tomasz Ostrowski writes: > I'm routinely bulk inserting data to a PostgreSQL table and then > analyzing a single column of the table, because it contains data which > significantly changes histogram of this column values - for example >

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Tomas Vondra writes: > When it comes to improving multiple (multi-column) foreign keys, I think > it may get way more complicated that it might seem. What if the foreign > keys overlap, for example? Or what if the keys go in opposite directions > (cycle). And so

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

On 06/06/2016 06:34 PM, Tom Lane wrote: ... BTW, another thought occurred to me yesterday: it seems like the existing code hasn't thought through its behavior for multiple foreign keys very carefully. That is, suppose we have both "A.J references B.K" and "A.X references B.Y", as separate FKs

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund wrote: >> In terms of diagnostic tools, you can get the VM bits and >> page-level bits using the pg_visibility extension; I wrote it >> precisely because of concerns like the ones you raise here. If you >> want to cross-check the

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 4:06 PM, Andres Freund wrote: >> I do appreciate you reviewing this code, very much, and genuinely, and >> it would be great if more people wanted to review it. > >> But this kind of reads like you think that I'm being a jerk, which I'm >> trying pretty

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote: >> > Why would they have to write the complex query? Wouldn't they just >> > need to run that we wrote for them? > > Then write that query. Verify that that query performs halfway > reasonably fast. Document that it should

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 4:27 PM, Andres Freund wrote: > On 2016-06-06 16:18:19 -0400, Stephen Frost wrote: >> That could be as simple as a query with the right things installed, or >> it might be an independent tool, but not having any way to check isn't >> good. That said,

Re: [HACKERS] [BUGS] Routine analyze of single column prevents standard autoanalyze from running at all

On 06/06/2016 01:38 PM, Tom Lane wrote: > Also, I'd be a bit inclined to disable the counter reset whenever a column > list is specified, disregarding the corner case where a list is given but > it includes all the table's analyzable columns. It doesn't really seem > worth the effort to account

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 11:35 AM, Andres Freund wrote: >> We need a read-only utility which checks that the system is in a correct >> and valid state. There are a few of those which have been built for >> different pieces, I believe, and we really should have one for the >>

Re: [HACKERS] Reviewing freeze map code

On Mon, Jun 6, 2016 at 5:06 PM, Andres Freund wrote: > On 2016-06-06 16:41:19 -0400, Robert Haas wrote: >> I really don't understand how you can not weigh in on the original >> thread leading up to my mid-March commits and say "hey, this needs a >> better testing tool", and

Re: [HACKERS] Reviewing freeze map code

Hi, On 2016-06-06 17:22:38 -0400, Robert Haas wrote: > > I'd also be ok with adding & documenting (beta release notes) > > CREATE EXTENSION pg_visibility; > > SELECT relname FROM pg_class WHERE relkind IN ('r', 'm') AND NOT > > pg_check_visibility(oid); > > or something olong those lines. > >

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote: > Robert Haas writes: >> ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1. >> I really don't like #1 much - I think I'd almost rather do nothing. > > FWIW, that's about my evaluation of the

Re: [HACKERS] Reviewing freeze map code

On 2016-06-06 16:41:19 -0400, Robert Haas wrote: > I really don't understand how you can not weigh in on the original > thread leading up to my mid-March commits and say "hey, this needs a > better testing tool", and then when you finally get around to > reviewing it in May, I'm supposed to drop

Re: [HACKERS] Reviewing freeze map code

Hi, On 2016-06-06 17:00:19 -0400, Robert Haas wrote: > 1. I think it is pretty misleading to say that those checks aren't > reachable any more. It's not like we freeze every page when we mark > it all-visible. True. What I mean is that you can't force the checks (and some that I think should

Re: [HACKERS] Reviewing freeze map code

Andres, all, * Andres Freund (and...@anarazel.de) wrote: > On 2016-06-06 15:16:10 -0400, Robert Haas wrote: > > On Mon, Jun 6, 2016 at 2:35 PM, Andres Freund wrote: > > and like you have the right to tell assign me arbitrary work, which I > > think you don't. > > It's not

Re: [HACKERS] Reviewing freeze map code

On 2016-06-06 16:18:19 -0400, Stephen Frost wrote: > That could be as simple as a query with the right things installed, or > it might be an independent tool, but not having any way to check isn't > good. That said, trying to make VACUUM do that doesn't make sense to me > either. The point is

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Jun 6, 2016 at 3:26 PM, Tom Lane wrote: > Robert Haas writes: > > ... I guess I'd prefer #2 to #2.5, #2.5 to #3, and #3 to #1. > > I really don't like #1 much - I think I'd almost rather do nothing. > > FWIW, that's about my evaluation of the

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: >>> Stephen, something is smelling wrong in checkExtensionMembership() >>> since 5d58999, an access method does not have ACLs and I would have

Re: [HACKERS] COMMENT ON, psql and access methods

Michael Paquier wrote: > On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier > wrote: > > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier > > wrote: > >> I have added an open item for 9.6 regarding this patch, that would be > >> good to complete

Re: [HACKERS] hstore: add hstore_length function

Thanks for the review, Fabrízio. Attached is the updated patch, rebased and tested against master. I integrated feedback from your first point and am no longer HS_POLLUTE'ing the namespace for the new function. With regards to your second point- I've been maintaining consistency with the rest

  1   2   >