Re: [HACKERS] Statement timeout behavior in extended queries

On 2017-04-04 06:35:00 +, Tsunakawa, Takayuki wrote: > From: Andres Freund [mailto:and...@anarazel.de] > Given the concern raised in > > http://archives.postgresql.org/message-id/12207.1491228316%40sss.pgh.p > > a.us > > I don't see this being ready for committer. > > If what Tatsuo-san said t

Re: [HACKERS] strange parallel query behavior after OOM crashes

Looking further in this context, number of active parallel workers is: parallel_register_count - parallel_terminate_count Can active workers ever be greater than max_parallel_workers, I think no. Then why should there be greater than check in the following condition: if (parallel && (Back

Re: [HACKERS] Statement timeout behavior in extended queries

From: Andres Freund [mailto:and...@anarazel.de] Given the concern raised in > http://archives.postgresql.org/message-id/12207.1491228316%40sss.pgh.p > a.us > I don't see this being ready for committer. If what Tatsuo-san said to Tom is correct (i.e. each Parse/Bind/Execute starts and stops the ti

Re: [HACKERS] ANALYZE command progress checker

On Tue, Apr 4, 2017 at 2:12 PM, Amit Langote wrote: > On 2017/03/30 17:39, Masahiko Sawada wrote: >> On Wed, Mar 29, 2017 at 5:38 PM, vinayak wrote: > I have updated the patch. >> >> I reviewed v7 patch. >> >> When I ran ANALYZE command to the table having 5 millions rows with 3 >> child table

Re: [HACKERS] Statement timeout behavior in extended queries

On 2017-04-04 06:18:04 +, Tsunakawa, Takayuki wrote: > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > > It's too late. Someone has already moved the patch to the next CF (for > > PostgreSQL 11). > > Yes, but this patch will be necessary by the final release of PG 10 if the > libpq batch/pip

Re: [HACKERS] Supporting huge pages on Windows

On 2017-01-05 03:12:09 +, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > > For the pg_ctl changes, we're going from removing all privilieges from the > > token, to removing none. Are there any

Re: [HACKERS] Statement timeout behavior in extended queries

From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > It's too late. Someone has already moved the patch to the next CF (for > PostgreSQL 11). Yes, but this patch will be necessary by the final release of PG 10 if the libpq batch/pipelining is committed in PG 10. I marked this as ready for committer

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > I don't think the errdetail is quite right - OpenProcessToken isn't really > a syscall, is it? But then it's a common pattern already in wind32_shmem.c... Yes, "Win32 API function" w

[HACKERS] Letting the client choose the protocol to use during a SASL exchange

Hi all, There is still one open item pending for SCRAM that has not been treated which is mentioned here: https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi When doing an authentication with SASL, the server decides what is the mechanism that the client has to use.

Re: [HACKERS] postgres_fdw bug in 9.6

Probably we should use "could not be created" instead of "was not created" in "... a local path suitable for EPQ checks was not created". "outer_path should not require relations from inner_path" may be reworded as "outer paths should not be parameterized by the inner relations". "neither path sh

Re: [HACKERS] Statement timeout behavior in extended queries

> The patch doesn't seem to behave like that. The Parse message calls > start_xact_command() -> enable_statement_timeout() -> enable_timeout(), and > set stmt_timer_started to true. Subsequent Bind and Execute messages call > enable_statement_timeout(), but enable_statement_timeout() doesn't c

Re: [HACKERS] Parallel Append implementation

Thanks Andres for your review comments. Will get back with the other comments, but meanwhile some queries about the below particular comment ... On 4 April 2017 at 10:17, Andres Freund wrote: > On 2017-04-03 22:13:18 -0400, Robert Haas wrote: >> On Mon, Apr 3, 2017 at 4:17 PM, Andres Freund wrot

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > Actually the statement timer is replaced with new statement timer value > in enable_statement_timeout(). The patch doesn't seem to behave like that. The Parse message calls start_xa

Re: [HACKERS] ANALYZE command progress checker

On 2017/04/04 14:15, Amit Langote wrote: > On 2017/04/04 14:12, Amit Langote wrote: >> Two kinds of statistics are collected if the table is a inheritance parent. >> >> First kind considers the table by itself and calculates regular >> single-table statistics using rows sampled from the only availa

Re: [HACKERS] [PATCH] Incremental sort

On 2017-04-03 22:18:21 -0400, Robert Haas wrote: > On Mon, Apr 3, 2017 at 5:09 PM, Andres Freund wrote: > > To me this hasn't gotten even remotely enough performance evaluation. > > And I don't think it's fair to characterize it as pending since 2013, > > given it was essentially "waiting on autho

Re: [HACKERS] ANALYZE command progress checker

On 2017/04/04 14:12, Amit Langote wrote: > Two kinds of statistics are collected if the table is a inheritance parent. > > First kind considers the table by itself and calculates regular > single-table statistics using rows sampled from the only available heap > (by calling do_analyze_rel() with i

Re: [HACKERS] ANALYZE command progress checker

On 2017/03/30 17:39, Masahiko Sawada wrote: > On Wed, Mar 29, 2017 at 5:38 PM, vinayak wrote: I have updated the patch. > > I reviewed v7 patch. > > When I ran ANALYZE command to the table having 5 millions rows with 3 > child tables, the progress report I got shows the strange result. The >

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Mar 30, 2017 at 12:00 PM, Haribabu Kommi wrote: > > > On Wed, Mar 29, 2017 at 11:04 PM, Andreas Karlsson > wrote: > >> On 03/29/2017 05:43 AM, Haribabu Kommi wrote: >> > Updated patch attached. >> >> I get a test failure in the pg_upgrade tests, but I do not have time >> right now to inv

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-04-04 08:57:33 +0900, Michael Paquier wrote: > On Tue, Apr 4, 2017 at 8:26 AM, Andres Freund wrote: > > On 2017-04-04 09:24:23 +1000, Vaishnavi Prabakaran wrote: > >> Just quickly, Is it not ok to consider only the code patch for this CF > >> without test patch? > > > > I'd say no, it's no

Re: [HACKERS] Parallel Append implementation

On 2017-04-03 22:13:18 -0400, Robert Haas wrote: > On Mon, Apr 3, 2017 at 4:17 PM, Andres Freund wrote: > > Hm. I'm not really convinced by the logic here. Wouldn't it be better > > to try to compute the minimum total cost across all workers for > > 1..#max_workers for the plans in an iterative

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Thu, Mar 30, 2017 at 11:17 PM, Bruce Momjian wrote: > On Tue, Mar 21, 2017 at 04:04:58PM -0400, Bruce Momjian wrote: > > On Tue, Mar 21, 2017 at 04:56:16PM -0300, Alvaro Herrera wrote: > > > Bruce Momjian wrote: > > > > On Tue, Mar 21, 2017 at 04:43:58PM -0300, Alvaro Herrera wrote: > > > > >

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-03 21:24 GMT+02:00 Fabien COELHO : > > Hello Tom, > > \if [select current_setting('server_version_num')::int < 11] >>> >> >> I really dislike this syntax proposal. >> > > It would get us into having to count nested brackets, and distinguish >> quoted from unquoted brackets, and so on

Re: [HACKERS] Instead of DROP function use UPDATE pg_proc in an upgrade extension script

> "Vicky" == Vicky Vergara writes: Vicky> UPDATE pg_proc SET [...] Vicky> So, I want to know how "safe" can you consider the second Vicky> method, and what kind of other objects do I need to test besides Vicky> views. Speaking from personal experience (I did this in the upgrade script f

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Fri, Mar 31, 2017 at 12:31 PM, Dilip Kumar wrote: > On Thu, Mar 30, 2017 at 5:27 PM, Amit Kapila > wrote: > > I am not sure if we can consider it as completely synthetic because we > > might see some similar cases for json datatypes. Can we once try to > > see the impact when the same test r

Re: [HACKERS] Instead of DROP function use UPDATE pg_proc in an upgrade extension script

2017-04-04 6:17 GMT+02:00 Vicky Vergara : > > Hello, > > > When creating an extension upgrade sql script, because the function does > not have the same parameter names and/or parameters type and/or the result > types changes, there is the need to drop the function because otherwise the > CREATE OR

[HACKERS] Compiler warning in costsize.c

Hi all, In builds where USE_ASSERT_CHECKING is not enabled, costsize.c can generate warnings. Here is for example with MSVC: src/backend/optimizer/path/costsize.c(4520): warning C4101: 'rte' : unreferen ced local variable [C:\Users\ioltas\git\postgres\postgres.vcxproj] src/backend/optimizer/pa

[HACKERS] Instead of DROP function use UPDATE pg_proc in an upgrade extension script

Hello, When creating an extension upgrade sql script, because the function does not have the same parameter names and/or parameters type and/or the result types changes, there is the need to drop the function because otherwise the CREATE OR REPLACE of the new signature will fail. So for exa

Re: [HACKERS] wait event documentation

On 2017/04/03 22:32, Robert Haas wrote: > Right now, the information on wait events is organized into one giant > table inside > https://www.postgresql.org/docs/devel/static/monitoring-stats.html#monitoring-stats-views > -- the wait event type is inserted into the lefthand column of the > table us

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Daniel Gustafsson wrote: > Testing DefElem options is done with both strcmp() and pg_strcasecmp() a bit > mixed. Since the option defnames are all lowercased, either via IDENT, > keyword > rules or “by hand” with makeString(), using strcmp() is safe (and assumed to > be > so in quite a lot of pl

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Sat, Apr 1, 2017 at 3:29 AM, Mithun Cy wrote: > On Sat, Apr 1, 2017 at 12:31 PM, Mithun Cy wrote: >> Also adding a patch which implements the 2nd way. > Sorry, I forgot to add sortbuild_hash patch, which also needs similar > changes for the hash_mask. Committed. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Unable to build doc on latest head

On Tue, Apr 4, 2017 at 2:01 AM, Andrew Gierth wrote: > > "Peter" == Peter Eisentraut > writes: > > > On 4/3/17 02:44, Ashutosh Bapat wrote: > >> [1] says that id.attribute is supported in stylesheets version > >> 1.77.1. Do I need to update stylesheets version? How do I do it? > >> Any

Re: [HACKERS] Unable to build doc on latest head

On Mon, Apr 3, 2017 at 8:36 PM, Tom Lane wrote: > Ashutosh Bapat writes: > > Recently my doc build has started failing with errors > > runtime error: file stylesheet.xsl line 57 element call-template > > The called template 'id.attribute' was not found. > > > [1] says that id.attribute is suppor

Re: [HACKERS] pg_partman 3.0.0 - real-world usage of native partitioning and a case for native default

On Mon, Apr 3, 2017 at 10:45 PM, Keith Fiske wrote: > > On Mon, Apr 3, 2017 at 5:13 AM, Ashutosh Bapat < > ashutosh.ba...@enterprisedb.com> wrote: > >> >> >> On Fri, Mar 31, 2017 at 9:00 PM, Keith Fiske wrote: >> >>> I've gotten pg_partman working with native partitioning already so I can >>> ho

Re: [HACKERS] Statement timeout behavior in extended queries

> Where is the statement_timeout timer stopped when processing Parse and Bind > messages? Actually the statement timer is replaced with new statement timer value in enable_statement_timeout(). > Do you mean the following sequence of operations are performed in this patch? > > Parse(statement1)

Re: [HACKERS] Documentation improvements for partitioning

On Mon, Apr 3, 2017 at 12:52 AM, Amit Langote wrote: > I noticed what looks like a redundant line (or an incomplete sentence) in > the paragraph about multi-column partition keys. In the following text: > > + partitioning, if desired. Of course, this will often result in a > larger > +

Re: [HACKERS] Fix obsolete comment in GetSnapshotData

On Sun, Apr 2, 2017 at 9:29 PM, Craig Ringer wrote: > You're right, I muddled it with PROCARRAY_VACUUM_FLAG. > > PROCARRAY_FLAGS_VACUUM is sufficient. Committed that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mail

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > No. Parse, bind and Execute message indivually stops and starts the > statement_timeout timer with the patch. Unless there's a lock conflict, > parse and bind will take very short time

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

On Fri, Mar 31, 2017 at 10:02 PM, Ashutosh Sharma wrote: > As suggested, I am now acquiring lock inside the caller function. > Attached is the patch having this changes. Thanks. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] If an extension library is loaded during pg_upgrade, can it tell?

On 04/03/17 22:08, Bruce Momjian wrote: > On Mon, Apr 3, 2017 at 09:53:34PM -0400, Chapman Flack wrote: >> Hi, >> >> Is there any distinctive state that could be checked by extension code >> to determine that it has been loaded incidentally during the operation >> of pg_upgrade rather than under n

Re: [HACKERS] wait event documentation

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Instead of continuing to repair this every time it gets broken, I propose > that we break this into one table that lists all the wait_event_type values > -- LWLock, Lock, BufferPin, Act

Re: [HACKERS] [PATCH] Incremental sort

On Mon, Apr 3, 2017 at 5:09 PM, Andres Freund wrote: > To me this hasn't gotten even remotely enough performance evaluation. > And I don't think it's fair to characterize it as pending since 2013, > given it was essentially "waiting on author" for most of that. This is undeniably a patch which ha

Re: [HACKERS] Parallel Append implementation

On Mon, Apr 3, 2017 at 4:17 PM, Andres Freund wrote: > Hm. I'm not really convinced by the logic here. Wouldn't it be better > to try to compute the minimum total cost across all workers for > 1..#max_workers for the plans in an iterative manner? I.e. try to map > each of the subplans to 1 (if

Re: [HACKERS] postgres_fdw: evaluate placeholdervars on remote server

On 2017/04/04 3:21, Andres Freund wrote: On 2017-02-28 21:45:22 +0900, Etsuro Fujita wrote: Here is a patch for $subject. This is a nontrivial patch, submitted just before the start of the last CF for postgres 10. Therefore I think we should move this to the next CF. Honestly, I'm not satis

Re: [HACKERS] If an extension library is loaded during pg_upgrade, can it tell?

On Mon, Apr 3, 2017 at 09:53:34PM -0400, Chapman Flack wrote: > Hi, > > Is there any distinctive state that could be checked by extension code > to determine that it has been loaded incidentally during the operation > of pg_upgrade rather than under normal conditions? > > PL/Java ordinarily chec

[HACKERS] If an extension library is loaded during pg_upgrade, can it tell?

Hi, Is there any distinctive state that could be checked by extension code to determine that it has been loaded incidentally during the operation of pg_upgrade rather than under normal conditions? PL/Java ordinarily checks what version of its schema is around, but that may be premature while pg_u

Re: [HACKERS] Making clausesel.c Smarter

On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote: > On Mon, Apr 3, 2017 at 8:52 PM, David Rowley > wrote: >>> One last observation: >>> >>> +/* >>> + * An IS NOT NULL test is a no-op if there's any other strict >>> quals, >>> + * so if that's the case, then we'll only

Re: [HACKERS] ANALYZE command progress checker

On 2017/03/30 17:39, Masahiko Sawada wrote: On Wed, Mar 29, 2017 at 5:38 PM, vinayak wrote: On 2017/03/25 4:30, Robert Haas wrote: On Fri, Mar 24, 2017 at 3:41 AM, vinayak wrote: I have updated the patch. You can't change the definition of AcquireSampleRowsFunc without updating the documen

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Mar 30, 2017 at 12:55 AM, Stas Kelvich wrote: > >> On 28 Mar 2017, at 18:08, Andres Freund wrote: >> >> On 2017-03-28 15:55:15 +0100, Simon Riggs wrote: >>> >>> >>> That assertion is obviously false... the plugin can resolve this in >>> various ways, if we allow it. >> >> Handling it by b

[HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

It seems pg_stat_progress_vacuum is not supposed to appear in the table titled "Collected Statistics Views". It was added by c16dc1aca. Attached patch fixes that. Thanks, Amit >From 779fd54f0e30455e0393252a4ba4514d23e0af15 Mon Sep 17 00:00:00 2001 From: amit Date: Tue, 4 Apr 2017 10:16:53 +0900

Re: [HACKERS] show "aggressive" or not in autovacuum logs

Hello, At Fri, 31 Mar 2017 18:20:23 +0900, Masahiko Sawada wrote in > On Wed, Mar 29, 2017 at 12:46 PM, Kyotaro HORIGUCHI > wrote: > > Hello, it would be too late but I'd like to propose this because > > this cannot be back-patched. > > > > > > In autovacuum logs, "%u skipped frozen" shows the

Re: [HACKERS] parallel bitmapscan isn't exercised in regression tests

On Mon, Apr 3, 2017 at 11:22 PM, Andres Freund wrote: > That's better than before, but I'd appreciate working on a bit more > coverage. E.g. rescans probably aren't exercised in that test, right? > > If you have time & energy, it'd also be good to expand the tests to > cover the prefetching logic

Re: [HACKERS] Making clausesel.c Smarter

On Mon, Apr 3, 2017 at 8:52 PM, David Rowley wrote: >> One last observation: >> >> +/* >> + * An IS NOT NULL test is a no-op if there's any other strict quals, >> + * so if that's the case, then we'll only apply this, otherwise >> we'll >> + * ignore it. >> +

Re: [HACKERS] delta relations in AFTER triggers

On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner wrote: > On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane wrote: >> Thomas Munro writes: >>> Or perhaps the code to inject trigger data transition tables into SPI >>> (a near identical code block these three patches) should be somewhere >>> common so that e

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Tue, Apr 4, 2017 at 8:26 AM, Andres Freund wrote: > On 2017-04-04 09:24:23 +1000, Vaishnavi Prabakaran wrote: >> Just quickly, Is it not ok to consider only the code patch for this CF >> without test patch? > > I'd say no, it's not acceptable. This is too much new code for it not > to be teste

Re: [HACKERS] make check-world output

On Mon, Apr 03, 2017 at 03:03:44PM +0900, Michael Paquier wrote: > On Sat, Apr 1, 2017 at 4:28 PM, Noah Misch wrote: > > The pg_upgrade test suite originated in an age when "make check-world" was > > forbidden to depend on Perl; the choice was a shell script or a C program. > > We > > do maintai

Re: [HACKERS] Making clausesel.c Smarter

On 4 April 2017 at 11:35, Claudio Freire wrote: > I'd prefer it if all occurrences of the concept were changed, to > maintain consistency. > That would include variables used to hold expressions that refer to > these as well, as in the case of: > > +Node *var; > + > +

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote: > Not good if it lowers the coverage, but hopefully that's fixable. Have you > analyzed where we're reducing coverage..? The current set of tests is just running pg_upgrade using the same version for the source and target instances. Based on th

Re: [HACKERS] Making clausesel.c Smarter

On Mon, Apr 3, 2017 at 5:59 AM, David Rowley wrote: >> +static void addCachedSelectivityRangeVar(CachedSelectivityClause >> **cslist, Node *var, >> bool varonleft, bool isLTsel, Selectivity s2); >> >> You're changing clause -> var throughout the code when dealing with >> nodes, but

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-04-04 09:24:23 +1000, Vaishnavi Prabakaran wrote: > Hi, > On Tue, Apr 4, 2017 at 7:05 AM, Andres Freund wrote: > > > On 2017-04-03 14:10:47 +1000, Vaishnavi Prabakaran wrote: > > > > The CF has been extended until April 7 but time is still growing short. > > > > Please respond with a new

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Hi, On Tue, Apr 4, 2017 at 7:05 AM, Andres Freund wrote: > On 2017-04-03 14:10:47 +1000, Vaishnavi Prabakaran wrote: > > > The CF has been extended until April 7 but time is still growing short. > > > Please respond with a new patch by 2017-04-04 00:00 AoE (UTC-12) or > this > > > submission will

Re: [HACKERS] Should we cacheline align PGXACT?

pgsql-hackers-ow...@postgresql.org wrote on 04/03/2017 01:58:03 PM: > From: Andres Freund > To: Alexander Korotkov > Cc: David Steele , Ashutosh Sharma > , Simon Riggs , Alvaro > Herrera , Robert Haas > , Bernd Helmle , Tomas > Vondra , pgsql-hackers hack...@postgresql.org> > Date: 04/03/201

Re: [HACKERS] Variable substitution in psql backtick expansion

On Mon, Apr 3, 2017 at 5:12 AM, Daniel Verite wrote: > Queries can be as complex as necessary, they just have to fit in one line. ​Line continuation in general is missed though I thought something already when in for 10.0 that improves upon this...​ > In no way at all,in the sense that, eithe

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael, On Mon, Apr 3, 2017 at 18:29 Michael Paquier wrote: > On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost wrote: > > I'm very curious what you're thinking here? IIRC, Andrew had some ideas > > for how to do true cross-version testing with TAP in the buildfarm, but > > I don't think we actu

Re: [HACKERS] Candidate for local inline function?

On 2017-03-17 15:29:27 -0500, Kevin Grittner wrote: > On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund wrote: > > On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote: > >> Why do we warn of a hazard here instead of eliminating said hazard > >> with a static inline function declaration in executor.h?

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost wrote: > I'm very curious what you're thinking here? IIRC, Andrew had some ideas > for how to do true cross-version testing with TAP in the buildfarm, but > I don't think we actually have that yet..? I heard about nothing in this area. Cross-branch

Re: [HACKERS] Variable substitution in psql backtick expansion

\set d sqrt(1 + random(1000) * 17) \echo :d sqrt(1+random(1000)*17) I assume we want to keep that pre-existing behavior of \set in psql, Ok. So no interpreted expression ever in psql's \set for backward compatibility. that is, making a copy of that string and associating a name to it, whe

Re: [HACKERS] Supporting huge pages on Windows

On 2017-04-03 04:56:45 +, Tsunakawa, Takayuki wrote: > +/* > + * EnableLockPagesPrivilege > + * > + * Try to acquire SeLockMemoryPrivilege so we can use large pages. > + */ > +static bool > +EnableLockPagesPrivilege(int elevel) > +{ > + HANDLE hToken; > + TOKEN_PRIVILEGES tp; > + LU

Re: [HACKERS] Making clausesel.c Smarter

On Mon, Apr 3, 2017 at 6:22 PM, David Rowley wrote: > On 4 April 2017 at 08:24, Andres Freund wrote: >> On 2017-04-03 20:59:42 +1200, David Rowley wrote: >>> Updated patch attached. >>> >>> Thanks for reviewing it. >> >> Given the time in the release cycle I'm afraid that this it's too late >> to

Re: [HACKERS] [PATCH] Incremental sort

On Tue, Apr 4, 2017 at 12:09 AM, Andres Freund wrote: > On 2017-04-04 00:04:09 +0300, Alexander Korotkov wrote: > > > >Thank you! > > > >I already sent version of patch after David's reminder. > > > >Please find rebased patch in the attachment. > > > > > > Cool. I think that's still a bit late fo

Re: [HACKERS] Making clausesel.c Smarter

On 2017-04-04 09:22:07 +1200, David Rowley wrote: > On 4 April 2017 at 08:24, Andres Freund wrote: > > On 2017-04-03 20:59:42 +1200, David Rowley wrote: > >> Updated patch attached. > >> > >> Thanks for reviewing it. > > > > Given the time in the release cycle I'm afraid that this it's too late >

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

On Tue, Apr 4, 2017 at 9:11 AM, Andres Freund wrote: > Hi, > > On 2017-03-31 17:53:12 +1300, Thomas Munro wrote: >> Thanks very much to Rafia for testing, and to Andres for his copious >> review feedback. Here's a new version. Changes: > > I unfortunately think it's too late to get this into v10

Re: [HACKERS] Making clausesel.c Smarter

On 4 April 2017 at 08:24, Andres Freund wrote: > On 2017-04-03 20:59:42 +1200, David Rowley wrote: >> Updated patch attached. >> >> Thanks for reviewing it. > > Given the time in the release cycle I'm afraid that this it's too late > to get this into v10. Does anybody disagree? If not, it should

Re: [HACKERS] PATCH: recursive json_populate_record()

On 2017-03-21 14:31:08 -0400, Andrew Dunstan wrote: > > > On 03/21/2017 01:37 PM, David Steele wrote: > > On 3/16/17 11:54 AM, David Steele wrote: > >> On 2/1/17 12:53 AM, Michael Paquier wrote: > >>> On Thu, Jan 26, 2017 at 6:49 AM, Tom Lane wrote: > Nikita Glukhov writes: > > On 25.01.

Re: [HACKERS] Can't compile with profiling after BRIN autosummarization

Jeff Janes wrote: > A newer gcc gave a better error message which lead me to add the line: > > #include "storage/block.h" /* for typedef BlockNumber */ > > into autovacuum.h, which fixes the problem. Ah, Peter already fixed it. -- Álvaro Herrerahttps://www.2ndQuadrant.

Re: [HACKERS] Can't compile with profiling after BRIN autosummarization

Jeff Janes wrote: > This git bisects down to: > > commit 7526e10224f0792201e99631567bbe44492bbde4 > Author: Alvaro Herrera > Date: Sat Apr 1 14:00:53 2017 -0300 > > BRIN auto-summarization > > The lines are: > > extern void AutoVacuumRequestWork(AutoVacuumWorkItemType type, >

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

Hi, On 2017-03-31 17:53:12 +1300, Thomas Munro wrote: > Thanks very much to Rafia for testing, and to Andres for his copious > review feedback. Here's a new version. Changes: I unfortunately think it's too late to get this into v10. There's still heavy development going on, several pieces chan

Re: [HACKERS] parallel explain analyze support not exercised

On Mon, Apr 3, 2017 at 3:31 PM, Andres Freund wrote: >> If this is 'make check', then we should have 8 parallel workers >> allowed, so if we only do one of these at a time, then I think we're >> OK. But if somebody changes that configuration setting or if it's >> 'make installcheck', then the con

Re: [HACKERS] [PATCH] Incremental sort

Hi, On 2017-04-04 00:04:09 +0300, Alexander Korotkov wrote: > > >Thank you! > > >I already sent version of patch after David's reminder. > > >Please find rebased patch in the attachment. > > > > Cool. I think that's still a bit late for v10? > > > > I don't know. ISTM, that I addressed all the i

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

On Thu, Mar 30, 2017 at 1:14 AM, Ashutosh Bapat wrote: > Done. Ashutosh and I spent several hours discussing this patch set today. I'm starting to become concerned about the fact that 0004 makes the partition bounds part of the PartitionScheme, because that means you can't do a partition-wise joi

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-04-03 14:10:47 +1000, Vaishnavi Prabakaran wrote: > > The CF has been extended until April 7 but time is still growing short. > > Please respond with a new patch by 2017-04-04 00:00 AoE (UTC-12) or this > > submission will be marked "Returned with Feedback". > > > > > Thanks for the informa

Re: [HACKERS] [PATCH] Incremental sort

On Mon, Apr 3, 2017 at 10:05 PM, Andres Freund wrote: > On April 3, 2017 12:03:56 PM PDT, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >On Mon, Apr 3, 2017 at 9:34 PM, Andres Freund > >wrote: > > > >> On 2017-03-29 00:17:02 +0300, Alexander Korotkov wrote: > >> > On Tue, Mar 28, 20

Re: [HACKERS] Variable substitution in psql backtick expansion

> > I assume we want to keep that pre-existing behavior of \set in > psql, that is, making a copy of that string and associating a > name to it, whereas I guess pgbench computes a value from it and > stores that value. > Maybe a \set-variant called \expr?

Re: [HACKERS] SERIALIZABLE with parallel query

On Fri, Mar 10, 2017 at 8:19 PM, Thomas Munro wrote: > On Wed, Feb 22, 2017 at 2:01 PM, Robert Haas wrote: >> I don't think I know enough about the serializable code to review >> this, or at least not quickly, but it seems very cool if it works. >> Have you checked what effect it has on shared me

Re: [HACKERS] identity columns

On 2017-04-03 16:31:27 -0400, Peter Eisentraut wrote: > > Is it guaranteed that the caller expects an int64? I saw that > > nextvalueexpr's have a typeid field. > > It expects one of the integer types. We could cast the result of > Int64GetDatum() to the appropriate type, but that wouldn't actua

Re: [HACKERS] Unable to build doc on latest head

> "Peter" == Peter Eisentraut writes: > On 4/3/17 02:44, Ashutosh Bapat wrote: >> [1] says that id.attribute is supported in stylesheets version >> 1.77.1. Do I need to update stylesheets version? How do I do it? >> Any help will be appreciated. Peter> The oldest version among the ones

Re: [HACKERS] Making clausesel.c Smarter

On Mon, Apr 3, 2017 at 5:24 PM, Andres Freund wrote: > On 2017-04-03 20:59:42 +1200, David Rowley wrote: >> Updated patch attached. >> >> Thanks for reviewing it. > > Given the time in the release cycle I'm afraid that this it's too late > to get this into v10. Does anybody disagree? If not, it

Re: [HACKERS] identity columns

On 4/3/17 14:19, Andres Freund wrote: > Are you going to try to merge this soon, or are you pushing this to 11? I plan to commit it this week. It was basically ready weeks ago, but had to be adjusted after the executor changes. >> +case T_NextValueExpr: >> +{ >> +

Re: [HACKERS] identity columns

On 3/30/17 22:57, Vitaly Burovoy wrote: > Why do you still want to leave "ADD IF NOT EXISTS" instead of using > "SET IF NOT EXISTS"? > If someone wants to follow the standard he can simply not to use "IF > NOT EXISTS" at all. Without it error should be raised. As I tried to mention earlier, it is

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > Now it could be decided that \set in psql stays simplistic because it is > not needed as much as it is with pgbench. Fine with me. It's not just that. It's that currently, if we do in psql: \set d sqrt(1 + random(1000) * 17) then we get that: \echo :d sqrt(1+ran

Re: [HACKERS] SERIALIZABLE with parallel query

On Tue, Apr 4, 2017 at 6:41 AM, Andres Freund wrote: > Hi, > > On 2017-03-11 15:19:23 +1300, Thomas Munro wrote: >> Here is a rebased patch. > > It seems that this patch is still undergoing development, review and > performance evaluation. Therefore it seems like it'd be a bad idea to > try to ge

Re: [HACKERS] Making clausesel.c Smarter

On 2017-04-03 20:59:42 +1200, David Rowley wrote: > Updated patch attached. > > Thanks for reviewing it. Given the time in the release cycle I'm afraid that this it's too late to get this into v10. Does anybody disagree? If not, it should be moved to the next CF. Greetings, Andres Freund --

Re: [HACKERS] Parallel Append implementation

Hi, On 2017-03-24 21:32:57 +0530, Amit Khandekar wrote: > diff --git a/src/backend/executor/nodeAppend.c > b/src/backend/executor/nodeAppend.c > index a107545..e9e8676 100644 > --- a/src/backend/executor/nodeAppend.c > +++ b/src/backend/executor/nodeAppend.c > @@ -59,9 +59,47 @@ > > #include

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 04/03/2017 03:41 PM, Sven R. Kunze wrote: > On 03.04.2017 21:30, Andrew Dunstan wrote: >> On 04/03/2017 02:44 PM, Sven R. Kunze wrote: >>> On 01.04.2017 22:20, Andrew Dunstan wrote: I added documentation when I committed it for the new functions, in the FTS section. I'm not sure

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 03.04.2017 21:30, Andrew Dunstan wrote: On 04/03/2017 02:44 PM, Sven R. Kunze wrote: On 01.04.2017 22:20, Andrew Dunstan wrote: I added documentation when I committed it for the new functions, in the FTS section. I'm not sure what we need to add to the JSON section if anything. Not sure, if

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Hi, In interactive mode, the warning in untaken branches is misleading when \endif is on the same line as the commands that are skipped. For instance: postgres=# \if false \echo NOK \endif \echo command ignored; use \endif or Ctrl-C to exit current \if block postgres=# From the point of

Re: [HACKERS] parallel explain analyze support not exercised

On 2017-04-03 15:13:13 -0400, Robert Haas wrote: > On Mon, Apr 3, 2017 at 1:53 PM, Andres Freund wrote: > >> Please find the attached for the same. > > > >> +-- to increase the parallel query test coverage > >> +EXPLAIN (analyze, timing off, summary off, costs off) SELECT * FROM tenk1; > >> +

Re: [HACKERS] Variable substitution in psql backtick expansion

[...] but OTOH "\if sql 1 from table where expr" looks awkward. Given an implicit select, I would prefer "\if exists (select 1 from table where expr)" but now it's not shorter. Possibly, but it is just an SQL expression, which looks good in the middle of an sql script. An advantage of pr

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 04/03/2017 02:44 PM, Sven R. Kunze wrote: > On 01.04.2017 22:20, Andrew Dunstan wrote: >> I added documentation when I committed it for the new functions, in the >> FTS section. I'm not sure what we need to add to the JSON section if >> anything. > > Not sure, if this is related but the format

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 04/03/2017 02:22 PM, Andres Freund wrote: > On 2017-04-01 16:20:46 -0400, Andrew Dunstan wrote: >> >> On 03/31/2017 03:17 PM, Oleg Bartunov wrote: >>> >>> On 30 Mar 2017 23:43, "Dmitry Dolgov" <9erthali...@gmail.com >>> > wrote: >>> >>> On 31 March 2017 at 00:

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Tom, \if [select current_setting('server_version_num')::int < 11] I really dislike this syntax proposal. It would get us into having to count nested brackets, and distinguish quoted from unquoted brackets, and so on ... and for what? It's not really better than \if sql se

  1   2   >