Re: [HACKERS] patch: function xmltable

2016-09-12 6:36 GMT+02:00 Craig Ringer : > On 12 September 2016 at 12:28, Craig Ringer wrote: > >> I'll take a closer read-through shortly. > > >DEFAULT > > isn't a normal literal, it's an xpath expression evaluated at the same > > time as the

Re: [HACKERS] patch: function xmltable

2016-09-12 6:28 GMT+02:00 Craig Ringer : > > I'll take a closer read-through shortly. > > > Missing file. You omitted executor/tableexpr.h from the patch, so I > can't compile. > > I've expanded and copy-edited the docs. Some of it is guesswork based > on the references you

Re: [HACKERS] patch: function xmltable

2016-09-12 6:36 GMT+02:00 Craig Ringer : > On 12 September 2016 at 12:28, Craig Ringer wrote: > >> I'll take a closer read-through shortly. > > >DEFAULT > > isn't a normal literal, it's an xpath expression evaluated at the same > > time as the

Re: [HACKERS] patch: function xmltable

On 12 September 2016 at 12:28, Craig Ringer wrote: >> I'll take a closer read-through shortly. >DEFAULT > isn't a normal literal, it's an xpath expression evaluated at the same > time as the rowexpression. Sorry for the spam, but turns out that's not the case as

Re: [HACKERS] patch: function xmltable

> I'll take a closer read-through shortly. Missing file. You omitted executor/tableexpr.h from the patch, so I can't compile. I've expanded and copy-edited the docs. Some of it is guesswork based on the references you sent and a glance at the code. Please check my changes carefully. I found a

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

On 9/11/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 9/11/16, Kevin Grittner wrote: >>> I was able to find cases during test which were not handled >>> correctly with either version, so I tweaked the query a little. > >>

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Sun, Sep 11, 2016 at 3:01 PM, Mark Kirkwood wrote: > On 11/09/16 19:16, Mark Kirkwood wrote: > >> >> >> On 11/09/16 17:01, Amit Kapila wrote: >>> >>> ...Do you think we can do some read-only >>> workload benchmarking using this server? If yes, then probably you

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

