[HACKERS] Bug in intarray bench script

In the contrib/intarray benchmarking script bench.pl, the -e option to print the plan via EXPLAIN is using the DBI do() method which discards output resulting in nothing being printed. Judging by the usage help (“show explain”) I assume the intention is to print the plan to STDOUT when invoked

Re: [HACKERS] Declarative partitioning

Hi Ildar, On 2016/05/16 22:12, Ildar Musin wrote: > Hi Amit, > > I'm running some experiments based on your infrastructure trying to > optimize SELECT queries. At some point I need to get PartitionDesc for > relation and to do it I'm using RelationGetPartitionDesc() function. > Problem is that

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

On 5/10/16 4:12 PM, Andres Freund wrote: The catalog representation (as in pg_class.reltoastrelid) isn't entirely clear to me. One way would be to invert pg_class.reltoastrelid's meaning and have the toast table point to the table it stores values for. That'd also open the potential of having

Re: [HACKERS] 10.0

On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote: > On 14 May 2016 at 02:49, Tom Lane wrote: > > * This year's major release will be 9.6.0, with minor updates 9.6.1, > > 9.6.2, etc. It's too late to do otherwise for this release cycle. > > > > * Next year's major

Re: [HACKERS] Backup doc typo

On Mon, May 16, 2016 at 6:08 AM, Amit Langote wrote: > Hi, > > Attached patch adds missing "is" in a sentence in backup.sgml. > Applied, thanks! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Does Type Have = Operator?

On 5/12/16 4:25 PM, David E. Wheeler wrote: On May 12, 2016, at 12:02 PM, Tom Lane wrote: Andrew mentions in the extension you pointed to that providing a default comparison operator would enable people to do UNION, DISTINCT, etc on JSON columns without thinking about it.

Re: [HACKERS] Does Type Have = Operator?

On 5/11/16 7:05 PM, David E. Wheeler wrote: On May 11, 2016, at 10:34 AM, Kevin Grittner wrote: I'm not clear enough on your intended usage to know whether these operators are a good fit, but they are sitting there waiting to be used if they do fit. Huh. I haven’t had any

[HACKERS] Parameters don't work in FETCH NEXT clause?

A user of mine just raised a strange issue... While it is possible to use a parameter in a LIMIT clause, PostgreSQL does not seem to allow using one in a FETCH NEXT clause. In other words, while the following works: SELECT 1 LIMIT $1; The following generates a syntax error: SELECT 1 FETCH NEXT

Re: [HACKERS] Does Type Have = Operator?

On May 17, 2016, at 7:58 AM, Jim Nasby wrote: > Probably in an attempt to bypass parse overhead on ingestion. > > Possibly because JSONB silently eats duplicated keys while JSON doesn't > (though in that case even casting to JSONB is probably not what you want). It’s

Re: [HACKERS] Does Type Have = Operator?

Sorry for the pgTAP off-topicness here, hackers. Please feel free to ignore. On May 17, 2016, at 8:10 AM, Jim Nasby wrote: > Speaking specifically to is(), what I'd find most useful is if it at least > hinted that there might be some type shenanigans going on, because

Re: [HACKERS] Re: [COMMITTERS] pgsql: Correctly align page's images in generic wal API

Teodor Sigaev writes: >> Instead of allocating this memory unconditionally for each buffer, >> wouldn't it be better to set all the page pointers to NULL in >> GenericXLogStart and allocate memory only once a buffer is registered >> in GenericXLogRegisterBuffer when finding a

Re: [HACKERS] 10.0

On 5/17/16 10:51 AM, David Fetter wrote: > On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote: >> On 14 May 2016 at 02:49, Tom Lane wrote: >>> * This year's major release will be 9.6.0, with minor updates 9.6.1, >>> 9.6.2, etc. It's too late to do otherwise for

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

Thanks for the commit. I have tested it again. Not getting server crash now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB Corporation On Mon, May 16, 2016 at 9:38 PM, Robert Haas wrote: > On Fri, May 13, 2016 at 6:40 PM, Michael Paquier >

Re: [HACKERS] Parameters don't work in FETCH NEXT clause?

Shay Rojansky writes: > A user of mine just raised a strange issue... While it is possible to use a > parameter in a LIMIT clause, PostgreSQL does not seem to allow using one in > a FETCH NEXT clause. In other words, while the following works: > SELECT 1 LIMIT $1; > The following

Re: [HACKERS] 10.0

