Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Jim Nasby wrote: > On 2/14/17 3:13 AM, Seki, Eiji wrote: > > +extern TransactionId GetOldestXmin(Relation rel, uint8 > > ignoreFlags); > > My impression is that most other places that do this sort of thing just call > the argument 'flags', so as not to "lock in" a single idea of what the

Re: [HACKERS] Sum aggregate calculation for single precsion real

On 14.02.2017 16:59, Jim Nasby wrote: On 2/13/17 10:45 AM, Konstantin Knizhnik wrote: It is not true - please notice query execution time of this two queries: I bet you'd get even less difference if you simply cast to float8 instead of adding 0.0. Same result, no floating point addition.

Re: [HACKERS] GUC for cleanup indexes threshold.

Hi, I tried regression test and found some errors concerning brin and gin, though I didn't look into this. Here's a log: *** /home/ideriha/postgres-master/src/test/regress/expected/brin.out 2017-02-13 11:33:43.270942937 +0900 ---

Re: [HACKERS] UPDATE of partition key

On 14 February 2017 at 22:24, David Fetter wrote: > On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote: >> Currently, an update of a partition key of a partition is not >> allowed, since it requires to move the row(s) into the applicable >> partition. >> >> Attached

Re: [HACKERS] Parallel Append implementation

On 14 February 2017 at 22:35, Robert Haas wrote: > On Mon, Feb 6, 2017 at 12:36 AM, Amit Khandekar > wrote: >>> Now that I think of that, I think for implementing above, we need to >>> keep track of per-subplan max_workers in the Append path; and

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Feb 10, 2017 at 3:19 PM, Amit Langote wrote: > The new partitioned tables do not contain any data by themselves. Any > data inserted into a partitioned table is routed to and stored in one of > its partitions. In fact, it is impossible to insert *any* data

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Amit Kapila wrote: > How will you decide just based on oldest xmin whether the tuple is visible or > not? How will you take decisions about tuples which have xmax set? In our use case, GetOldestXmin is used by an original maintainer process[es] to an original control table[s]. The table can be

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote: > I think the patch as presented probably isn't quite what we want, > because it waits synchronously for the second result to be ready. > Note that the wait for the first result is asynchronous: we check > PQisBusy and

Re: [HACKERS] parallelize queries containing subplans