On Mon, Sep 12, 2016 at 11:38 AM, Tom Lane wrote: > Michael Paquier writes: >> Indeed, and the query field does not have much more meaning for a WAL >> sender. So I'd propose the attached for 9.6 and HEAD. I have thought >> about reporting that to

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Mon, Sep 12, 2016 at 7:00 AM, Jeff Janes wrote: > On Thu, Sep 8, 2016 at 12:09 PM, Jeff Janes wrote: > >> >> I plan to do testing using my own testing harness after changing it to >> insert a lot of dummy tuples (ones with negative values in the

Re: [HACKERS] Forbid use of LF and CR characters in database and role names

On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote: > I discourage documenting LF/CR restrictions. For the epsilon of readers who > would benefit from this knowledge, the error message suffices. For everyone > else, it would just dilute the text. (One could argue against

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

Michael Paquier writes: > Indeed, and the query field does not have much more meaning for a WAL > sender. So I'd propose the attached for 9.6 and HEAD. I have thought > about reporting that to pgstat in StartReplication(), but as there is > some error handling there I'd

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

On Mon, Sep 12, 2016 at 10:16 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Michael Paquier writes: >> > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote: >> >> The fact that the pg_stat_replication view

Re: [HACKERS] patch: function xmltable

On 9 September 2016 at 21:44, Pavel Stehule wrote: > > > 2016-09-09 10:35 GMT+02:00 Pavel Stehule : >> >> Hi, >> >> I am sending new version of this patch >> >> 1. now generic TableExpr is better separated from a real content >> generation >> 2. I

Re: [HACKERS] Add support for restrictive RLS policies

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote: > > Stephen Frost writes: > >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > >>> Can't you keep those words as Sconst or something (DefElems?)

Re: [HACKERS] Add support for restrictive RLS policies

On Thu, Sep 8, 2016 at 5:21 PM, Tom Lane wrote: > Stephen Frost writes: >> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: >>> Can't you keep those words as Sconst or something (DefElems?) until the >>> execution phase, so that they don't need to be

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Sep 8, 2016 at 12:09 PM, Jeff Janes wrote: > I plan to do testing using my own testing harness after changing it to > insert a lot of dummy tuples (ones with negative values in the pseudo-pk > column, which are never queried by the core part of the harness) and >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Michael Paquier writes: > > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote: > >> The fact that the pg_stat_replication view does show walsender processes > >> seems like possibly a reasonable argument for

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

Michael Paquier writes: > On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote: >> The fact that the pg_stat_replication view does show walsender processes >> seems like possibly a reasonable argument for not showing them in >> pg_stat_activity. But

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

Vitaly Burovoy writes: > On 9/11/16, Kevin Grittner wrote: >> I was able to find cases during test which were not handled >> correctly with either version, so I tweaked the query a little. > Hmm. Which one? Attempt to "SET ROLE "? > Unfortunately, I

Re: [HACKERS] Forbid use of LF and CR characters in database and role names

On Thu, Sep 08, 2016 at 12:12:49PM -0400, Peter Eisentraut wrote: > On 9/6/16 1:42 PM, Robert Haas wrote: > > On Tue, Sep 6, 2016 at 9:43 PM, Peter Eisentraut > > wrote: > > > Everything that is using appendShellString() is now going to reject LF > > > and CR

Re: [HACKERS] Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn

On Sun, Sep 11, 2016 at 5:21 AM, Tom Lane wrote: > The fact that the pg_stat_replication view does show walsender processes > seems like possibly a reasonable argument for not showing them in > pg_stat_activity. But we'd have to do some rejiggering of the view > definition to

[HACKERS] CommitFest 2016-09 status summary

Hi all, The current status summary is: Needs review: 81 Waiting on author: 35 Ready for Commiter: 12 Commited: 78 Moved to next CF: 1 Rejected: 6 Returned with feedback: 6 TOTAL: 219 The current progress is ~39%. The things moving fast but 27 patches still with no signed reviewer. So if you

Re: [HACKERS] Tuplesort merge pre-reading

On 12/09/16 12:16, Gavin Flower wrote: [...] two blocks would be logically adjacent (which means they are likely to be physically close together, but not guaranteed!). [...] Actual disk layouts are quite complicated, the above is an over simplification, but the message is still valid.

Re: [HACKERS] Tuplesort merge pre-reading

On 12/09/16 10:13, Peter Geoghegan wrote: On Sun, Sep 11, 2016 at 8:47 AM, Heikki Linnakangas wrote: [...] I don't know what the difference is between accessing 10 pages randomly, and accessing a random set of 10 single pages sequentially, in close succession. As Tom would

Re: [HACKERS] Tuplesort merge pre-reading

On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote: >> + for (tapenum = 0; tapenum < maxTapes; tapenum++) >> + { >> + LogicalTapeAssignReadBufferSize(state->tapeset, tapenum, >> + (per_tape + (tapenum < cutoff ? 1 : >> 0)) *

Re: [HACKERS] Merge Join with an Index Optimization

On Sun, Sep 11, 2016 at 11:07 PM, Michael Malis wrote: > On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote: >> >> Michael Malis writes: >> >> As I understand it, a merge join will currently read all tuples from >> >> both >> >>

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

On 9/11/16, Kevin Grittner wrote: > On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy >> Mark it as "Ready for committer". >> >> P.S.: While I was reviewing I simplified SQL query: improved version >> only 2 seqscans instead of 3 seqscans with an inner loop in an >> original

Re: [HACKERS] Tuplesort merge pre-reading

On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote: > * Doesn't this code need to call MemoryContextAllocHuge() rather than > palloc()?: > >> @@ -709,18 +765,19 @@ LogicalTapeRewind(LogicalTapeSet *lts, int tapenum, >> bool forWrite) >> Assert(lt->frozen); >>

[HACKERS] Typo in filename identification

The IDENTIFICATION filename in src/backend/storage/ipc/dsm_impl.c is incorrectly labelling the file dsm.c. Patch fixing the typo attached. cheers ./daniel typo-dsm_impl_identification.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Tuplesort merge pre-reading

On Sun, Sep 11, 2016 at 3:13 PM, Peter Geoghegan wrote: > * Please make this use the ".., + 1023" natural rounding trick that is > used in the similar traces that are removed: > >> +#ifdef TRACE_SORT >> + if (trace_sort) >> + elog(LOG, "using %d kB of memory for read

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Mon, Sep 12, 2016 at 1:47 AM, Tom Lane wrote: > Looks reasonable to me, we'll soon see what the buildfarm thinks. Thanks for the commit. I am seeing green statuses on the buildfarm. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Tuplesort merge pre-reading

On Sun, Sep 11, 2016 at 8:47 AM, Heikki Linnakangas wrote: > Here's a new version of these patches, rebased over current master. I > squashed the two patches into one, there's not much point to keep them > separate. I think I have my head fully around this now. For some reason,

Re: [HACKERS] Merge Join with an Index Optimization

On Sun, Sep 11, 2016 at 9:20 AM Tom Lane wrote: > Michael Malis writes: > >> As I understand it, a merge join will currently read all tuples from > both > >> subqueries (besides early termination). I believe it should be possible > to > >> take

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy wrote: > Tested manually in versions 9.2 and 10devel, I hope it can be > back-patched to all supported versions. We don't normally back-patch tab completion work unless it is fixing a crash or removing displayed entries

Re: [HACKERS] WAL consistency check facility

Hello, Based on the previous discussions, I've modified the existing patch. >+ void(*rm_checkConsistency) (XLogReaderState *record); >All your _checkConsistency functions share the same pattern, in short >they all use a for loop for each block, call each time >XLogReadBufferExtended,

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

Kevin Grittner writes: > test=# create role fred with createdb; > CREATE ROLE > test=# create user bob; > CREATE ROLE > test=# grant fred to bob; > GRANT ROLE > test=# alter database postgres owner to fred; > ALTER DATABASE > test=# set role fred; > SET > test=> create database

Re: Install extensions using update scripts (was Re: [HACKERS] Remove superuser() checks from pgstattuple)

Pushed with adjustments for the review points. Hopefully this will make Stephen's life easier, along with others submitting contrib-module updates. We should urge anyone who submits an old-style extension update patch to consider whether they really want to bother with a new base script. At

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sun, Sep 11, 2016 at 6:28 AM, Heikki Linnakangas wrote: > Pushed this "displace root" patch, with some changes: Attached is rebased version of the entire patch series, which should be applied on top of what you pushed to the master branch today. This features a new scheme

Re: [HACKERS][REVIEW] Tab Completion for CREATE DATABASE ... TEMPLATE ...

On Sat, Sep 10, 2016 at 12:26 AM, Vitaly Burovoy wrote: > According to the documentation since 9.2 till devel a database can be > used as a template if it has a "datistemplate" mark or by superusers > or by their owners. Hm. I wonder whether the following failure of

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote: >> It might accidentally fail to fail as-is, but likely it would be better >> not to be pushing garbage paths into extraincludes and extralibs when >> some of those options

Re: [HACKERS] [GENERAL] C++ port of Postgres

Some of your patches look useful, but unrelated to C++: 7, 8, 15, 16(?), 20. I applied that subset to 9.6 and got a clean "make check". Would it make sense to add them to the next commitfest, regardless of the C++ effort? On Wed, Aug 31, 2016 at 9:41 AM, Peter Eisentraut

Re: [HACKERS] Merge Join with an Index Optimization

Michael Malis writes: > As I understand it, a merge join will currently read all tuples from both > subqueries (besides early termination). I believe it should be possible to > take advantages of the indexes on one or both of the tables being read from > to skip a large

Re: [HACKERS] cost_sort() may need to be updated

On Sun, Sep 11, 2016 at 9:01 AM, Tom Lane wrote: > Peter Geoghegan writes: >> I think that we *can* refine this guess, and should, because random >> I/O is really quite unlikely to be a large cost these days (I/O in >> general often isn't a large cost,

Re: [HACKERS] cost_sort() may need to be updated

Peter Geoghegan writes: > I think that we *can* refine this guess, and should, because random > I/O is really quite unlikely to be a large cost these days (I/O in > general often isn't a large cost, actually). More fundamentally, I > think it's a problem that cost_sort() thinks

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sun, Sep 11, 2016 at 6:28 AM, Heikki Linnakangas wrote: > * I renamed "tuplesort_heap_siftup()" to "tuplesort_delete_top()". I realize > that this is controversial, per the discussion on the "Is > tuplesort_heap_siftup() a misnomer?" thread. However, now that we have a new >

Re: [HACKERS] Tuplesort merge pre-reading

Here's a new version of these patches, rebased over current master. I squashed the two patches into one, there's not much point to keep them separate. - Heikki >From 6e3813d876cf3efbe5f1b80c45f44ed5494304ab Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date:

Re: [HACKERS] Use nanosleep() for pg_usleep() on Unix/Linux?

Paul Guo writes: > I happened to read the pg_usleep() code recently. I'm wondering > if we could implement it using the posix function nanosleep(), > instead of by select(). That actually looks like a pretty good idea. Some research says that nanosleep() is defined in SUSv2,

Re: [HACKERS] [PATCH] Alter or rename enum value

Jim Nasby writes: > On 9/8/16 4:55 AM, Emre Hasegeli wrote: >> The main problem that has been discussed before was the indexes. One >> way is to tackle with it is to reindex all the tables after the >> operation. Currently we are doing it when the datatype of indexed

Re: [HACKERS] [GENERAL] C++ port of Postgres

> P.S. I'm asking because I was planning to review that patch. But I >> can't tell if any more review by a non-committer is still required by >> the commitfest workflow. > > > I think this has gotten enough attention, for the commitfest workflow. The > workflow is flexible, depending on the

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 09/11/2016 01:20 AM, Christian Convey wrote: Hi Heikki, Could I ask you a newbie-reviewer question about something I'm seeing here? https://commitfest.postgresql.org/10/776/ From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides), I got the impression that a successful patch

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 09/11/2016 01:20 AM, Christian Convey wrote: Hi Heikki, Could I ask you a newbie-reviewer question about something I'm seeing here? https://commitfest.postgresql.org/10/776/ From some reading I've done (e.g., Stephen Frost's PGCon 2011 slides), I got the impression that a successful patch

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On 09/10/2016 03:22 AM, Claudio Freire wrote: Overall, however, I believe the patch is in good shape. Only minor form issues need to be changed, the functionality seems both desirable and ready. Pushed this "displace root" patch, with some changes: * I renamed "tuplesort_heap_siftup()" to

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote: > It might accidentally fail to fail as-is, but likely it would be better > not to be pushing garbage paths into extraincludes and extralibs when > some of those options aren't set. Right, we need to correct something here. But

Re: [HACKERS] Override compile time log levels of specific messages/modules

On 11 Sep. 2016 11:31, "Jim Nasby" wrote: > Actually, I wish this was a straight-up logging level feature, because I need it all the time when debugging complicated user-level code. Specifically, I wish there was a GUC that would alter (client|log)_min_messages upon

[HACKERS] Use nanosleep() for pg_usleep() on Unix/Linux?

I happened to read the pg_usleep() code recently. I'm wondering if we could implement it using the posix function nanosleep(), instead of by select(). nanosleep() is designed with higher time resolution, besides it provide remaining time if is interrupted by signal so that pg_usleep() could be

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 11/09/16 19:16, Mark Kirkwood wrote: On 11/09/16 17:01, Amit Kapila wrote: ...Do you think we can do some read-only workload benchmarking using this server? If yes, then probably you can use concurrent hash index patch [1] and cache the metapage patch [2] (I think Mithun needs to rebase

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 11/09/16 17:01, Amit Kapila wrote: On Sun, Sep 11, 2016 at 4:10 AM, Mark Kirkwood wrote: performed several 10 hour runs on size 100 database using 32 and 64 clients. For the last run I rebuilt with assertions enabled. No hangs or assertion failures.

Re: [HACKERS] [PATCH] Alter or rename enum value

> Why not just disallow dropping a value that's still in use? That's certainly > what I would prefer to happen by default... Of course, we should disallow it. That problem is what to do next. We cannot just remove the value, because it might still be referenced from the inner nodes of the