On 17 May 2016 at 10:37, David Steele wrote: > On 5/17/16 10:51 AM, David Fetter wrote: > >> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote: >>> On 14 May 2016 at 02:49, Tom Lane wrote: * This year's major release will be 9.6.0, with

Re: [HACKERS] Parameters don't work in FETCH NEXT clause?

Apologies, as usual I didn't read the docs carefully enough. On Tue, May 17, 2016 at 7:13 PM, Tom Lane wrote: > Shay Rojansky writes: > > A user of mine just raised a strange issue... While it is possible to > use a > > parameter in a LIMIT clause, PostgreSQL

Re: [HACKERS] A couple of cosmetic changes around shared memory code

Michael Paquier writes: > On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak > wrote: > -toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry) > +toc_bytes = offsetof(shm_toc, toc_entry) + nentry *

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

On Tue, May 10, 2016 at 02:06:19PM -0400, Tom Lane wrote: > Sooner or later we are going to need to go to 8-byte TOAST object > identifiers. Maybe we should think about doing that sooner not > later rather than trying to invent some anti-wraparound solution > here. Yay! Is there any lift in

Re: [HACKERS] Declarative partitioning

Amit Langote writes: > On 2016/05/16 22:12, Ildar Musin wrote: >> Could you please tell is >> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE >> query? > Hmm, I think invalidation would not occur mid-query since it would have > acquired a

[HACKERS] seg fault in contrib/bloom

I'm getting seg faults on contrib/bloom when updating a tuple which was found via a bloom index. It does not happen on every update, but it does happen within a few seconds of run time, so it is readily reproducible. The test harness is a bit of a mess, I'll try to clean it up and post it if no

[HACKERS] Jsonb array-style subscripting, generic version

Hi With regard to previous conversations: http://www.postgresql.org/message-id/flat/CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com#CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com

Re: [HACKERS] Parameters don't work in FETCH NEXT clause?

On Tue, May 17, 2016 at 12:15 PM, Shay Rojansky wrote: > Apologies, as usual I didn't read the docs carefully enough. > > On Tue, May 17, 2016 at 7:13 PM, Tom Lane wrote: > >> Shay Rojansky writes: >> > A user of mine just raised a strange

Re: [HACKERS] seg fault in contrib/bloom

Jeff Janes writes: > I'm getting seg faults on contrib/bloom when updating a tuple which > was found via a bloom index. > It does not happen on every update, but it does happen within a few > seconds of run time, so it is readily reproducible. The test harness > is a bit of

Re: [HACKERS] Reviewing freeze map code

On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote: > On Tue, May 10, 2016 at 10:40 PM, Masahiko Sawada > wrote: >> Or second way I came up with is having tool to remove particular _vm >> file safely, which is executed via SQL or client tool like

[HACKERS] Parallel query and temp_file_limit

temp_file_limit "specifies the maximum amount of disk space that a session can use for temporary files, such as sort and hash temporary files", according to the documentation. That's not true when parallel query is in use, since the global variable temporary_files_size receives no special

Re: [HACKERS] Reviewing freeze map code

Masahiko Sawada wrote: > On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote: > > We should support scan_all only with the new-style options syntax for > > VACUUM; that is, vacuum (scan_all) rename. That doesn't require > > making scan_all a keyword, which is good: this

[HACKERS] Re: [COMMITTERS] pgsql: Allocate all page images at once in generic wal interface

Allocate all page images at once in generic wal interface That reduces number of allocation. Per gripe from Michael Paquier and Tom Lane suggestion. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/7c979c95a3700d0bd34c2831f49a9260d505b0f9 Modified Files

Re: [HACKERS] Reviewing freeze map code

On Tue, May 17, 2016 at 3:32 PM, Alvaro Herrera wrote: > Masahiko Sawada wrote: >> On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote: > >> > We should support scan_all only with the new-style options syntax for >> > VACUUM; that is, vacuum

Re: [HACKERS] Reviewing freeze map code