On Wed, Feb 15, 2017 at 4:38 AM, Robert Haas wrote: > On Tue, Feb 14, 2017 at 4:24 AM, Amit Kapila wrote: >> On further evaluation, it seems this patch has one big problem which >> is that it will allow forming parallel plans which can't be

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On Tue, Feb 14, 2017 at 09:24:47PM -0800, Joshua Chamberlain wrote: > Hello, > > (I'm posting to hackers since I got no response on the general > list.) > > I use Postgres + PostGIS quite heavily, and recently have been > taking full advantage of the new parallelism in 9.6. I'm now running >

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote: > On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada > wrote: >> On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek >> wrote: >>> On 10/02/17 19:55, Masahiko Sawada wrote:

Re: [HACKERS] bytea_output vs make installcheck

Andres Freund writes: > I don't quite see the point of this - there's a lot of settings that cause > spurious test failures. I don't see any point fixing random cases of that. > And I don't think the continual cost of doing so overall is worth the minimal > gain. > What's

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On Wed, Feb 15, 2017 at 2:24 PM, Joshua Chamberlain wrote: > Are there plans in 10.0 to allow parallelism in queries that write, or at > least in "CREATE TABLE AS" queries? (Support in materialized views would be > great, too!) Nope. There are no patches for now. -- Michael

[HACKERS] CREATE TABLE with parallel workers, 10.0?

Hello, (I'm posting to hackers since I got no response on the general list.) I use Postgres + PostGIS quite heavily, and recently have been taking full advantage of the new parallelism in 9.6. I'm now running queries in a few hours that would otherwise take more than a day. However, parallelism

Re: [HACKERS] bytea_output vs make installcheck

On February 14, 2017 9:02:14 PM PST, neha khatri wrote: >On Wed, Feb 15, 2017 at 10:04 AM, neha khatri > wrote:. >> >> >>> Attached are two options for doing that. One overrides bytea_output >>> locally where-ever needed, and the other overrides

Re: [HACKERS] bytea_output vs make installcheck

On Wed, Feb 15, 2017 at 10:04 AM, neha khatri wrote:. > > >> Attached are two options for doing that. One overrides bytea_output >> locally where-ever needed, and the other overrides it for the entire >> 'regression' database. >> > > The solution that overrides

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Wed, Feb 15, 2017 at 3:18 AM, Jim Nasby wrote: > Why not do what we do for pg_stat_activity.current_query and leave it NULL > for non-SU? If subcriptions are designed to be superuser-only, it seems fair to me to do so. Some other system SRFs do that already. > Even

Re: [HACKERS] operator_precedence_warning vs make installcheck

Jeff Janes writes: > make installcheck fails against a server running with > operator_precedence_warning = on. > The difference is in update.out, and consists of an error-locating carat > getting moved over by one position. I've attached the regression diff. > I don't

Re: [HACKERS] Sum aggregate calculation for single precsion real

Robert Haas writes: > Well put. Although it's worth noting that we aren't 100% consistent > about this stuff: sum(smallint), sum(integer), and sum(bigint) all use > an output data type different from the input data type, but other > versions of sum() don't. In those cases

Re: [HACKERS] parallelize queries containing subplans

On Wed, Feb 15, 2017 at 4:46 AM, Robert Haas wrote: > On Mon, Feb 13, 2017 at 11:07 PM, Amit Kapila wrote: >> I have removed the check of AlternativeSubPlan so that it can be >> handled by expression_tree_walker. > ... >> Attached patch fixes all

Re: [HACKERS] pg_basebackup -R

On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier > wrote: >> In short, I'd like to think that we should just filter out those two >> parameters by name and call it a day. Or introduce an idea

Re: [HACKERS] Documentation improvements for partitioning

On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote wrote: > On 2017/02/13 14:21, Amit Langote wrote: >> On 2017/02/10 19:19, Simon Riggs wrote: >>> * The OID inheritance needs work - you shouldn't need to specify a >>> partition needs OIDS if the parent has it already.

Re: [HACKERS] pg_stat_wal_write statistics view

On Wed, Feb 8, 2017 at 9:36 PM, Amit Kapila wrote: > On Tue, Feb 7, 2017 at 11:47 AM, Haribabu Kommi > wrote: > > Hi Hackers, > > > > I just want to discuss adding of a new statistics view that provides > > the information of wal writing

Re: [HACKERS] Documentation improvements for partitioning

On Fri, Feb 10, 2017 at 3:00 AM, Simon Riggs wrote: > Given that we already have partitioning feature committed, we really > need to have the docs committed as well. Just for the record, it's not like there were no documentation changes in the originally committed patch.

Re: [HACKERS] Sum aggregate calculation for single precsion real

On Tue, Feb 14, 2017 at 8:59 AM, Jim Nasby wrote: >> From my point of your it is strange and wrong expectation. >> I am choosing "float4" type for a column just because it is enough to >> represent range of data I have and I need to minimize size of record. > > In other

[HACKERS] operator_precedence_warning vs make installcheck

make installcheck fails against a server running with operator_precedence_warning = on. The difference is in update.out, and consists of an error-locating carat getting moved over by one position. I've attached the regression diff. I don't know why the setting of this GUC causes the carat to

Re: [HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins

On Wed, Feb 15, 2017 at 2:22 PM, Tom Lane wrote: > Adding a C.F.I. inside this loop is the most straightforward fix, but > I am leaning towards adding one in ExecHashJoinGetSavedTuple instead, > because that would also ensure that all successful paths through >

Re: [HACKERS] WAL consistency check facility

On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote: > On Tue, Feb 14, 2017 at 7:12 PM, Tom Lane wrote: >> FWIW, my own habit when creating new PG files is generally to write >> >> * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group

Re: [HACKERS] WAL consistency check facility

On Tue, Feb 14, 2017 at 7:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier >> wrote: >>> Just for curiosity: does the moment when the code has been written or >>> committed

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Tue, Feb 14, 2017 at 12:11 AM, Michael Paquier wrote: > On Thu, Feb 2, 2017 at 3:01 PM, Higuchi, Daisuke > wrote: >> From: Michael Paquier [mailto:michael.paqu...@gmail.com] >>>This has not been added yet to the next CF. As Ashutosh

[HACKERS] Missing CHECK_FOR_INTERRUPTS in hash joins

I ran into a case where a hash join took a really long time to respond to a cancel request --- long enough that I gave up and kill -9'd it, because its memory usage was also growing to the point where the kernel would likely soon choose to do that for me. The culprit seems to be that there's no

Re: [HACKERS] WAL consistency check facility

Robert Haas writes: > On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier > wrote: >> Just for curiosity: does the moment when the code has been written or >> committed counts? It's no big deal seeing how liberal the Postgres >> license is, but this

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Wed, Feb 15, 2017 at 2:08 AM, Robert Haas wrote: > On Mon, Feb 13, 2017 at 5:00 PM, Michael Paquier > wrote: >> It seems like the previous review I provided for the set of renaming >> patches has been ignored: >>

Re: [HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN

On Mon, Feb 13, 2017 at 10:34 PM, Tom Lane wrote: > Jim Nasby writes: >> Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to >> be able to do something like WHEN tag LIKE 'ALTER%'. > > Seems like it would be a seriously bad idea

[HACKERS] new high availability feature for the system with both asynchronous and synchronous replication

Hi all, I propose a new feature for high availability. This configuration is effective for following configuration: 1. Primary and synchronous standby are in the same center; called main center. 2. Asynchronous standby is in the another center; called backup center. (The backup center is

Re: [HACKERS] WAL consistency check facility

On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 2:43 AM, Robert Haas wrote: >> On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier >> wrote: >>> Please find attached a patch with those

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera wrote: > I'd rather have a --quiet mode instead. If you're running it by hand, > you're likely to omit the switch, whereas when writing the cron job > you're going to notice lack of switch even before you let the job run >

Re: [HACKERS] parallelize queries containing subplans

On Mon, Feb 13, 2017 at 11:07 PM, Amit Kapila wrote: > I have removed the check of AlternativeSubPlan so that it can be > handled by expression_tree_walker. ... > Attached patch fixes all the comments raised till now. Committed after removing the reference to

Re: [HACKERS] Skipping PgStat_FunctionCallUsage for many expressions

On 2017-02-14 17:58:23 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-11-26 08:41:28 -0800, Andres Freund wrote: > >> On November 26, 2016 8:06:26 AM PST, Tom Lane wrote: > >>> Those don't call functions, they call operators. Yes, I know that

Re: [HACKERS] parallelize queries containing subplans

On Tue, Feb 14, 2017 at 4:24 AM, Amit Kapila wrote: > On further evaluation, it seems this patch has one big problem which > is that it will allow forming parallel plans which can't be supported > with current infrastructure. For ex. marking immediate level params > as

Re: [HACKERS] bytea_output vs make installcheck

On Wed, Feb 15, 2017 at 8:50 AM, 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

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

Hello Tom, So moving the conditional stack back into PsqlScanState has some side effects: conditional.[ch] have to move to the fe_utils/ dirs, and now pgbench, which does not use conditionals, would have to link to them. Is that a small price to pay for modularity and easier-to-find code? Or

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

On Tue, Feb 14, 2017 at 4:44 PM, Tom Lane wrote: > Corey Huinker writes: > > So moving the conditional stack back into PsqlScanState has some side > > effects: conditional.[ch] have to move to the fe_utils/ dirs, and now > > pgbench, which does not

Re: [HACKERS] Skipping PgStat_FunctionCallUsage for many expressions

Andres Freund writes: > On 2016-11-26 08:41:28 -0800, Andres Freund wrote: >> On November 26, 2016 8:06:26 AM PST, Tom Lane wrote: >>> Those don't call functions, they call operators. Yes, I know that an >>> operator has a function underlying it, but the

Re: [HACKERS] Skipping PgStat_FunctionCallUsage for many expressions

On 2016-11-26 08:41:28 -0800, Andres Freund wrote: > On November 26, 2016 8:06:26 AM PST, Tom Lane wrote: > >Robert Haas writes: > >> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund > >wrote: > >>> while working on my faster

Re: [HACKERS] WAL consistency check facility

On Wed, Feb 15, 2017 at 2:43 AM, Robert Haas wrote: > On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier > wrote: >> Please find attached a patch with those fixes. > > Committed, but I changed the copyright dates to 2016-2017 rather than > just 2017

Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.

On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes wrote: > I thought people would object to checking the version number in two > different places to make the same fundamental decision, and would want that > refactored somehow. But if you are OK with it, then I am. The binary

Re: [HACKERS] Set of fixes for WAL consistency check facility

On Wed, Feb 15, 2017 at 2:44 AM, Robert Haas wrote: > I committed the patch posted to the other thread. Hopefully that > closes this issue. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] bytea_output vs make installcheck

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, and the other overrides it for the entire

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

Corey Huinker writes: > So moving the conditional stack back into PsqlScanState has some side > effects: conditional.[ch] have to move to the fe_utils/ dirs, and now > pgbench, which does not use conditionals, would have to link to them. Is > that a small price to pay for

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

Robert Haas wrote: > On Tue, Feb 14, 2017 at 12:06 PM, Magnus Hagander wrote: > > However, outputing this info by default will make it show up in things like > > everybodys cronjobs by default. Right now a successful pg_basebackup run > > will come out with no output at all,

Re: [HACKERS] Improve OR conditions on joined columns (common star schema problem)

Jim Nasby writes: > On 2/14/17 1:18 PM, Tom Lane wrote: >> One point that could use further review is whether the de-duplication >> algorithm is actually correct. I'm only about 95% convinced by the >> argument I wrote in planunionor.c's header comment. > I'll put some

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

Robert Haas wrote: > On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote: > >> Thoughts, comments, objections, better ideas? > > > > No better ideas. I'm a bit concerned about declarations needed both by > > normal and xlog related routines, but I guess that can be solved by

Re: [HACKERS] possibility to specify template database for pg_regress

Dne 14. 2. 2017 21:35 napsal uživatel "Andres Freund" : On 2017-02-14 14:29:56 -0600, Jim Nasby wrote: > On 2/14/17 1:59 PM, Andres Freund wrote: > > > AFAIK if you're doing make check (as opposed to installcheck) it's > > > significantly more complicated than that since you'd

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote: >> Thoughts, comments, objections, better ideas? > > No better ideas. I'm a bit concerned about declarations needed both by > normal and xlog related routines, but I guess that can be solved by a > third header as you did.

Re: [HACKERS] Improve OR conditions on joined columns (common star schema problem)

On 2/14/17 1:18 PM, Tom Lane wrote: I think this might be code-complete, modulo the question of whether we want an enabling GUC for it. I'm still concerned about the question of whether it adds more planning time than it's worth for most users. (Obviously it needs some regression test cases

Re: [HACKERS] Small improvement to parallel query docs

On 15 February 2017 at 03:41, Robert Haas wrote: > On Tue, Feb 14, 2017 at 5:17 AM, David Rowley > wrote: >> Updated patch attached. > > Committed and back-patched to 9.6. Great. Thanks Robert. -- David Rowley

Re: [HACKERS] Official adoption of PGXN

On 2017-02-14 12:19:56 -0800, Josh Berkus wrote: > On 02/14/2017 12:05 PM, Tom Lane wrote: > > Jim Nasby writes: > >> First, just to clarify: my reasons for proposing "core adoption" of PGXN > >> are not technical in nature. > > > > What do you think "core adoption"

Re: [HACKERS] possibility to specify template database for pg_regress

On 2017-02-14 14:29:56 -0600, Jim Nasby wrote: > On 2/14/17 1:59 PM, Andres Freund wrote: > > > AFAIK if you're doing make check (as opposed to installcheck) it's > > > significantly more complicated than that since you'd have to create a temp > > > cluster/install yourself. > > > > But in that

Re: [HACKERS] Official adoption of PGXN

On 2/14/17 2:19 PM, Josh Berkus wrote: One part of this would need to be having a designated committee of the Postgres community pick a set of "blessed" extensions for packagers to package. Right now, contrib serves that purpose (badly). One of the reasons we haven't dealt with the extension

Re: [HACKERS] Parallel Index Scans

On Tue, Feb 14, 2017 at 12:48 PM, Robert Haas wrote: > That sounds way better. Here's an updated patch. Please review my changes, which include: * Various comment updates. * _bt_parallel_seize now unconditionally sets *pageno to P_NONE at the beginning, instead of doing

Re: [HACKERS] possibility to specify template database for pg_regress

On 2/14/17 1:59 PM, Andres Freund wrote: AFAIK if you're doing make check (as opposed to installcheck) it's significantly more complicated than that since you'd have to create a temp cluster/install yourself. > But in that case you can't have useful templates in the regression test either, so

Re: [HACKERS] Official adoption of PGXN

On 02/14/2017 12:05 PM, Tom Lane wrote: > Jim Nasby writes: >> First, just to clarify: my reasons for proposing "core adoption" of PGXN >> are not technical in nature. > > What do you think "core adoption" means? Surely not that anything > associated with PGXN would

Re: [HACKERS] Official adoption of PGXN

On 2/14/17 2:05 PM, Tom Lane wrote: Jim Nasby writes: First, just to clarify: my reasons for proposing "core adoption" of PGXN are not technical in nature. What do you think "core adoption" means? Surely not that anything associated with PGXN would be in the core

Re: [HACKERS] Official adoption of PGXN (was: removing tsearch2)

Jim Nasby writes: > First, just to clarify: my reasons for proposing "core adoption" of PGXN > are not technical in nature. What do you think "core adoption" means? Surely not that anything associated with PGXN would be in the core distro. > Right now contrib is

Re: [HACKERS] possibility to specify template database for pg_regress

On 2017-02-14 12:33:35 -0600, Jim Nasby wrote: > On 2/13/17 8:50 PM, Andres Freund wrote: > > On 2017-02-14 11:46:52 +0900, Michael Paquier wrote: > > > > I still fail to see why --use-existing as suggested in > > > >

Re: [HACKERS] pg_waldump's inclusion of backend headers is a mess

Hi, On 2017-02-13 22:42:00 -0500, Robert Haas wrote: > I dug into the problem and discovered that pg_waldump is slurping up a > tremendous crapload of backend headers. It includes gin.h, > gist_private.h, hash_xlog.h, nbtree.h, and spgist.h, which all end up > including amapi.h, which includes

[HACKERS] Official adoption of PGXN (was: removing tsearch2)

First, just to clarify: my reasons for proposing "core adoption" of PGXN are not technical in nature. My desire is to have an extension/add-on system that's officially endorsed and embraced by the official community, similar to CPAN, pypy, npm, etc. There's no technical reason we need PGXN to

Re: [HACKERS] Improve OR conditions on joined columns (common star schema problem)

I wrote: > The main remaining piece of work here is that, as you can see from the > above, it fails to eliminate joins to tables that we don't actually need > in a particular UNION arm. This is because the references to those > tables' ctid columns prevent analyzejoins.c from removing the joins.

Re: [HACKERS] PATCH: two slab-like memory allocators

On 02/14/2017 03:22 AM, Andres Freund wrote: Hi, On 2017-02-11 14:40:18 +0100, Tomas Vondra wrote: On 02/11/2017 02:33 AM, Andres Freund wrote: I have a hard time believing this the cache efficiency of linked lists (which may or may not be real in this case) out-weights this, but if you want

Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.

On Mon, Feb 13, 2017 at 6:19 PM, Michael Paquier wrote: > On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes wrote: > > check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or > > directory > > > > This looks somewhat complicated to fix.

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Tue, Feb 14, 2017 at 12:06 PM, Magnus Hagander wrote: > However, outputing this info by default will make it show up in things like > everybodys cronjobs by default. Right now a successful pg_basebackup run > will come out with no output at all, which is how most Unix

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On 2/14/17 3:13 AM, Seki, Eiji wrote: +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags); My impression is that most other places that do this sort of thing just call the argument 'flags', so as not to "lock in" a single idea of what the flags are for. I can't readily

Re: [HACKERS] possibility to specify template database for pg_regress

On 2/13/17 8:50 PM, Andres Freund wrote: On 2017-02-14 11:46:52 +0900, Michael Paquier wrote: I still fail to see why --use-existing as suggested in https://www.postgresql.org/message-id/20170208002900.vkldujzfkwbvq...@alap3.anarazel.de isn't sufficient. Some tests create objects without

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

On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote: > What would be the mnemonic for "," an "@"? Oh, I just picked it because control-@ is the nul character, and your commands would be nullified. I realize that's pretty weak, but we're talking about finding a punctuation

Re: [HACKERS] log_autovacuum_min_duration doesn't log VACUUMs

On 2/13/17 11:12 AM, Robert Haas wrote: FWIW, this is a significant problem outside of DDL. Once you're past 1-2 levels of nesting SET client_min_messages = DEBUG becomes completely useless. I think the ability to filter logging based on context would be very valuable. AFAIK you could actually

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 2/13/17 9:36 PM, Michael Paquier wrote: Probably I failed to get Peter's point... Anyway IMO that we can expose all the columns except the sensitive information (i.e., subconninfo field) in pg_subscription to even non-superusers. Then we can use pg_subscription for the tab-completion for

[HACKERS] Add checklist item for psql completion to commitfest review

After seeing Yet Another Missing Psql Tab Completion it occurred to me... why not add a checklist item to the commitfest review page? I realize most regular contributors don't use the form, but a fair number of people do. I don't see how it could hurt. Another possible idea is a git hook that

Re: [HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN

On 2/13/17 9:34 PM, Tom Lane wrote: Jim Nasby writes: Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to be able to do something like WHEN tag LIKE 'ALTER%'. Seems like it would be a seriously bad idea for such an expression to be able to invoke

Re: [HACKERS] removing tsearch2

On Feb 14, 2017, at 9:37 AM, Magnus Hagander wrote: > It's a failing in one of the two at least. It either needs to be easier to > build the things on windows, or pgxn would need to learn to do binary > distributions. PGXN makes no effort to support installation on any

Re: [HACKERS] Parallel Index Scans

On Mon, Feb 13, 2017 at 9:04 PM, Amit Kapila wrote: > I think the comment at that place is not as clear as it should be. So > how about changing it as below: > > Existing comment: > -- > /* > * For parallel scans, get the last page scanned as it

Re: [HACKERS] Set of fixes for WAL consistency check facility

On Mon, Feb 13, 2017 at 8:00 PM, Michael Paquier wrote: > Beginning a new thread to raise awareness... As already reported here, > I had a look at what has been committed in a507b869: >

Re: [HACKERS] WAL consistency check facility

On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier wrote: > Please find attached a patch with those fixes. Committed, but I changed the copyright dates to 2016-2017 rather than just 2017 since surely some of the code was originally written before 2017. Even that might

Re: [HACKERS] Declarative partitioning - another take

On Fri, Feb 10, 2017 at 12:54 AM, Amit Langote wrote: > On 2017/02/09 15:22, amul sul wrote: >> About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch, >> following test is already covered in alter_table.sql @ Line # 1918, >> instead of this kindly add test

Re: [HACKERS] pg_basebackup -R

On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier wrote: > On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila wrote: >> +1. Sounds sensible thing to do. > > Hm. It seems to me that PGPASSFILE still needs to be treated as an > exception because it is

Re: [HACKERS] removing tsearch2

On Feb 14, 2017 18:26, "David E. Wheeler" wrote: On Feb 14, 2017, at 5:37 AM, Jim Nasby wrote: >> Until pgxn has a way of helping users on for example Windows (or other >> platforms where they don't have a pgxs system and a compiler around), >>

Re: [HACKERS] AT detach partition is broken

On Mon, Feb 13, 2017 at 2:30 AM, Amit Langote wrote: > I noticed that running ALTER TABLE table_name DETACH PARTITION crashes, if > table_name is not a partitioned table. That's because of an Assert in > ATExecDetachPartition(). We really should error out much

Re: [HACKERS] [PROPOSAL] timestamp informations to pg_stat_statements

On Sun, Jul 17, 2016 at 7:15 PM, Tom Lane wrote: > Peter Geoghegan writes: >> On Sun, Jul 17, 2016 at 12:22 AM, Jun Cheol Gim wrote: >>> If we have timestamp of first and last executed, we can easily gather thess >>> informations and

Re: [HACKERS] removing tsearch2

On Feb 14, 2017, at 5:37 AM, Jim Nasby wrote: >> Until pgxn has a way of helping users on for example Windows (or other >> platforms where they don't have a pgxs system and a compiler around), >> it's always going to be a "second class citizen". > > I view that as more

Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow

On Mon, Feb 13, 2017 at 11:38 PM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > > On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera > > wrote: > > > Well, we can remove them from PG10 and pgAdmin3 (and others) be > adjusted >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove all references to "xlog" from SQL-callable functions in p

On Mon, Feb 13, 2017 at 5:00 PM, Michael Paquier wrote: > It seems like the previous review I provided for the set of renaming > patches has been ignored: > https://www.postgresql.org/message-id/CAB7nPqSm=PNSe3EfvnEResdFzpQMcXXgapFBcF=EFdxVW4=f...@mail.gmail.com > Good

Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

On Mon, Feb 13, 2017 at 10:33 AM, Michael Banck wrote: > Hi, > > Am Montag, den 13.02.2017, 09:31 +0100 schrieb Magnus Hagander: > > On Mon, Feb 13, 2017 at 3:29 AM, Jim Nasby > > wrote: > > On 2/11/17 4:36 AM, Michael Banck wrote: >

Re: [HACKERS] Parallel Append implementation

On Tue, Feb 14, 2017 at 12:05 PM, Robert Haas wrote: > Having the extra > 1-2 workers exist does not seem better. Err, exit, not exist. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Parallel Append implementation

On Mon, Feb 6, 2017 at 12:36 AM, Amit Khandekar wrote: >> Now that I think of that, I think for implementing above, we need to >> keep track of per-subplan max_workers in the Append path; and with >> that, the bitmap will be redundant. Instead, it can be replaced with >>

Re: [HACKERS] UPDATE of partition key

On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote: > Currently, an update of a partition key of a partition is not > allowed, since it requires to move the row(s) into the applicable > partition. > > Attached is a WIP patch (update-partition-key.patch) that removes > this

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On Fri, Feb 10, 2017 at 10:36 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/31/16 11:43 AM, Tom Lane wrote: > > Magnus Hagander writes: > >> I still think that some wording in the direction of the fact that the > >> majority of all users won't

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 14, 2017 at 12:18 AM, Dilip Kumar wrote: > Fixed. Thanks, the external interface to this looks much cleaner now. Scrutinizing the internals: What is the point of having a TBMSharedIterator contain a TIDBitmap pointer? All the values in that TIDBitmap are

Re: [HACKERS] UPDATE of partition key

On Mon, Feb 13, 2017 at 7:01 AM, Amit Khandekar wrote: > partspartitioned inheritance no. of rows subpartitions > ==== === === = > > 500 10 sec 3 min 02 sec 1,000,000 0 > 1000 10 sec 3

Re: [HACKERS] Small improvement to parallel query docs

On Tue, Feb 14, 2017 at 5:17 AM, David Rowley wrote: > On 14 February 2017 at 21:25, Amit Kapila wrote: >> +Aggregate stage. For such cases there is clearly going to be no >> +performance benefit to using parallel aggregation. >> >>

Re: [HACKERS] removing tsearch2

On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby wrote: > Right; I think we need at least some amount of pgxn buildfarm coverage. > There probably also needs to be a way to officially bless certain > distributions. Unless there's a pretty significant need for an official >

  1   2   >