Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Tuesday, October 20, 2015 1:11 PM > To: Robert Haas > Cc: Tom Lane; Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI; > pgsql-hackers@postgresql.org; Shigeru Hanada > Subject: Re: [HACKERS] Foreign join pushdown

Re: [HACKERS] checkpointer continuous flushing

On Mon, Oct 19, 2015 at 4:06 AM, Andres Freund wrote: > > > I wonder if mmap() && msync(MS_ASYNC) isn't a better replacement for > sync_file_range(SYNC_FILE_RANGE_WRITE) than posix_fadvise(DONTNEED). It > might even be possible to later approximate that on windows using >

Re: [HACKERS] Checkpoint throttling issues

On Tue, Oct 20, 2015 at 1:05 AM, Alvaro Herrera wrote: > > Fabien COELHO wrote: > > > >4) It's a bit dubious to only pgstat_send_bgwriter() when on schedule. > > > > No opinion! > > My guess here, without looking, is that this was based on the idea of > "oops, we're late

Re: [HACKERS] SuperUser check in pg_stat_statements

You can create a Security Definer Funtion which can then be executed by then non-superuser monitoring role: (Assuming you have a role monitoring and pg_stat_statements is installed in schema public) -- connected as a superuser CREATE FUNCTION pg_stat_statements() RETURNS SETOF

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, >I think that you should add the flag or something which indicates whether this >backend is running VACUUM or not, into PgBackendStatus. >pg_stat_vacuum_progress should display the entries of only backends with that >flag set true. This design means that you need to set the flag to true

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita wrote: As Tom mentioned, just recomputing the original join tuple is not good enough. We would need to rejoin the test tuples for the baserels even if ROW_MARK_COPY is in use. Consider: A=# BEGIN; A=# UPDATE t SET a

Re: [HACKERS] Multi-column distinctness.

On 19 October 2015 at 20:16, Tomas Vondra wrote: > Hello Kyotaro-san, > > On 09/11/2015 06:58 PM, Tomas Vondra wrote: > > > >> Maybe the best solution is to abandon the ALTER TABLE approach >> entirely, and instead invent a new set of commands >> >>CREATE

[HACKERS] Duplicated assignment of slot_name in walsender.c

