Re: [HACKERS] Explicit subtransactions for PL/Tcl

2017-03-09 7:48 GMT+01:00 Victor Wagner : > On Wed, 8 Mar 2017 16:49:33 +0100 > Pavel Stehule wrote: > > > > > I did a review of this patch > > > I'm attaching new version of patch with the issues pointed by you fixed. > > > > > 4. A documentation is good - although I am not sure if it is well >

Re: [HACKERS] Explicit subtransactions for PL/Tcl

On Thu, 9 Mar 2017 09:25:14 +0100 Pavel Stehule wrote: > > > is this patch complete? I don't see new regress tests Oh, really! I've forgot that git diff doesn't include files which are not added into git. So, no old regress tests as well. Sorry for posting incomplete patch. Attached fixed ve

Re: [HACKERS] Explicit subtransactions for PL/Tcl

Hi 2017-03-09 10:25 GMT+01:00 Victor Wagner : > On Thu, 9 Mar 2017 09:25:14 +0100 > Pavel Stehule wrote: > > > > > > > is this patch complete? I don't see new regress tests > > Oh, really! I've forgot that git diff doesn't include files which are > not added into git. > > So, no old regress test

Re: [HACKERS] Logical replication existing data copy

On 2017-03-09 11:06, Erik Rijkers wrote: file Name: logrep.20170309_1021.1.1043.scale_25.clients_64.NOK.log 20170309_1021 is the start-time of the script 1 is master (2 is replica) 1043 is the time, 10:43, just before the pg_waldump call Sorry, that might be confusing. That 10:43 is the ti

Re: [HACKERS] Logical replication existing data copy

On 2017-03-09 11:06, Erik Rijkers wrote: On 2017-03-08 10:36, Petr Jelinek wrote: On 07/03/17 23:30, Erik Rijkers wrote: On 2017-03-06 11:27, Petr Jelinek wrote: 0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch + 0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+ 0

Re: [HACKERS] Explicit subtransactions for PL/Tcl

On Thu, 9 Mar 2017 11:12:09 +0100 Pavel Stehule wrote: > the regress tests is unstable > > the proc name has mutable pid > > ! (procedure "__PLTcl_proc_16503" line 3) > invoked from within > ! "__PLTcl_proc_16503 SPI" > > Regards Really, I don't know what can be done with it, short

Re: [HACKERS] Explicit subtransactions for PL/Tcl

2017-03-09 11:45 GMT+01:00 Victor Wagner : > On Thu, 9 Mar 2017 11:12:09 +0100 > Pavel Stehule wrote: > > > > the regress tests is unstable > > > > the proc name has mutable pid > > > > ! (procedure "__PLTcl_proc_16503" line 3) > > invoked from within > > ! "__PLTcl_proc_16503 SPI" > >

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 9 March 2017 at 18:06, Ashutosh Bapat wrote: >>> >>> Here's the patch attached. >> >> Agreed. It seems like a good idea to keep that logic in a single location > > Ok. > >> >> I've beaten your patch around a bit and come up with the attached. > > The new name merge_fdw_options() is shorter than

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Wed, Mar 8, 2017 at 12:58 PM, Andres Freund wrote: > 0002: Check hash join work_mem usage at the point of chunk allocation. > > Modify the existing hash join code to detect work_mem exhaustion at > the point where chunks are allocated, instead of checking after every > tuple insertion. This ma

Re: [HACKERS] [PATCH] kNN for btree

On Thu, Mar 2, 2017 at 5:57 PM, David Steele wrote: > Hi Alexander, > > On 2/16/17 11:20 AM, Robert Haas wrote: > > On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane wrote: > >> Robert Haas writes: > >>> On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov > >>> wrote: > My idea is that we need m

Re: [HACKERS] New CORRESPONDING clause design

Hi , Here is a patch corrected as your feedback except missed tests case because corresponding by clause is implemented on the top of set operation and you can’t do that to set operation without corresponding by clause too Eg postgres=# SELECT 1 a, 2 b, 3 c UNION SELECT 4 a, 5 b, 6 c, 8 d; E

