Re: [HACKERS] parallelize queries containing initplans

On Wed, Oct 11, 2017 at 9:24 PM, Robert Haas wrote: > On Mon, Oct 9, 2017 at 5:56 AM, Amit Kapila wrote: >> How about always returning false for PARAM_EXTERN? > > Yeah, I think that's what we should do. Let's do that first as a > separate patch,

[HACKERS] Parallel safety for extern params

As discussed in a nearby thread [1] (parallelize queries containing initplans), it appears that there are cases where queries referring PARAM_EXTERN params are treated as parallel-restricted even though they should be parallel-safe. I have done some further investigation and found that actually

Re: [HACKERS] Still another race condition in recovery TAP tests

On Fri, Oct 06, 2017 at 05:57:24PM +0800, Craig Ringer wrote: > On 6 October 2017 at 14:03, Noah Misch wrote: > > On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote: > >> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's > >> a better implementation

Re: [HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended

On Thu, Oct 12, 2017 at 10:47 PM, Amit Kapila wrote: > Today, I was trying to think about cases when we can return BLK_DONE > in XLogReadBufferForRedoExtended. One thing that occurred to me is > that it can happen during the replay of WAL if the full_page_writes is >

Re: [HACKERS] Log LDAP "diagnostic messages"?

On Fri, Oct 13, 2017 at 3:59 PM, Peter Eisentraut wrote: > On 9/24/17 07:00, Thomas Munro wrote: >> Fair point. In that case there are a few others we should consider >> moving down too for consistency, like in the attached. > >> Thanks, that is much tidier.

Re: [HACKERS] oversight in EphemeralNamedRelation support

Thomas Munro writes: > On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote: >> Yeah, I agree --- personally I'd never write a query like that. But >> the fact that somebody ran into it when v10 has been out for barely >> a week suggests that

Re: [HACKERS] oversight in EphemeralNamedRelation support

On Fri, Oct 13, 2017 at 12:46 PM, Tom Lane wrote: > Thomas Munro writes: >> On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote: >>> The CTE was simply not part of the available namespace for the INSERT's >>> target, so it

Re: [HACKERS] Log LDAP "diagnostic messages"?

On 9/24/17 07:00, Thomas Munro wrote: > Fair point. In that case there are a few others we should consider > moving down too for consistency, like in the attached. > Thanks, that is much tidier. Done that way in the attached. > > Here also is a small addition to your TAP test which exercises

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Thu, Oct 12, 2017 at 9:46 PM, Robert Haas wrote: > On Wed, Oct 11, 2017 at 7:08 AM, Ashutosh Bapat > wrote: >> Here's updated patch set based on the basic partition-wise join >> committed. The patchset applies on top of the patch to

Re: [HACKERS] Slow synchronous logical replication

On 12 October 2017 at 16:09, Konstantin Knizhnik wrote: > > Is the CREATE TABLE and INSERT done in the same transaction? > > No. Table was create in separate transaction. > Moreover the same effect will take place if table is create before start of > replication. >

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

On Thu, Oct 12, 2017 at 10:49 PM, Robert Haas wrote: > On Wed, Oct 11, 2017 at 10:43 PM, Ashutosh Bapat > wrote: >> You are suggesting that a dummy partitioned table be treated as an >> un-partitioned table and apply above suggested

Re: [HACKERS] replace GrantObjectType with ObjectType

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_* > symbols is not useful and leads to duplication. Digging around in the > past suggests that we used to have a lot of these command-specific > symbols but got

Re: [HACKERS] Discussion on missing optimizations

Laurenz, * Laurenz Albe (laurenz.a...@cybertec.at) wrote: > Robert Haas wrote: > > One trick that some system use is avoid replanning as much as we do > > by, for example, saving plans in a shared cache and reusing them even > > in other sessions. That's hard to do in our architecture because

Re: [HACKERS] postgres_fdw super user checks

Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Oct 5, 2017 at 1:02 PM, Jeff Janes wrote: > > I don't see a reason to block a directly-logged-in superuser from using a > > mapping. I asked in the closed list whether the current (released) > > behavior

Re: [HACKERS] Pluggable storage

On Thu, Oct 12, 2017 at 8:00 PM, Haribabu Kommi wrote: > Currently I added a snapshot_satisfies API to find out whether the tuple > satisfies the visibility or not with different types of visibility routines. > I feel these > are some how enough to develop a different

[HACKERS] Determine state of cluster (HA)

-Hackers, I had a long call with a firm developing front end proxy/cache/HA for Postgres today. Essentially the software is a replacement for PGPool in entirety but also supports analytics etc... When I was asking them about pain points they talked about the below and I was wondering if this

Re: [HACKERS] UPDATE of partition key

On 2017/10/13 6:18, Robert Haas wrote: > Is anybody still reviewing the main patch here? (It would be good if > the answer is "yes".) I am going to try to look at the latest version over the weekend and early next week. Thanks, Amit -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Continuous integration on Windows?

On 10/12/2017 06:46 PM, Thomas Munro wrote: > On Fri, Oct 13, 2017 at 10:57 AM, Andrew Dunstan > wrote: >> Actually, that didn't take too long. >> >> No testing yet, but this runs a build successfully: >>

Re: [HACKERS] Optimise default partition scanning while adding new partition

On 2017/10/13 4:18, Robert Haas wrote: > On Thu, Oct 5, 2017 at 9:29 PM, Amit Langote > wrote: >> Attached a patch to modify the INFO messages in check_default_allows_bound. > > Committed. However, I didn't see a reason to adopt the comment change > you proposed,

Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

David Rowley writes: > On 13 October 2017 at 12:41, Tom Lane wrote: >> Yeah, we would probably also want to check the flag in nodeWindowAgg. >> Not sure exactly how that should play out --- maybe we end up with >> a tri-valued property "works as

Re: [HACKERS] Pluggable storage

On Fri, Oct 13, 2017 at 8:23 AM, Robert Haas wrote: > On Thu, Oct 12, 2017 at 4:38 PM, Alexander Korotkov > wrote: > > It's probably that we imply different meaning to "MVCC implementation". > > While writing "MVCC implementation" I meant that,

Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

On 13 October 2017 at 12:41, Tom Lane wrote: > David Rowley writes: >> If the user defines their normal aggregate as not safe for merging, >> then surely it'll not be suitable to be used as a window function >> either, since the final function

Re: [HACKERS] oversight in EphemeralNamedRelation support

Thomas Munro writes: > On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote: >> The CTE was simply not part of the available namespace for the INSERT's >> target, so it found the regular table instead. v10 has thus broken >> cases that used to

Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

David Rowley writes: > On 13 October 2017 at 12:08, Tom Lane wrote: >> Therefore, I think we need to bite the bullet and provide an aggregate >> property (CREATE AGGREGATE argument / pg_aggregate column) that tells >> whether the aggregate

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

On Tue, Aug 15, 2017 at 10:54 AM, Robert Haas wrote: >> Or at least make the filtering optional. > > I don't think "filtering" is the right way to think about it. It's > just labeling each combination of bits with the meaning appropriate to > that combination of bits. I

Re: [HACKERS] [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Peter Geoghegan wrote: > On Fri, Oct 6, 2017 at 8:29 AM, Alvaro Herrera > wrote: > > /* > > * When a tuple is frozen, the original Xmin is lost, but we know it's a > > * committed transaction. So unless the Xmax is InvalidXid, we don't > > know > >

Re: [HACKERS] oversight in EphemeralNamedRelation support

On Fri, Oct 13, 2017 at 10:01 AM, Tom Lane wrote: > Thomas Munro writes: >> Before that, CTE used as modify targets produced a different error message: > >> postgres=# WITH d AS (SELECT 42) INSERT INTO d VALUES (1); >> ERROR: relation "d" does

Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

On 13 October 2017 at 12:08, Tom Lane wrote: > Therefore, I think we need to bite the bullet and provide an aggregate > property (CREATE AGGREGATE argument / pg_aggregate column) that tells > whether the aggregate supports transition state merging. Likely this > should have

[HACKERS] Aggregate transition state merging vs. hypothetical set functions

I started to look into fixing orderedsetaggs.c so that we could revert 52328727b, and soon found a rather nasty problem. Although the plain OSAs seem amenable to supporting multiple finalfn calls on the same transition state, the "hypothetical set" functions are not at all. What they do is to

Re: [HACKERS] Extended statistics is not working on Vars hidden under a RelabelType

On 13 October 2017 at 04:56, Alvaro Herrera wrote: > I pushed your original fix. Thanks for committing -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Continuous integration on Windows?

On Fri, Oct 13, 2017 at 10:57 AM, Andrew Dunstan wrote: > Actually, that didn't take too long. > > No testing yet, but this runs a build successfully: > > > See results at

Re: [HACKERS] Continuous integration on Windows?

On 2017-10-12 17:57:11 -0400, Andrew Dunstan wrote: > No testing yet, but this runs a build successfully: > > > See results at "Time Elapsed 00:04:36.37" I'd expected

Re: [HACKERS] Continuous integration on Windows?

On 10/12/2017 04:14 PM, Andrew Dunstan wrote: > > On 10/11/2017 11:04 PM, Thomas Munro wrote: >> Hi hackers, >> >> I don't use Windows myself, but I'd rather avoid submitting patches >> that fail to build, build with horrible warnings or blow up on that >> fine operating system. I think it

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 17:27:52 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote: > >> In other words, it's not utterly fixed in stone --- we invented > >> --load-via-partition-root primarily to cope with circumstances that > >> could change hash values

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 4:20 PM, Andres Freund wrote: >> In other words, it's not utterly fixed in stone --- we invented >> --load-via-partition-root primarily to cope with circumstances that >> could change hash values --- but we sure don't want to be changing it >> with any

Re: [HACKERS] Pluggable storage

On Thu, Oct 12, 2017 at 4:38 PM, Alexander Korotkov wrote: > It's probably that we imply different meaning to "MVCC implementation". > While writing "MVCC implementation" I meant that, for instance, alternative > storage > may implement UNDO chains to store versions of

Re: [HACKERS] UPDATE of partition key

On Wed, Oct 4, 2017 at 9:51 AM, Amit Khandekar wrote: > Preparatory patches : > 0001-Prepare-for-re-using-UPDATE-result-rels-during-tuple.patch > 0002-Prevent-a-redundant-ConvertRowtypeExpr-node.patch > Main patch : > update-partition-key_v20.patch Committed 0001 with a

Re: [HACKERS] oversight in EphemeralNamedRelation support

Thomas Munro writes: > On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane wrote: >> Hm. I actually think the bug here is that 18ce3a4ab introduced >> anything into setTargetTable at all. There was never previously >> any assumption that the target

Re: [HACKERS] show precise repos version for dev builds?

Hi, On 2017-10-12 22:50:47 +0200, Fabien COELHO wrote: > The make dependencies ensure that the header file is regenerated on each > build with a phony target, and the C file is thus recompiled and linked into > the executables on each build. It means that all executables are linked on > each

Re: [HACKERS] show precise repos version for dev builds?

Hello Tom, I've seen issues with a number of tools. The one I can remember most clearly is check_postgres.pl . Nobody's going to argue that this is pretty code, but last time I tested (9.4-era, admittedly) it exploded messily with extra-version. FWIW, Salesforce tried to do something similar

Re: [HACKERS] Columnar storage support

Thanks a lot for all thoses informations regarding this "Feature" development. I'll try to test VOPS soon, and see if monetdb_fdw support filter and aggregates pushdown ;o) PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- Sent via pgsql-hackers

Re: [HACKERS] Pluggable storage

On Wed, Oct 11, 2017 at 11:08 PM, Robert Haas wrote: > On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov > wrote: > > For me, it's crucial point that pluggable storages should be able to have > > different MVCC implementation, and

Re: [HACKERS] oversight in EphemeralNamedRelation support

On Fri, Oct 13, 2017 at 8:50 AM, Tom Lane wrote: > Julien Rouhaud writes: >> On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro >> wrote: >>> I suppose we could consider moving the schemaname check into >>>

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 16:06:11 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 3:43 PM, Andres Freund wrote: > > Are we going to rely on the the combine function to stay the same > > forever after? > > If we change them, it will be a pg_upgrade compatibility break for > anyone

Re: [HACKERS] Continuous integration on Windows?

On 10/11/2017 11:04 PM, Thomas Munro wrote: > Hi hackers, > > I don't use Windows myself, but I'd rather avoid submitting patches > that fail to build, build with horrible warnings or blow up on that > fine operating system. I think it would be neat to be able to have > experimental branches of

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 3:43 PM, Andres Freund wrote: > Are we going to rely on the the combine function to stay the same > forever after? If we change them, it will be a pg_upgrade compatibility break for anyone using hash-partitioned tables with more than one partitioning

Re: [HACKERS] oversight in EphemeralNamedRelation support

Julien Rouhaud writes: > On Mon, Oct 9, 2017 at 10:43 PM, Thomas Munro > wrote: >> I suppose we could consider moving the schemaname check into >> getRTEForSpecialRelationType(), since otherwise both callers need to >> do that (and as you

Re: [HACKERS] [POC] hash partitioning

On 2017-10-12 10:05:26 -0400, Robert Haas wrote: > On Thu, Oct 12, 2017 at 9:08 AM, amul sul wrote: > > How about combining high 32 bits and the low 32 bits separately as shown > > below? > > > > static inline uint64 > > hash_combine64(uint64 a, uint64 b) > > { > > return

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

Well for this given query it is possible. I haven't come across any such query yet. Possibly because I am more concerned about the TPCDS and TPCH benchmarks, where it's less likely to occur. On 13 October 2017 at 00:52, Tom Lane wrote: > Gourav Kumar

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

Gourav Kumar writes: > A Join clause/predicate will only mention 2 relations. It can't have 3 or > more relations. Really? What of, say, select ... from a,b,c where (a.x + b.y) = c.z; regards, tom lane -- Sent via pgsql-hackers mailing

Re: [HACKERS] Optimise default partition scanning while adding new partition

On Thu, Oct 5, 2017 at 9:29 PM, Amit Langote wrote: > Attached a patch to modify the INFO messages in check_default_allows_bound. Committed. However, I didn't see a reason to adopt the comment change you proposed, so I left that part out. -- Robert Haas

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 1:02 PM, Jeff Janes wrote: > I don't see a reason to block a directly-logged-in superuser from using a > mapping. I asked in the closed list whether the current (released) > behavior was a security bug, and the answer was no. And I don't know why >

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

A Join clause/predicate will only mention 2 relations. It can't have 3 or more relations. On 12 October 2017 at 23:14, Tom Lane wrote: > Gourav Kumar writes: > > My objective is to construct join graph from a given query. > > A join graph, has a node

Re: [HACKERS] Parallel Append implementation

On Wed, Oct 11, 2017 at 8:51 AM, Amit Khandekar wrote: > [ new patch ] + parallel_append + Waiting to choose the next subplan during Parallel Append plan + execution. + + Probably needs to update a morerows values of some earlier

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

Gourav Kumar writes: > My objective is to construct join graph from a given query. > A join graph, has a node for each relation involved in a join, and an edge > between two relations if they share a join predicate among them. Hm, well, you could adapt the logic in

Re: [HACKERS] On markers of changed data

On Fri, Oct 6, 2017 at 10:34 AM, Michael Paquier wrote: > On Fri, Oct 6, 2017 at 11:22 PM, Tom Lane wrote: >> I'd say no: >> >> 1. You don't know the granularity of the filesystem's timestamps, at least >> not without making unportable assumptions.

Re: [HACKERS] Help required to debug pg_repack breaking logical replication

On Sat, Oct 7, 2017 at 2:37 PM, Daniele Varrazzo wrote: > (with a > custom addition to update the relfrozenxid which seems backwards to me > as it sets the older frozen xid on the new table [3]). > > [3] https://github.com/reorg/pg_repack/issues/152 Wow. That's

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

On Wed, Oct 11, 2017 at 10:43 PM, Ashutosh Bapat wrote: > You are suggesting that a dummy partitioned table be treated as an > un-partitioned table and apply above suggested optimization. A join > between a partitioned and unpartitioned table is partitioned by the

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

What is meant by "unstructured Join"? Thanks, Gourav On 12 October 2017 at 22:47, Gourav Kumar wrote: > My objective is to construct join graph from a given query. > A join graph, has a node for each relation involved in a join, and an edge > between two relations if they

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

My objective is to construct join graph from a given query. A join graph, has a node for each relation involved in a join, and an edge between two relations if they share a join predicate among them. To do this I first tried to use the make_join_rel() function - There I checked if they

Re: [HACKERS] [COMMITTERS] pgsql: Add port/strnlen support to libpq and ecpg Makefiles.

I wrote: > On reflection, let's just go with the solution of building libpgport_lib.a > with the right flags (fPIC + threading) and leave libpgport.a alone. > That way we don't need a debate about whether there's an efficiency > cost worth worrying about. I looked into this and got discouraged

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

Gourav Kumar writes: > I have the RelOptInfo data structure for the relations which are to be > joined but when I check their joininfo, it is empty. You aren't telling us anything much about the case you're studying, but if the join clauses have the form of equality

Re: [HACKERS] How does postgres store the join predicate for a relation in a given query

Hi Ashutosh, I have the RelOptInfo data structure for the relations which are to be joined but when I check their joininfo, it is empty. Does baserestrictinfo contains base predicates ? Thanks Gourav. On 11 October 2017 at 12:00, Ashutosh Bapat wrote: > On

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Wed, Oct 11, 2017 at 7:08 AM, Ashutosh Bapat wrote: > Here's updated patch set based on the basic partition-wise join > committed. The patchset applies on top of the patch to optimize the > case of dummy partitioned tables [1]. > > Right now, the advanced

Re: [HACKERS] GUC for cleanup indexes threshold.

On Tue, Oct 10, 2017 at 5:55 AM, Pavel Golub wrote: > DP> The new status of this patch is: Ready for Committer > > Seems like, we may also going to hit it and it would be cool this > vacuum issue solved for next PG version. Exactly which patch on this thread is someone

[HACKERS] Re: Extended statistics is not working on Vars hidden under a RelabelType

David Rowley wrote: > The reason Tomas coded it the way it was coded is due to the fact that > there's already code that works exactly the same way in > clauselist_selectivity(). Personally, I don't particularly like that > code, but I'd rather not invent a new way to do the same thing. I pushed

Re: [HACKERS] Fix a typo in execReplication.c

On Thu, Oct 12, 2017 at 6:55 AM, Petr Jelinek wrote: > Thanks for the patch, looks correct to me. Committed and back-patched to v10. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] Discussion on missing optimizations

On 13 October 2017 at 03:00, Tom Lane wrote: > Laurenz Albe writes: >> Robert Haas wrote: >>> One trick that some system use is avoid replanning as much as we do >>> by, for example, saving plans in a shared cache and reusing them even >>> in other

Re: [HACKERS] Query started showing wrong result after Ctrl+c

tushar writes: > On 10/12/2017 03:46 PM, Marko Tiikkaja wrote: >> The subquery: >>     select n from tv limit 1 >> could in theory return any row due to the lack of ORDER BY. What I'm >> guessing happened is that you're seeing a synchronized sequential scan >> in

Re: [HACKERS] Discussion on missing optimizations

On Thu, Oct 12, 2017 at 10:00 AM, Tom Lane wrote: >> From my experience with Oracle I would say that that is a can of worms. > > Yeah, I'm pretty suspicious of the idea too. We've had an awful lot of > bad experience with local plan caching, to the point where people wonder >

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 9:08 AM, amul sul wrote: > How about combining high 32 bits and the low 32 bits separately as shown > below? > > static inline uint64 > hash_combine64(uint64 a, uint64 b) > { > return (((uint64) hash_combine((uint32) a >> 32, (uint32) b >> 32) <<

Re: [HACKERS] Discussion on missing optimizations

Laurenz Albe writes: > Robert Haas wrote: >> One trick that some system use is avoid replanning as much as we do >> by, for example, saving plans in a shared cache and reusing them even >> in other sessions. That's hard to do in our architecture because the >>

[HACKERS] BLK_DONE state in XLogReadBufferForRedoExtended

Today, I was trying to think about cases when we can return BLK_DONE in XLogReadBufferForRedoExtended. One thing that occurred to me is that it can happen during the replay of WAL if the full_page_writes is off. Basically, when the full_page_writes is on, then during crash recovery, it will

Re: [HACKERS] Extended statistics is not working on Vars hidden under a RelabelType

On 13 October 2017 at 02:17, Alvaro Herrera wrote: > I propose this slightly larger change. hmm, this is not right. You're not checking that there's a Var below the RelabelType. I tried with: explain select * from ab where (a||a)::varchar = '' and b = ''; and your

[HACKERS] Re: Extended statistics is not working on Vars hidden under a RelabelType

Tomas Vondra wrote: > On 10/10/2017 05:03 AM, David Rowley wrote: > > Basically, $subject is causing us not to properly find matching > > extended stats in this case. > > > > The attached patch fixes it. > > > > The following test cases is an example of the misbehaviour. Note > > rows=1 vs

Re: [HACKERS] Parallel Bitmap Heap Scans segfaults due to (tbm->dsa==NULL) on PostgreSQL 10

On Thu, Oct 12, 2017 at 6:37 PM, Tomas Vondra wrote: > > > On 10/12/2017 02:40 PM, Dilip Kumar wrote: >> On Thu, Oct 12, 2017 at 4:31 PM, Tomas Vondra >> wrote: >>> Hi, >>> >>> It seems that Q19 from TPC-H is consistently failing with

Re: [HACKERS] [POC] hash partitioning

On Thu, Oct 12, 2017 at 6:31 AM, Robert Haas wrote: > On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote: >> How about the attached patch(0003)? >> Also, the dim variable is renamed to natts. > > I'm not sure I believe this comment: > > +/* > +

Re: [HACKERS] Parallel Bitmap Heap Scans segfaults due to (tbm->dsa==NULL) on PostgreSQL 10

On 10/12/2017 02:40 PM, Dilip Kumar wrote: > On Thu, Oct 12, 2017 at 4:31 PM, Tomas Vondra > wrote: >> Hi, >> >> It seems that Q19 from TPC-H is consistently failing with segfaults due >> to calling tbm_prepare_shared_iterate() with (tbm->dsa==NULL). >> >> I'm not

Re: [HACKERS] Parallel Bitmap Heap Scans segfaults due to (tbm->dsa==NULL) on PostgreSQL 10

On Thu, Oct 12, 2017 at 4:31 PM, Tomas Vondra wrote: > Hi, > > It seems that Q19 from TPC-H is consistently failing with segfaults due > to calling tbm_prepare_shared_iterate() with (tbm->dsa==NULL). > > I'm not very familiar with how the dsa is initialized and

[HACKERS] Fwd: [BUGS] BUG #14850: Implement optinal additinal parameter for 'justify' date/time function

Пересылаемое сообщение11.10.2017, 17:12, "Pavel Stehule" :Hi2017-10-11 12:35 GMT+02:00 :The following bug has been logged on the website: Bug reference:      14850 Logged by:          Eugen Konkov Email address:      kes-...@yandex.ru

[HACKERS] Parallel Bitmap Heap Scans segfaults due to (tbm->dsa==NULL) on PostgreSQL 10

Hi, It seems that Q19 from TPC-H is consistently failing with segfaults due to calling tbm_prepare_shared_iterate() with (tbm->dsa==NULL). I'm not very familiar with how the dsa is initialized and passed around, but I only see the failures when the bitmap is constructed by a mix of BitmapAnd and

Re: [HACKERS] Fix a typo in execReplication.c

On 12/10/17 00:52, Masahiko Sawada wrote: > On Thu, Oct 12, 2017 at 5:02 AM, Robert Haas wrote: >> On Mon, Oct 9, 2017 at 10:59 PM, Masahiko Sawada >> wrote: >>> Attached a patch for $subject. ISTM these are mistakes of copy-and-paste. >> >>

Re: [HACKERS] Query started showing wrong result after Ctrl+c

On 10/12/2017 03:46 PM, Marko Tiikkaja wrote: The subquery:     select n from tv limit 1 could in theory return any row due to the lack of ORDER BY. What I'm guessing happened is that you're seeing a synchronized sequential scan in follow-up queries.  Add an ORDER BY. Bang on . After

Re: [HACKERS] Query started showing wrong result after Ctrl+c

On Thu, Oct 12, 2017 at 12:03 PM, tushar wrote: > postgres=# SELECT * FROM ( SELECT n from tv where n= (select * from > (select n from tv limit 1) c)) as c ; > n > -- > 3713 > (1 row) > > This time , query is started showing wrong result. Is this an

[HACKERS] Query started showing wrong result after Ctrl+c

Hi, Steps to reproduce - \\ PG HEAD / PG v10  sources . Connect to psql terminal -  create these following object create table tv(n int,n1 char(100)); insert into tv values (generate_series(1,100),'aaa'); insert into tv values (generate_series(1,100),'a'); analyze tv; vacuum tv;

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-09-19 20:49 GMT+02:00 Merlin Moncure : > On Tue, Sep 19, 2017 at 1:37 PM, Robert Haas > wrote: > > On Tue, Sep 19, 2017 at 12:45 PM, Pavel Stehule > wrote: > >>> You can already set a GUC with function scope. I'm not

Re: [HACKERS] Discussion on missing optimizations

Andres Freund wrote: > On 2017-10-08 11:28:09 -0400, Tom Lane wrote: > > Adam Brusselback writes: > > > On another note: > > >> turning ORs into UNIONs > > > > > This is another one which would be incredibly useful for me. I've had > > > to do this manually for

Re: [HACKERS] replace GrantObjectType with ObjectType

Michael Paquier wrote: > On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut > wrote: > > It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_* > > symbols is not useful and leads to duplication. Digging around in the > > past suggests that we used to

Re: [HACKERS] Slow synchronous logical replication

On 12.10.2017 04:23, Craig Ringer wrote: On 12 October 2017 at 00:57, Konstantin Knizhnik wrote: The reason of such behavior is obvious: wal sender has to decode huge transaction generate by insert although it has no relation to this publication. It does. Though

Re: [HACKERS] Omission in GRANT documentation

Tom Lane wrote: >> But types also have the USAGE privilege for PUBLIC by default: > > Yup, that's an oversight. > >> Hence I propose the attached documentation patch. > > Pushed, with a bit of additional wordsmithing. Thanks for taking the time. Yours, Laurenz Albe -- Sent via

Re: [HACKERS] Discussion on missing optimizations

Robert Haas wrote: > One trick that some system use is avoid replanning as much as we do > by, for example, saving plans in a shared cache and reusing them even > in other sessions. That's hard to do in our architecture because the > controlling GUCs can be different in every session and there's

Re: [HACKERS] replace GrantObjectType with ObjectType

On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut wrote: > It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_* > symbols is not useful and leads to duplication. Digging around in the > past suggests that we used to have a lot of these