walsender.c, CreateReplicationSlot() currently has this: slot_name = NameStr(MyReplicationSlot->data.name); if (cmd->kind == REPLICATION_KIND_LOGICAL) { [...] } else if (cmd->kind == REPLICATION_KIND_PHYSICAL && cmd->reserve_wal) {

Re: [HACKERS] Parallel Aggregate

On 13 October 2015 at 20:57, Haribabu Kommi wrote: > On Tue, Oct 13, 2015 at 5:53 PM, David Rowley > wrote: > > On 13 October 2015 at 17:09, Haribabu Kommi > > wrote: > >> > >> On Tue, Oct 13, 2015 at 12:14 PM,

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Oct 19, 2015 at 8:47 PM, Masahiko Sawada wrote: > > Hi, > > Attached patch is a rough patch which supports multi sync replication > by another approach I sent before. > > The new GUC parameters are: > * synchronous_standby_num, which specifies the number of standby

Re: [HACKERS] PoC: Partial sort

On Fri, Oct 16, 2015 at 7:11 PM, Alexander Korotkov wrote: > On Sun, Jun 7, 2015 at 11:01 PM, Peter Geoghegan wrote: > >> On Sun, Jun 7, 2015 at 8:10 AM, Andreas Karlsson >> wrote: >> > Are you planning to work on this patch for 9.6? >>

[HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

Hi. Introduction PostgreSQL full-text search extension uses dictionaries from the various open source spell checker software to perform word normalization. Currently, Ispell, MySpell and Hunspell dictionaries are supported. Dictionaries requires two files: a dictionary file and

Re: [HACKERS] COPY FREEZE and PD_ALL_VISIBLE

On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes wrote: > I'm planning on adding a todo item to have COPY FREEZE set PD_ALL_VISIBLE. > Or is there some reason this can't be done? > > Since the whole point of COPY FREEZE is to avoid needing to rewrite the > entire table, it seems

Re: [HACKERS] Allow ssl_renegotiation_limit in PG 9.5

On Sun, Oct 18, 2015 at 4:56 PM, Shay Rojansky wrote: > Here's a patch that adds back the GUC, with default/min/max 0 and > GUC_NO_SHOW_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE. > > This is my first pg patch, please be gentle with any screwups :) Why, you dummy. No,

Re: [HACKERS] SuperUser check in pg_stat_statements

Hey Lukas, Thanks. Able to see the queries from all users. Can you explain the monitoring.get_stat_statements()? -- View this message in context: http://postgresql.nabble.com/SuperUser-check-in-pg-stat-statements-tp5870589p5870733.html Sent from the PostgreSQL - hackers mailing list archive

[HACKERS] Typos in plannodes.h

Hi, I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please find attached a patch. Best regards, Etsuro Fujita diff --git a/src/include/nodes/plannodes.h b/src/include/nodes/plannodes.h index 92fd8e4..6b28c8e 100644 --- a/src/include/nodes/plannodes.h +++

Re: [HACKERS] [RFC] overflow checks optimized away

On Fri, Oct 16, 2015 at 11:29 PM, Michael Paquier wrote: > Well, I have played a bit with this patch and rebased it as attached. > One major change is the use of the variables PG_INT* that have been > added in 62e2a8d. Some places were not updated with those new checks, > in majority a couple of

Re: [HACKERS] Parallel Seq Scan

On Fri, Oct 16, 2015 at 9:51 AM, Robert Haas wrote: > > On Mon, Oct 5, 2015 at 8:20 AM, Amit Kapila wrote: > > [ new patch for heapam.c changes ] > > There's a second patch attached here as well, parallel-relaunch.patch, > which makes it possible

Re: [HACKERS] Minor comment fix

On Mon, Oct 19, 2015 at 12:25 AM, Amit Langote wrote: > Attached fixes the following in comment above ExecCheckIndexConstraints: > > s/no no conflict/no conflict/g Thanks, committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

[HACKERS] Documentation for min_wal_size and max_wal_size

Wouldn't it be better to have these two parameters documented next to each other, as in the attached patch? Yours, Laurenz Albe 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch Description: 0001-Move-documentation-for-min_wal_size-before-max_wal_s.patch -- Sent via

Re: [HACKERS] checkpointer continuous flushing

On 2015-10-19 21:14:55 +0200, Fabien COELHO wrote: > >In my performance testing it showed that calling PerformFileFlush() only > >at segment boundaries and in CheckpointWriteDelay() can lead to rather > >spikey IO - not that surprisingly. The sync in CheckpointWriteDelay() is > >problematic

Re: [HACKERS] tab completion for extension versions

On Sun, Oct 18, 2015 at 6:59 PM, Jeff Janes wrote: > This patch adds "VERSION" to the list of words completed after "create > extension foo", and adds the list of available versions of foo after "create > extension foo version". > > There is no point in filtering out the

Re: [HACKERS] a raft of parallelism-related bug fixes

On Sat, Oct 17, 2015 at 6:17 PM, Robert Haas wrote: > It's good to have your perspective on how this can be improved, and > I'm definitely willing to write more documentation. Any lack in that > area is probably due to being too close to the subject area, having > spent

Re: [HACKERS] [PATCH] SQL function to report log message

On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule wrote: > 2015-10-20 17:15 GMT+02:00 Robert Haas : >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule >> wrote: >> > Probably it was my request. I don't like to using NULL as

Re: [HACKERS] Multi-column distinctness.

On 10/20/2015 05:59 PM, Tom Lane wrote: Robert Haas writes: On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra wrote: ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and use REMOVE STATISTICS instead of DROP STATISTICS.

Re: [HACKERS] pgbench throttling latency limit

On 2014-08-14 15:01:53 +0200, Fabien COELHO wrote: > > Add --limit to limit latency under throttling > > Under throttling, transactions are scheduled for execution at certain times. > Transactions may be far behind schedule and the system may catch up with the > load later. This option allows to

Re: [HACKERS] Declarative partitioning

On 20 October 2015 at 18:34, Amit Langote wrote: > > > On Wednesday, 21 October 2015, Thom Brown wrote: >> >> On 18 August 2015 at 12:23, Amit Langote wrote: >> > Hi Thom, >> > >> > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown

Re: [HACKERS] Documentation for min_wal_size and max_wal_size

On 10/20/15 10:27 AM, Albe Laurenz wrote: > Wouldn't it be better to have these two parameters documented next to each > other, > as in the attached patch? I was also about to fix that. I did it slightly differently, to restore the original alphabetical ordering. -- Sent via pgsql-hackers

Re: [HACKERS] pgbench throttling latency limit

On 2015-10-20 20:55:46 +0200, Andres Freund wrote: > On 2014-08-14 15:01:53 +0200, Fabien COELHO wrote: > > > > Add --limit to limit latency under throttling > > > > Under throttling, transactions are scheduled for execution at certain times. > > Transactions may be far behind schedule and the

Re: [HACKERS] Declarative partitioning

On 18 August 2015 at 12:23, Amit Langote wrote: > Hi Thom, > > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown wrote: >> >> >> Wow, didn't expect to see that email this morning. >> >> A very quick test: >> >> CREATE TABLE purchases (purchase_id serial,

Re: [HACKERS] Declarative partitioning

On Wednesday, 21 October 2015, Thom Brown wrote: > On 18 August 2015 at 12:23, Amit Langote > wrote: > > Hi Thom, > > > > On Tue, Aug 18, 2015 at 8:02 PM, Thom Brown > wrote: > >> > >> > >> Wow, didn't

Re: [HACKERS] bugs and bug tracking

On 10/13/2015 11:41 AM, Bruce Momjian wrote: FYI, I think we already have two limits for the first line summary of commit messages. The limits are 64 for commit message subjects and 50 characters for gitweb summary pages --- anything longer is truncated. My commit template shows me the limits

Re: [HACKERS] Multi-column distinctness.

Tomas Vondra writes: > On 10/20/2015 05:59 PM, Tom Lane wrote: >> Why is this an improvement over using already-existing keywords? > The problem is that the actual syntax is ADD [COLUMN], so we can't > simply use ADD STATISTICS as that would mean a conflict in the

Re: [HACKERS] [DOCS] max_worker_processes on the standby

Robert Haas wrote: > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote: > > I agree with that sentiment. > > > > Attached patch adds variable to the shmem which is used for module > > activation tracking - set to true in ActiveCommitTs() and false in > >

Re: [HACKERS] Dangling Client Backend Process

On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I don't think that proc_exit(1) is the right way to exit here. It's >> not very friendly to exit without at least attempting to give the >> client a clue about what has gone wrong. I

Re: [HACKERS] Multi-column distinctness.

On Tue, Oct 20, 2015 at 11:59 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra >> wrote: > ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and > use

Re: [HACKERS] Dangling Client Backend Process

Robert Haas wrote: > On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera > wrote: > > Agreed, but I don't think "shutdown" is the right word to use here -- > > that makes it sound like it was orderly. Perhaps "crash"? > > Well, that's a little speculative. "due to

Re: [HACKERS] checkpoint_segments upgrade recommendation?

On 10/17/15 10:25 AM, Michael Paquier wrote: > I think that we should just suggest a reverse formula of the maximum > soft limit of checkpoint_segments for max_wal_size in the release notes > of 9.5, basically: > (3 * your_old_checkpoint_segments + 1) * 16MB = max_wal_size How about this patch?

Re: [HACKERS] Multi-column distinctness.

I wrote: > Tomas Vondra writes: >> The problem is that the actual syntax is ADD [COLUMN], so we can't >> simply use ADD STATISTICS as that would mean a conflict in the grammar. >> Resolving it means either making COLUMN non-optional, or adding >> STATISTICS to

Re: [HACKERS] [PATCH] SQL function to report log message

On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule wrote: > Probably it was my request. I don't like to using NULL as value, that should > be ignored. The "hint" is clean, there NULL can be ignored, but what about > DETAIL or MESSAGE? If the field is required - as MESSAGE

Re: [HACKERS] ROWS FROM(): A Foolish (In)Consistency?

On Tue, Oct 20, 2015 at 11:03 AM, David Fetter wrote: > On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote: >> On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote: >> > On 10/19/15 1:07 PM, David Fetter wrote: >> >> >> >> What I'd like to do is

Re: [HACKERS] Multi-column distinctness.

Robert Haas writes: > On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra > wrote: ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and use REMOVE STATISTICS instead of DROP STATISTICS. That way we can use ALTER

Re: [HACKERS] [COMMITTERS] pgsql: Tab complete CREATE EXTENSION .. VERSION.

On Tue, Oct 20, 2015 at 02:28:15PM +, Robert Haas wrote: > Tab complete CREATE EXTENSION .. VERSION. > > Jeff Janes Would this be worth back-patching to 9.5? It seems like a pretty isolated change with a pretty helpful utility. Cheers, David. -- David Fetter

Re: [HACKERS] Multi-column distinctness.

On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra wrote: >> Koyotaro's changes to force COLUMN to be required won't get through. >> >> ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, and >> use REMOVE STATISTICS instead of DROP STATISTICS. That way

Re: [HACKERS] Typos in plannodes.h

On Tue, Oct 20, 2015 at 7:45 AM, Etsuro Fujita wrote: > I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please > find attached a patch. Oops. Good catch. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 11:59, Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 20, 2015 at 10:51 AM, Tomas Vondra > > wrote: > ISTM that we could use COLLECT STATISTICS instead of ADD STATISTICS, > and > use

Re: [HACKERS] ROWS FROM(): A Foolish (In)Consistency?

On Tue, Oct 20, 2015 at 11:16:13AM -0400, Robert Haas wrote: > On Tue, Oct 20, 2015 at 11:03 AM, David Fetter wrote: > > On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote: > >> On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby > >> wrote: > >> > On

Re: [HACKERS] Dangling Client Backend Process

Robert Haas wrote: > I don't think that proc_exit(1) is the right way to exit here. It's > not very friendly to exit without at least attempting to give the > client a clue about what has gone wrong. I suggest something like > this: > > ereport(FATAL, >

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 17:15 GMT+02:00 Robert Haas : > On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule > wrote: > > Probably it was my request. I don't like to using NULL as value, that > should > > be ignored. The "hint" is clean, there NULL can be ignored,

[HACKERS] [PATCH] Typos in comments

I fixed some typos in posgres. They are all in comments. :) Thanks PATCH.typos Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Multi-column distinctness.

Hi, On 10/20/2015 09:11 PM, Tom Lane wrote: I wrote: Tomas Vondra writes: The problem is that the actual syntax is ADD [COLUMN], so we can't simply use ADD STATISTICS as that would mean a conflict in the grammar. Resolving it means either making COLUMN

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 20:05 GMT+02:00 Robert Haas : > On Tue, Oct 20, 2015 at 11:29 AM, Pavel Stehule > wrote: > > 2015-10-20 17:15 GMT+02:00 Robert Haas : > >> On Tue, Oct 20, 2015 at 11:09 AM, Pavel Stehule < >

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 16:48, Tomas Vondra wrote: > and I can get this to work too >> >> | DROP STATISTICS ON '(' name_list ')' >> >> if I expand out the "DROP opt_column" productions to be two separate >> productions with and without COLUMN,

Re: [HACKERS] bugs and bug tracking

* Joshua D. Drake (j...@commandprompt.com) wrote: > On 10/13/2015 11:41 AM, Bruce Momjian wrote: > > >FYI, I think we already have two limits for the first line summary of > >commit messages. The limits are 64 for commit message subjects and 50 > >characters for gitweb summary pages --- anything

Re: [HACKERS] Less than ideal error reporting in pg_stat_statements

On 10/4/15 6:10 PM, Tom Lane wrote: Andrew Dunstan writes: >Sorry, I'm a bit late to this party. Does what you have committed mean >people are less likely to see "Out of Memory" coming from >pg_stat_statements? If not, what can be done about them short of a >restart? And

Re: [HACKERS] [PATCH] Typos in comments

On 10/20/15 11:08 AM, CharSyam wrote: I fixed some typos in posgres. They are all in comments. :) These all look good to me. RFC. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble!

Re: [HACKERS] [PROPOSAL] Improvements of Hunspell dictionaries support

On 10/20/15 9:00 AM, Artur Zakirov wrote: Internal representation of the dictionary in the PostgreSQL doesn't impose too strict limits on the number of affix rules. There are a flagval array, which size must be increased from 256 to 65000. Is that per dictionary entry, fixed at 64k? That seems

Re: [HACKERS] Why no CONSTANT for row variables in plpgsql?

On 10/19/15 7:12 PM, Tom Lane wrote: Jim Nasby writes: What did seem odd is that while processing the DECLARE section there were plpgsql datums for tt.a and tt.b. I would have expected the assignment to produce a row datum of type tt. Yeah, that's the thing that's

Re: [HACKERS] a raft of parallelism-related bug fixes

On 17 October 2015 at 18:17, Robert Haas wrote: > It's good to have your perspective on how this can be improved, and > I'm definitely willing to write more documentation. Any lack in that > area is probably due to being too close to the subject area, having > spent

Re: [HACKERS] SuperUser check in pg_stat_statements

Rajan, I'll reply off-list since this isn't the right discussion for -hackers. Best, Lukas On Tue, Oct 20, 2015 at 7:02 AM, rajan wrote: > Hey Lukas, > > Thanks. Able to see the queries from all users. Can you explain the > monitoring.get_stat_statements()? > > > > -- >

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby wrote: > I fail to see how doing > > HINT: NULL > > is much better than just not raising a HINT at all... I'm not a huge fan of this patch, as previously noted, but I certainly agree that if we're going to do it, we should

Re: [HACKERS] ROWS FROM(): A Foolish (In)Consistency?

On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote: > On 10/19/15 1:07 PM, David Fetter wrote: >> >> What I'd like to do is lift the restriction on ROWS FROM(), which >> currently requires that the stuff inside the parentheses set-returning >> functions, so constructs

Re: [HACKERS] Multi-column distinctness.

Hi, On 10/20/2015 01:14 PM, Simon Riggs wrote: On 19 October 2015 at 20:16, Tomas Vondra > wrote: Hello Kyotaro-san, On 09/11/2015 06:58 PM, Tomas Vondra wrote: > Maybe the best solution is to abandon the

Re: [HACKERS] Dangling Client Backend Process

On Tue, Oct 20, 2015 at 12:48 AM, Rajeev rastogi wrote: > On 19 October 2015 21:37, Robert Haas [mailto:robertmh...@gmail.com] Wrote: > >>On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera >> wrote: >>> Andres Freund wrote: On 2015-10-14

Re: [HACKERS] ROWS FROM(): A Foolish (In)Consistency?

On Tue, Oct 20, 2015 at 10:52:05AM -0400, Robert Haas wrote: > On Mon, Oct 19, 2015 at 8:02 PM, Jim Nasby wrote: > > On 10/19/15 1:07 PM, David Fetter wrote: > >> > >> What I'd like to do is lift the restriction on ROWS FROM(), which > >> currently requires that the

Re: [HACKERS] [PATCH] SQL function to report log message

2015-10-20 16:50 GMT+02:00 Robert Haas : > On Mon, Oct 19, 2015 at 7:59 PM, Jim Nasby > wrote: > > I fail to see how doing > > > > HINT: NULL > > > > is much better than just not raising a HINT at all... > > I'm not a huge fan of this patch, as

Re: [HACKERS] Why no CONSTANT for row variables in plpgsql?

Jim Nasby writes: > On 10/19/15 7:12 PM, Tom Lane wrote: >> IMO, we ought to get rid of the use of that representation for >> composite-type variables and use the RECORD code paths for them, > That also means there would only need to be changes to RECORD to allow >

Re: [HACKERS] Multi-column distinctness.

On 10/20/2015 11:28 PM, Simon Riggs wrote: On 20 October 2015 at 16:48, Tomas Vondra > wrote: >> On 10/20/2015 09:11 PM, Tom Lane wrote: Can't we just insist that there be only one statistics declaration for a given column

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Oct 10, 2015 at 4:20 AM, Robert Haas wrote: > On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote: >> I don't see the problem? I mean catversion will reliably tell you which >> format the vm is in? > > Totally agreed. > >> We could additionally

Re: [HACKERS] Freeze avoidance of very large table.

On 9 October 2015 at 15:20, Robert Haas wrote: > On Thu, Oct 8, 2015 at 1:52 PM, Andres Freund wrote: > > I don't see the problem? I mean catversion will reliably tell you which > format the vm is in? > > Totally agreed. > This isn't an agreement

Re: [HACKERS] Multi-column distinctness.

Tomas Vondra writes: > On 10/20/2015 11:28 PM, Simon Riggs wrote: >> Since this command doesn't actually ADD the statistics, it just creates >> a specification used by the next ANALYZE, it would seem better to use a >> different keyword than ADD, perhaps DECLARE

Re: [HACKERS] Multi-column distinctness.

On 20 October 2015 at 21:06, Tom Lane wrote: > I am getting more attracted to your suggestion of making these things > stand-alone commands "CREATE STATISTICS" and "DROP STATISTICS". Not only > does that fix the syntactic problems of shoehorning them into ALTER TABLE, > but

Re: [HACKERS] Typos in plannodes.h

On 2015/10/21 0:13, Robert Haas wrote: On Tue, Oct 20, 2015 at 7:45 AM, Etsuro Fujita wrote: I found typos in plannodes.h: s/scan.plan.quals/scan.plan.qual/g Please find attached a patch. Oops. Good catch. Committed. Thanks for picking this up! Best

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/20 13:11, Etsuro Fujita wrote: On 2015/10/20 5:34, Robert Haas wrote: On Mon, Oct 19, 2015 at 3:45 AM, Etsuro Fujita wrote: As Tom mentioned, just recomputing the original join tuple is not good enough. We would need to rejoin the test tuples for the

Re: [HACKERS] checkpoint_segments upgrade recommendation?

On Wed, Oct 21, 2015 at 3:11 AM, Peter Eisentraut wrote: > On 10/17/15 10:25 AM, Michael Paquier wrote: > > I think that we should just suggest a reverse formula of the maximum > > soft limit of checkpoint_segments for max_wal_size in the release notes > > of 9.5, basically: > >

Re: [HACKERS] Debugging buildfarm pg_upgrade check failures

On Sat, Jul 25, 2015 at 10:59:27AM -0400, Tom Lane wrote: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl=2015-07-24%2020%3A29%3A18 > > What evidently happened there is that "pg_ctl start" gave up waiting for > the postmaster to start too soon. The postmaster log appears to

Re: [HACKERS] Multi-tenancy with RLS

On Sat, Oct 10, 2015 at 1:54 AM, Stephen Frost wrote: > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: >> On Fri, Oct 9, 2015 at 2:04 PM, Stephen Frost wrote: >> > * Robert Haas (robertmh...@gmail.com) wrote: >> >> We've got one reloption for views

Re: [HACKERS] Dangling Client Backend Process

On 20 October 2015 23:34, Robert Haas [mailto:robertmh...@gmail.com] Wrote: >On Tue, Oct 20, 2015 at 12:11 PM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I don't think that proc_exit(1) is the right way to exit here. It's >>> not very friendly to exit without at

[HACKERS] ATT_FOREIGN_TABLE and ATWrongRelkindError()

Hi, This may just be nitpicking but I noticed that ATWrongRelkindError() could emit a better message in case of such errors during ALTER COLUMN DEFAULT and ALTER COLUMN SET STORAGE than "%s is of the wrong type" which is what it would emit now. Just need to add a couple of cases to the switch

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Wednesday, October 21, 2015 12:31 PM > To: Robert Haas > Cc: Tom Lane; Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI; > pgsql-hackers@postgresql.org; Shigeru Hanada > Subject: Re: [HACKERS] Foreign join

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, In my performance testing it showed that calling PerformFileFlush() only at segment boundaries and in CheckpointWriteDelay() can lead to rather spikey IO - not that surprisingly. The sync in CheckpointWriteDelay() is problematic because it only is triggered while on schedule, and

Re: [HACKERS] [DOCS] max_worker_processes on the standby

On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote: > I agree with that sentiment. > > Attached patch adds variable to the shmem which is used for module > activation tracking - set to true in ActiveCommitTs() and false in > DeactivateCommitTs(). All the checks inside the

Re: [HACKERS] More work on SortSupport for text - strcoll() and strxfrm() caching

On Sun, Oct 18, 2015 at 2:52 PM, Peter Geoghegan wrote: > On Thu, Oct 15, 2015 at 9:07 AM, Robert Haas wrote: >> Would you be willing to try coding it up that way so we can see how it looks? > > I attach a patch that does it that way. That looks good to