Re: [HACKERS] Parallel Append implementation

> > +if (rel->partial_pathlist != NIL && > +(Path *) linitial(rel->partial_pathlist) == subpath) > +partial_subplans_set = bms_add_member(partial_subplans_set, i); > > This seems like a scary way to figure this out. What if we wanted to > build a parallel append sub

[HACKERS] Performance issue after upgrading from 9.4 to 9.6

Hi, We are having some performance issues after we upgraded to newest version of PostgreSQL, before it everything was fast and smooth. Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we upgraded to 9.6.2 with no improvement. Some information about our setup: Freebsd, Solaris (Smar

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hello On 07.03.2017 15:58, Masahiko Sawada wrote: I've read the discussion so far but I didn't see the reason why you've changed it to as a contrib module. Could you tell me about that? I did it on the initiative of our customer, who preferred the implementation in the form of contrib. Contri

Re: [HACKERS] Gather Merge

On Wed, Mar 8, 2017 at 11:59 PM, Rushabh Lathia wrote: > Here is another version of patch with the suggested changes. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Parallel Append implementation

On Thu, Mar 9, 2017 at 7:42 AM, Ashutosh Bapat wrote: >> >> +if (rel->partial_pathlist != NIL && >> +(Path *) linitial(rel->partial_pathlist) == subpath) >> +partial_subplans_set = bms_add_member(partial_subplans_set, i); >> >> This seems like a scary way to figure

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On Thu, Mar 9, 2017 at 1:17 AM, Joe Conway wrote: > On 03/07/2017 08:29 PM, Tom Lane wrote: >> Michael Paquier writes: >>> here is a separate thread dedicated to the following extension for >>> CREATE/ALTER ROLE: PASSWORD ('value' USING 'method'). >> >> The parentheses seem weird ... do we really

[HACKERS] Performance issue after upgrading from 9.4 to 9.6

Hi, We are having some performance issues after we upgraded to newest version of PostgreSQL, before it everything was fast and smooth. Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we upgraded to 9.6.2 with no improvement. Some information about our setup: Freebsd, Solaris (Smar

Re: [HACKERS] Gather Merge

On Thu, Mar 9, 2017 at 6:19 PM, Robert Haas wrote: > On Wed, Mar 8, 2017 at 11:59 PM, Rushabh Lathia > wrote: > > Here is another version of patch with the suggested changes. > > Committed. > > Thanks Robert for committing this. My colleague Neha Sharma found one regression with the patch. I wa

Re: [HACKERS] contrib modules and relkind check

Amit, Michael, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/03/09 11:51, Michael Paquier wrote: > > On Wed, Mar 8, 2017 at 5:10 PM, Amit Langote > > wrote: > >> On 2017/03/08 16:47, Michael Paquier wrote: > >>> Only regular tables are tested as valid objects. Testing toast tabl

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

Hello, I wanted to review the patch. But the patch is applied with errors. I've rebased the local copy and have done review on it. I'm not sure is it properly to send rebased patch by reviewer, so I haven't sent it to avoid confuses. On 29.01.2017 17:00, Michael Paquier wrote: Attached is w

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 3/8/17 02:34, Michael Paquier wrote: > This patch looks good to me. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make cha

Re: [HACKERS] background sessions

On 3/8/17 14:22, Pavel Stehule wrote: > 1. will be background session process closed automatically when parent > process is closed? If the communications queue goes away the process will eventually die. This is similar to how a backend process will eventually die if the client goes away. Some mor

Re: [HACKERS] [PATCH] kNN for SP-GiST

Hi, Nikita! I take a look to this patchset. My first notes are following. * 0003-Extract-index_store_orderby_distances-v02.patch Function index_store_orderby_distances doesn't look general enough for its name. GiST supports ordering only by float4 and float8 distances. SP-GiST also goes that

Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog

On 3/7/17 11:16, Robert Haas wrote: > Well, if the problem you're trying to solve is "retain WAL for as long > as possible without running out of disk space and having everything go > kablooey", then it would solve that problem, and I think that's a very > reasonable problem to want to solve. Coul

Re: [HACKERS] [PATCH]: fix bug in SP-GiST box_ops

On Wed, Feb 1, 2017 at 2:43 PM, Emre Hasegeli wrote: > > I think this patch is already in a good shape. > > I am sorry for introducing this bug. This fix looks good to me as well. I checked this patch too. And it seems good to me as well. Should we mark it as "ready for committer"? -- Al

[HACKERS] postgres_fdw IMPORT SCHEMA and partitioned tables

Greetings, While reviewing Amit Langote's patch to handle partitioned tables properly in various contrib modules (mostly by throwing an error since things like pageinspect aren't going to work on the empty 'parent' table), I went looking through contrib for other modules that do something with rel

Re: [HACKERS] Partitioning vs ON CONFLICT

On Fri, Feb 17, 2017 at 1:47 AM, Amit Langote wrote: > On 2017/02/17 14:50, Peter Geoghegan wrote: >> On Thu, Feb 16, 2017 at 9:27 PM, Amit Langote >> wrote: >>> Attached patch fixes that. Thom, your example query should not error out >>> with the patch. As discussed here, DO UPDATE cannot be s

Re: [HACKERS] increasing the default WAL segment size

On Mon, Feb 27, 2017 at 11:15 PM, Jim Nasby wrote: >> * You're considering any WAL file with a power of 2 as valid. Suppose, >> the correct WAL seg size is 64mb. For some reason, the server >> generated a 16mb invalid WAL file(maybe it crashed while creating the >> WAL file). Your code seems to tr

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier wrote: > Yes, I agree with that for MD5, and after looking around I can see > (like here http://prosody.im/doc/plain_or_hashed) as well that > SCRAM-hashed is used. Now, there are as well references to the salt, > like in protocol.sgml: > "The salt t

Re: [HACKERS] [GSoC] Self introduction and question to mentors

Hi, Kirill! 2017-03-06 12:41 GMT+05:00 Кирилл Бороздин : > My name is Kirill Borozdin. I am a student of Ural Federal University from > Yekaterinburg, Russia. That's fine. I'm the associate professor at Ural Federal University. But not in your institution, though. > I understand that this task wi

[HACKERS] partitioned tables and contrib/sepgsql

Greetings, While going over the contrib modules, I noticed that sepgsql was not updated for partitioned tables. What that appears to mean is that it's not possible to define labels on partitioned tables. As I recall, accessing the parent of a table will, similar to the GRANT system, not perform

Re: [HACKERS] partitioned tables and contrib/sepgsql

On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote: > Greetings, > > While going over the contrib modules, I noticed that sepgsql was not > updated for partitioned tables. What that appears to mean is that it's > not possible to define labels on partitioned tables. As I recall, > accessing the

Re: [HACKERS] CREATE/ALTER ROLE PASSWORD ('value' USING 'method')

On 03/09/2017 06:34 AM, Robert Haas wrote: > On Thu, Mar 9, 2017 at 7:59 AM, Michael Paquier > wrote: >> Yes, I agree with that for MD5, and after looking around I can see >> (like here http://prosody.im/doc/plain_or_hashed) as well that >> SCRAM-hashed is used. Now, there are as well references t

Re: [HACKERS] partitioned tables and contrib/sepgsql

Mike, * Mike Palmiotto (mike.palmio...@crunchydata.com) wrote: > On Thu, Mar 9, 2017 at 9:47 AM, Stephen Frost wrote: > > While going over the contrib modules, I noticed that sepgsql was not > > updated for partitioned tables. What that appears to mean is that it's > > not possible to define lab

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Mar 9, 2017 at 3:11 AM, Robert Haas wrote: > On Tue, Mar 7, 2017 at 6:41 PM, Robert Haas wrote: Great, thanks. 0001 looks good to me now, so committed. >>> >>> Committed 0002. >> >> Here are some initial review thoughts on 0003 based on a first read-through. > > More thoughts on the

Re: [HACKERS] [bug fix] dblink leaks unnamed connections

On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki wrote: > Hello, > > dblink fails to close the unnamed connection as follows when a new unnamed > connection is requested. The attached patch fixes this. This issue was reported about ten years ago and added as TODO item. http://archives.postgr

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Mar 9, 2017 at 12:25 AM, Robert Haas wrote: > On Wed, Mar 8, 2017 at 7:45 AM, Amit Kapila wrote: >> Okay, I can try, but note that currently there is no test related to >> "snapshot too old" for any other indexes. > > Wow, that's surprising. It seems the snapshot_too_old test only > chec

[HACKERS] Parallel Bitmap scans a bit broken

I was just doing some testing on [1] when I noticed that there's a problem with parallel bitmap index scans scans. Test case: patch with [1] =# create table r1(value int); CREATE TABLE =# insert into r1 select (random()*1000)::int from generate_Series(1,100); INSERT 0 100 =# create index

Re: [HACKERS] [bug fix] dblink leaks unnamed connections

Fujii Masao writes: > On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki > wrote: >> dblink fails to close the unnamed connection as follows when a new unnamed >> connection is requested. The attached patch fixes this. > This issue was reported about ten years ago and added as TODO item. > ht

Re: [HACKERS] use SQL standard error code for nextval

On 2/28/17 22:15, Peter Eisentraut wrote: > The SQL standard defines a separate error code for nextval exhausting > the sequence space. I haven't found any discussion of this in the > archives, so it seems this was just not considered or not yet in > existence when the error codes were introduced.

[HACKERS] partial indexes and bitmap scans

Greetings, Consider this: create table t10 (c1 int, c2 int); create index on t10 (c1) where c2 > 5; \d t10 Table "sfrost.t10" Column | Type | Modifiers +-+--- c1 | integer | c2 | integer | Indexes: "t10_c1_idx" btree (c1) WHERE c2 > 5 insert in

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

Hi, Andres Thanks a lot for the review! > Why are we keeping that list / the "batch" allocation pattern? It > doesn't actually seem useful to me after these changes. Given that we > don't shrink hash-tables, we could just use the hash-table memory for > this, no? I don't think we can do that. A

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 9, 2017 at 9:17 PM, David Rowley wrote: > patch with [1] > > =# create table r1(value int); > CREATE TABLE > =# insert into r1 select (random()*1000)::int from > generate_Series(1,100); > INSERT 0 100 > =# create index on r1 using brin(value); > CREATE INDEX > =# set enable_seq

Re: [HACKERS] Declarative partitioning optimization for large amount of partitions

Hi Amit, > Sorry, I didn't mean to dissuade you from trying those > micro-optimizations. If general inheritance cases can benefit from it > (which, until we have a different method, will be used by partitioned > tables as well), I think we should try it. OK, I'll see what could be done here as w

Re: [HACKERS] Gather Merge

On Thu, Mar 9, 2017 at 8:21 AM, Rushabh Lathia wrote: > Thanks Robert for committing this. > > My colleague Neha Sharma found one regression with the patch. I was about > to send this mail and noticed that you committed the patch. Oops. Bad timing. > postgres=# explain select aid from pgbench_a

Re: [HACKERS] New CORRESPONDING clause design

2017-03-09 13:18 GMT+01:00 Surafel Temesgen : > Hi , > > Here is a patch corrected as your feedback except missed tests case > because corresponding by clause is implemented on the top of set operation > and you can’t do that to set operation without corresponding by clause too > I don't understa

Re: [HACKERS] Gather Merge

On Thu, Mar 9, 2017 at 9:42 PM, Robert Haas wrote: > On Thu, Mar 9, 2017 at 8:21 AM, Rushabh Lathia > wrote: > > Thanks Robert for committing this. > > > > My colleague Neha Sharma found one regression with the patch. I was about > > to send this mail and noticed that you committed the patch. >

Re: [HACKERS] [bug fix] dblink leaks unnamed connections

On 03/09/2017 07:54 AM, Tom Lane wrote: > Fujii Masao writes: >> On Wed, Mar 8, 2017 at 3:52 PM, Tsunakawa, Takayuki >> wrote: >>> dblink fails to close the unnamed connection as follows when a new unnamed >>> connection is requested. The attached patch fixes this. > >> This issue was reported

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 9, 2017 at 9:37 PM, Dilip Kumar wrote: >> =# create table r1(value int); >> CREATE TABLE >> =# insert into r1 select (random()*1000)::int from >> generate_Series(1,100); >> INSERT 0 100 >> =# create index on r1 using brin(value); >> CREATE INDEX >> =# set enable_seqscan=0; >> S

Re: [HACKERS] partial indexes and bitmap scans

Stephen Frost writes: > Perhaps I'm missing something obvious, but isn't it a bit redundant to > have both a Recheck condition (which is the predicate of the index) and > a Filter condition (which is the user's predicate) when we've already > decided that the user's predicate must result in a subs

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote: > I slightly modified your query to reproduce this issue. > > explain analyze select * from r1 where value<555; > > Patch is attached to fix the problem. I forgot to mention the cause of the problem. if (istate->schunkptr < istate->nchunks) {

Re: [HACKERS] GUC for cleanup indexes threshold.

On Wed, Mar 8, 2017 at 1:43 AM, Peter Geoghegan wrote: > On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila wrote: >>> While I can't see this explained anywhere, I'm >>> pretty sure that that's supposed to be impossible, which this patch >>> changes. >>> >> >> What makes you think that patch will allow

Re: [HACKERS] partial indexes and bitmap scans

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Perhaps I'm missing something obvious, but isn't it a bit redundant to > > have both a Recheck condition (which is the predicate of the index) and > > a Filter condition (which is the user's predicate) when we've already > >

Re: [HACKERS] Gather Merge

On Thu, Mar 9, 2017 at 11:25 AM, Rushabh Lathia wrote: > I don't see this failure with the patch. Even I forced the gather merge > in the above query and that just working fine. > > Attaching patch, with the discussed changes. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Parallel Bitmap scans a bit broken

On Thu, Mar 9, 2017 at 11:50 AM, Dilip Kumar wrote: > On Thu, Mar 9, 2017 at 10:02 PM, Dilip Kumar wrote: >> I slightly modified your query to reproduce this issue. >> >> explain analyze select * from r1 where value<555; >> >> Patch is attached to fix the problem. > > I forgot to mention the caus

Re: [HACKERS] partial indexes and bitmap scans

Stephen Frost writes: > We have already figured out that the user's predicate results in a > subset of the index's or we wouldn't be able to use that index though, > right? Do we really need to spend cycles re-discovering that? Are > there cases where we actually need the index's predicate to ev

Re: [HACKERS] use SQL standard error code for nextval

> On Mar 9, 2017, at 7:59 AM, Peter Eisentraut > wrote: > > On 2/28/17 22:15, Peter Eisentraut wrote: >> The SQL standard defines a separate error code for nextval exhausting >> the sequence space. I haven't found any discussion of this in the >> archives, so it seems this was just not conside

Re: [HACKERS] Performance issue after upgrading from 9.4 to 9.6

On Thu, Mar 9, 2017 at 7:47 AM, Naytro Naytro wrote: > We are having some performance issues after we upgraded to newest > version of PostgreSQL, before it everything was fast and smooth. > > Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we > upgraded to 9.6.2 with no improvement.

Re: [HACKERS] partial indexes and bitmap scans

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > We have already figured out that the user's predicate results in a > > subset of the index's or we wouldn't be able to use that index though, > > right? Do we really need to spend cycles re-discovering that? Are > > there c

Re: [HACKERS] use SQL standard error code for nextval

On 3/9/17 12:27, Mark Dilger wrote: > Perhaps you should add something to the release notes. Somebody could be > testing for the old error code. The release notes will be written when the release is prepared. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 2

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Mar 9, 2017 at 10:23 AM, Amit Kapila wrote: >> +mode anyway). It would seem natural to complete the split in VACUUM, but >> since >> +splitting a bucket might require allocating a new page, it might fail if you >> +run out of disk space. That would be bad during VACUUM - the reason for

Re: [HACKERS] Logical replication existing data copy

On 3/6/17 05:27, Petr Jelinek wrote: > updated and rebased version of the patch attached. Some comments on this patch: Can we have a better explanation of different snapshot options in CREATE_REPLICATION_SLOT. We use all these variants in different places, but it's not fully documented why. Thi

Re: [HACKERS] Logical replication existing data copy

On 3/6/17 05:27, Petr Jelinek wrote: > And lastly I changed the automagic around exporting, not exporting and > using the snapshot produced by CREATE_REPLICATION_SLOT into explicit > parameter for the CREATE_REPLICATION_SLOT command (and added simple > framework for adding more of those if needed i

Re: [HACKERS] SQL/JSON in PostgreSQL

On 08.03.2017 20:48, Peter van Hardenberg wrote: Small point of order: YAML is not strictly a super-set of JSON. I haven't read the whole standard, but from what I can see the standard considers JSON an official subset of itself: http://www.yaml.org/spec/1.2/spec.html Regards, Sven -- Sen

Re: [HACKERS] use SQL standard error code for nextval

Mark Dilger writes: >> On Mar 9, 2017, at 7:59 AM, Peter Eisentraut >> wrote: >> On 2/28/17 22:15, Peter Eisentraut wrote: >>> The SQL standard defines a separate error code for nextval exhausting >>> the sequence space. I haven't found any discussion of this in the >>> archives, so it seems th

Re: [HACKERS] SQL/JSON in PostgreSQL

On Thu, Mar 9, 2017 at 12:48 PM, Sven R. Kunze wrote: > On 08.03.2017 20:48, Peter van Hardenberg wrote: >> >> Small point of order: YAML is not strictly a super-set of JSON. > > I haven't read the whole standard, but from what I can see the standard > considers JSON an official subset of itself:

Re: [HACKERS] [PATCH] Enabling atomics on ARM64

On Wed, Mar 8, 2017 at 10:18 PM, Roman Shaposhnik wrote: > I'd like to offer a forward port from a change I'm contributing > the Greenplum code base over here: > https://github.com/greenplum-db/gpdb/pull/1983 Thanks. Please add this to https://commitfest.postgresql.org/14/ so it doesn't get

Re: [HACKERS] partial indexes and bitmap scans

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I do notice that createplan.c makes some effort to get rid of filter >> conditions that are provably true when the index conditions are. >> Doesn't look like it considers the reverse direction. Not sure if >> that's missing a bet.

Re: [HACKERS] updating parallel.sgml

On Wed, Mar 8, 2017 at 12:46 PM, Robert Haas wrote: > Here's a patch which updates parallel.sgml for the new parallel scan > types which have recently been committed, and also expands the > explanation of parallel joins slightly. I hope everyone will find > this useful in understanding what new c

Re: [HACKERS] SQL/JSON in PostgreSQL

On 08.03.2017 20:52, Magnus Hagander wrote: On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > wrote: Small point of order: YAML is not strictly a super-set of JSON. Editorializing slightly, I have not seen much interest in the world for YAML support though

Re: [HACKERS] foreign partition DDL regression tests

On Thu, Mar 9, 2017 at 1:19 AM, Ashutosh Bapat wrote: >>> At least we need to update the documentation. >> >> Got a proposal? > > How about something like attached? Committed with some revisions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Se

Re: [HACKERS] SQL/JSON in PostgreSQL

On 09.03.2017 18:58, Robert Haas wrote: Also, even if the superset thing were true on a theoretical plane, I'm not sure it would do us much good in practice. If we start using YAML-specific constructs, we won't have valid JSON any more. If we use only things that are legal in JSON, YAML's irrel

Re: [HACKERS] Documentation improvements for partitioning

I think you might have the titles for 0002 and 0003 backwards. On Fri, Mar 3, 2017 at 2:51 AM, Amit Langote wrote: > 0002: some cosmetic fixes to create_table.sgml I think this sentence may be unclear to some readers: + One might however want to set it for only some partitions, + which is

Re: [HACKERS] PATCH: psql show index with type info

On 3/8/17 04:11, Ashutosh Bapat wrote: > The header for this table is "list of relations", so type gets > associated with relations indicated type of relation. btree: gin as a > type of relation doesn't sound really great. Instead we might want to > add another column "access method" and specify th

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote: > Andres Freund writes: >> Wonder if we there's an argument to be made for implementing this >> roughly similarly to split_pathtarget_at_srf - instead of injecting a >> ProjectSet node we'd add a FunctionScan node below a Result node. > > Yeah, pos

Re: [HACKERS] PATCH: psql show index with type info

On 3/8/17 08:30, Stephen Frost wrote: > Right, I don't think having an extra column which is going to be NULL a > large amount of the time is good. Note that \di already has a column "Table" that is null for something that is not an index. So I don't think this argument is very strong. -- Peter

Re: [HACKERS] PATCH: psql show index with type info

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/8/17 04:11, Ashutosh Bapat wrote: > > The header for this table is "list of relations", so type gets > > associated with relations indicated type of relation. btree: gin as a > > type of relation doesn't sound really great.

Re: [HACKERS] PATCH: psql show index with type info

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/8/17 08:30, Stephen Frost wrote: > > Right, I don't think having an extra column which is going to be NULL a > > large amount of the time is good. > > Note that \di already has a column "Table" that is null for something > that is

Re: [HACKERS] New CORRESPONDING clause design

hi 2017-03-09 17:19 GMT+01:00 Pavel Stehule : > > > 2017-03-09 13:18 GMT+01:00 Surafel Temesgen : > >> Hi , >> >> Here is a patch corrected as your feedback except missed tests case >> because corresponding by clause is implemented on the top of set operation >> and you can’t do that to set opera

Re: [HACKERS] Couple of issues with prepared FETCH commands

On Wed, Jan 11, 2017 at 11:28 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jan 10, 2017 at 5:38 PM, Andrew Gierth >> wrote: >>> But the problem that actually came up is this: if you do the PQprepare >>> before the named cursor has actually been opened, then everything works >>> _up until

Re: [HACKERS] SQL/JSON in PostgreSQL

Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix. On Thu, Mar 9, 2017 at 10:24 AM, Sven R. Kunze wrote

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

Hello Amit, On Tue, Mar 7, 2017 at 4:24 PM, Amit Langote wrote: > Hi Kuntal, > > Patches apply and compile fine. Works as advertised. > > Some minor comments on the patches themselves. > Thanks for the review. > In 0001: > > - * pgstat_bestart() - > + * pgstat_procstart() - > + * > + * Initial

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Wed, Jan 25, 2017 at 12:44 AM, Craig Ringer wrote: >> The way that SetTransactionIdLimit() now works looks a bit dangerous. >> xidWrapLimit, xidStopLimit, and xidWarnLimit are computed based on the >> passed-in oldestXid value and written straight into shared memory. >> But the shared memory co

Re: [HACKERS] [PATCH] Add pg_disable_checksums() and supporting infrastructure

On Sun, Feb 19, 2017 at 12:02 PM, David Christensen wrote: > Hi Robert, this is part of a larger patch which *does* enable the checksums > online; I’ve been extracting the necessary pieces out with the understanding > that some people thought the disable code might be useful in its own merit.

Re: [HACKERS] SQL/JSON in PostgreSQL

On 09.03.2017 19:50, Peter van Hardenberg wrote: Anecdotally, we just stored dates as strings and used a convention (key ends in "_at", I believe) to interpret them. The lack of support for dates in JSON is well-known, universally decried... and not a problem the PostgreSQL community can fix.

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

This is looking pretty neat. I played around with it a bit. There are a couple of edge cases that you need to address, I think. - Does not support \x - When \pset format is rst, then \pset linestyle also shows up as "rst". That is wrong. Same for markdown. - Broken output in tuples_only (\

Re: [HACKERS] bytea_output vs make installcheck

On 2/14/17 16:50, Jeff Janes wrote: > make installcheck currently fails against a server running > with bytea_output = escape. > > Making it succeed is fairly easy, and I think it is worth doing. > > Attached are two options for doing that. One overrides bytea_output > locally where-ever needed,

Re: [HACKERS] on_dsm_detach() callback and parallel tuplesort BufFile resource management

On Wed, Mar 8, 2017 at 5:23 PM, Robert Haas wrote: > I think something like 0007-hj-shared-buf-file-v6.patch from > https://www.postgresql.org/message-id/CAEepm=3g=dMG+84083fkFzLvgMJ7HdhbGB=aezabnukbzm3...@mail.gmail.com > is probably a good approach to this problem. In essence, it dodges > the p

Re: [HACKERS] Performance issue after upgrading from 9.4 to 9.6

Hi, On 2017-03-09 13:47:35 +0100, Naytro Naytro wrote: > We are having some performance issues after we upgraded to newest > version of PostgreSQL, before it everything was fast and smooth. > > Upgrade was done by pg_upgrade from 9.4 directly do 9.6.1. Now we > upgraded to 9.6.2 with no improveme

[HACKERS] tzdata2017a breaks timestamptz regression test

I typically build with --with-system-tzdata, which means that any time Red Hat sees fit to push out a new copy of the tzdata package, that's what I'm testing against. This morning they updated to tzdata2017a, and I'm seeing the attached test failures. The reason for this is that the IANA crew hav

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

Perhaps I'm confused by the title of this thread/CF entry, but background workers already do show up in pg_stat_activity. (You can verify that by testing the background sessions patch.) So which additional things are we aiming to see with this? In practice, I think it's common to do a quick sele

Re: [HACKERS] Documentation improvements for partitioning

Robert Haas writes: > This is about list-ifying a note, but I think we should try to > de-note-ify it. It's a giant block of text that is not obviously more > noteworthy than the surrounding text; I think should be saved > for things that particularly need to be called out. Yeah. A big problem

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Robert Haas writes: > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote: >> If you don't want to make ExecInitExpr responsible, then the planner would >> have to do something like split_pathtarget_at_srf anyway to decompose the >> expressions, no matter which executor representation we use. > Did

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote: > >> If you don't want to make ExecInitExpr responsible, then the planner would > >> have to do something like split_pathtarget_at_srf anyway to decompose the > >> expressi

Re: [HACKERS] adding an immutable variant of to_date

Thanks! On 08.03.2017 17:37, Andreas Karlsson wrote: The current code for to_char will on the first call to to_char build arrays with the localized names of the week days and the months. I suspect that you may need to build something similar but a set of arrays per locale. Not sure what the

Re: [HACKERS] adding an immutable variant of to_date

On 08.03.2017 03:37, Robert Haas wrote: The commit message for 64353640e87b54250f1b8a1d2a708d270dff4bfd has some interesting perspective on this. """ Also, mark to_date() and to_char(interval) as stable; although these appear not to depend on any GUC variables as of CVS HEAD, that seems a prope

[HACKERS] Upgrading postmaster's log messages about bind/listen errors

Over in https://www.postgresql.org/message-id/flat/201703072317.01345.john.iliffe%40iliffe.ca we spent quite a lot of effort to diagnose what turned out to be a simple networking misconfiguration. It would probably have taken a lot less effort if the postmaster were more forthcoming about exactly

Re: [HACKERS] cast result of copyNode()

On 3/7/17 18:27, Mark Dilger wrote: > You appear to be using a #define macro to wrap a function of the same name > with the code: > > #define copyObject(obj) ((typeof(obj)) copyObject(obj)) Yeah, that's a bit silly. Here is an updated version that changes that. -- Peter Eisentraut

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

On Thu, Mar 9, 2017 at 2:30 PM, Peter Eisentraut wrote: > Perhaps I'm confused by the title of this thread/CF entry, but > background workers already do show up in pg_stat_activity. (You can > verify that by testing the background sessions patch.) So which > additional things are we aiming to se

  1   2   3   >