On 05/17/2016 12:32 PM, Alvaro Herrera wrote: Syntaxes are; VACUUM (SCAN_ALL) table_name; VACUUM (SCAN_ALL); -- for all tables on database Is SCAN_ALL really the best we can do here? The business of having an underscore in an option name has no precedent (other than CURRENT_DATABASE

Re: [HACKERS] Parallel query and temp_file_limit

On Wed, May 18, 2016 at 12:55 AM, Peter Geoghegan wrote: > > temp_file_limit "specifies the maximum amount of disk space that a > session can use for temporary files, such as sort and hash temporary > files", according to the documentation. That's not true when parallel > query

[HACKERS] foreign table batch inserts

Hi, I realized that inserts into foreign tables are only done row by row. Consider copying data from one local table to a foreign table with INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM local_table; When the foreign server is for example in another datacenter with long latency, this as

Re: [HACKERS] seg fault in contrib/bloom

Jeff Janes writes: > I'm getting seg faults on contrib/bloom when updating a tuple which > was found via a bloom index. I pushed a patch that should fix this, but without having tried to reproduce the problem locally; so possibly I guessed wrong as to what is causing it.

Re: [HACKERS] Parameters don't work in FETCH NEXT clause?

> > ​Would something like this be valid? > > OFFSET { start_literal | ( start_expression ) } { ROW | ROWS } > FETCH { FIRST | NEXT} [ count_literal | ( count_expression ) ] { ROW | > ROWS } ONLY > > Leaving the mandatory parentheses detail to the description, while > adequate, seems insufficient -

Re: [HACKERS] Reviewing freeze map code

On Tue, May 17, 2016 at 4:34 PM, Joshua D. Drake wrote: > On 05/17/2016 12:32 PM, Alvaro Herrera wrote: > >> Syntaxes are; >> VACUUM (SCAN_ALL) table_name; >> VACUUM (SCAN_ALL); -- for all tables on database >> >> Is SCAN_ALL really the best we can do here? The

Re: [HACKERS] Reviewing freeze map code

On 17/05/16 21:32, Alvaro Herrera wrote: > Is SCAN_ALL really the best we can do here? The business of having an > underscore in an option name has no precedent (other than > CURRENT_DATABASE and the like). ALTER DATABASE has options for ALLOW_CONNECTIONS, CONNECTION_LIMIT, and IS_TEMPLATE. >

Re: [HACKERS] seg fault in contrib/bloom

On Tue, May 17, 2016 at 2:02 PM, Tom Lane wrote: > Jeff Janes writes: >> I'm getting seg faults on contrib/bloom when updating a tuple which >> was found via a bloom index. > > I pushed a patch that should fix this, but without having tried to >

Re: [HACKERS] Reviewing freeze map code

On 18/05/16 09:34, Vik Fearing wrote: On 17/05/16 21:32, Alvaro Herrera wrote: Is SCAN_ALL really the best we can do here? The business of having an underscore in an option name has no precedent (other than CURRENT_DATABASE and the like). ALTER DATABASE has options for ALLOW_CONNECTIONS,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Allocate all page images at once in generic wal interface

Teodor Sigaev writes: > Seems, this patch isn't liked by curculio [1] buildfarm member, but I'm > confused > with diagnostics: > 2016-05-17 21:43:19.489 CEST [573b7457.547c:3] LOG: statement: CREATE > EXTENSION > bloom; > 2016-05-17 21:43:19.501 CEST [573b7457.547c:4]

Re: [HACKERS] foreign table batch inserts

On Wed, May 18, 2016 at 6:00 AM, Manuel Kniep wrote: > I realized that inserts into foreign tables are only done row by row. > Consider copying data from one local table to a foreign table with > > INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM local_table; > > When the

Re: [HACKERS] Parallel query and temp_file_limit

On Tue, May 17, 2016 at 1:53 PM, Amit Kapila wrote: > What kind of special treatment are you expecting for temporary_files_size, > also why do you think it is required? Currently neither we build hash in > parallel nor there is any form of parallel sort work. I expect

Re: [HACKERS] Parallel query and temp_file_limit

On Tue, May 17, 2016 at 3:33 PM, Peter Geoghegan wrote: > Fundamentally, since temporary_files_size enforcement simply > piggy-backs on low-level fd.c file management, without any > consideration of what the temp files contain, it'll be hard to be sure > that parallel workers

Re: [HACKERS] Declarative partitioning

On 2016/05/18 2:22, Tom Lane wrote: > Amit Langote writes: >> On 2016/05/16 22:12, Ildar Musin wrote: >>> Could you please tell is >>> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE >>> query? > >> Hmm, I think invalidation would not

[HACKERS] roadmap sharing

Hi, Today at the developer meeting - https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting - there was some talk of sharing corporate roadmaps. Postgres Pro put their roadmap up at https://wiki.postgresql.org/wiki/Postgres_Professional_roadmap and I have now done the same thing for the