Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/17 9:58, Robert Haas wrote: But with Etsuro Fujita's patch, and I think what you have proposed has been similar, how are you going to do it? The proposal is to call the recheck method and hope for the best, but what is the recheck method going to do? Where is it going to get the

[HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi, We cannot to declare variable with referenced type on other composite variable. This limit is probably artificial, because any composite type is any type too in PostgreSQL. The issue: referencing on composite variables doesn't work do $$ declare x int; y x%type; begin end; $$; -- ok do $$

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

2015-10-18 21:13 GMT+02:00 Jim Nasby : > On 10/17/15 11:49 AM, Pavel Stehule wrote: > >> 2015-10-17 18:42 GMT+02:00 Jim Nasby > >: >> >> On 10/15/15 11:51 PM, Pavel Stehule wrote: >> >> I don't think

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/17 12:22, Robert Haas wrote: On Fri, Oct 16, 2015 at 9:51 PM, Tom Lane wrote: Robert Haas writes: Both you and Etsuro Fujita are proposing to fix this problem by somehow making it the FDW's problem to reconstruct the tuple previously

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Fri, Oct 16, 2015 at 9:51 PM, Tom Lane wrote: > > Robert Haas writes: > >> Both you and Etsuro Fujita are proposing to fix this problem by > >> somehow making it the FDW's problem to reconstruct the tuple > >> previously produced by the join from

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Monday, October 19, 2015 8:52 PM > To: Kaigai Kouhei(海外 浩平); Kyotaro HORIGUCHI > Cc: pgsql-hackers@postgresql.org; shigeru.han...@gmail.com; > robertmh...@gmail.com > Subject: Re: [HACKERS] Foreign join

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

I wrote: >> As Robert mentioned in [1], I think that if we're inside EPQ, >> pushed-down quals and/or pushed-down joins should be locally rechecked >> in the same way as other cases such as IndexRecheck. So, I'll propose >> the updated version of the patch. On 2015/10/16 18:48, Kouhei Kaigai

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On 2015/10/16 19:03, Kouhei Kaigai wrote: *** 48,59 ExecScanFetch(ScanState *node, + /* +* Execute recheck plan and get the next tuple if foreign join. +*/ + if (scanrelid == 0) + { +

Re: [HACKERS] Some questions about the array.

Hello again. I attached simple patch for omitted boundaries in the slice. This will simplify the writing of SQL. Instead: select arr[2:array_upper(arr, 1)]; you can write: select arr[2:]; simple and elegant. Omitted boundaries is prohibited in UPDATE. Thanks. -- YUriy Zhuravlev Postgres

[HACKERS] Checkpoint throttling issues

Hi, working on the checkpoint sorting/flushing patch I noticed a number of preexisting issues: 1) The progress passed to CheckpointWriteDelay() will often be wrong - it's calculated as num_written / num_to_write, but num_written is only incremented if the buffer hasn't since independently

Re: [HACKERS] fs issues on software raid0 (PG_VERSION does not contain valid data)

Hi, On 10/18/2015 08:37 PM, Andres Freund wrote: Hi, On 2015-10-18 20:25:29 +0200, Tomas Vondra wrote: I've been doing a lot of filesystem testing / benchmarking recently, and today I've ran into a really strange issue with ext4 on two SSD devices in a RAID-0 configuration (Linux software

Re: [HACKERS] pg_restore cancel TODO

On Wed, Oct 14, 2015 at 09:34:04AM -0700, Jeff Janes wrote: > I've added the TODO item: > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the keyboard) > make it cancel the children processes. > > The context where this arises is that I want to populate data into a new >

Re: [HACKERS] PATCH: 9.5 replication origins fix for logical decoding

Hi all Patch revision 3 attached. It's a one-liner, with just the fix, and an explanatory note in the patch header. I'll leave the test changes for now, per Andres's feedback. I'll write up a proposed addition to the replication origin docs that explains the existence of separate origins for

Re: [HACKERS] Improve the concurency of vacuum full table and select statement on the same relation

The lock upgrade for vacuum full table tends to cause deadlock with other lock upgrade transaction which is from AccessShareLock to lockmode > AccessShareLock. Tom Lane's concern is that it will cause vacuum full failed after do a lot of work. But If we can always let other transaction failed

Re: [HACKERS] pg_restore cancel TODO

Jeff Janes wrote: > I've added the TODO item: > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > keyboard) make it cancel the children processes. > > The context where this arises is that I want to populate data into a new > installation compiled with a patch under review,

[HACKERS] SuperUser check in pg_stat_statements

Hello, When monitoring using pg_stat_satements I see that postgres by default conceals queries executed by other users from the user who is selecting the pg_stat_statements view. I have edited the pg_stat_statements.c by disabling the superuser check function so that all queries will be visible

Re: [HACKERS] SuperUser check in pg_stat_statements

On Mon, Oct 19, 2015 at 5:15 PM, rajan wrote: > Hello, > > When monitoring using pg_stat_satements I see that postgres by default > conceals queries executed by other users from the user who is selecting the > pg_stat_statements view. > > I have edited the

Re: [HACKERS] pg_restore cancel TODO

Alvaro Herrera writes: > Jeff Janes wrote: >> I've added the TODO item: >> >> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the >> keyboard) make it cancel the children processes. >> >> The context where this arises is that I want to populate data

[HACKERS] Re: [COMMITTERS] pgsql: Define integer limits independently from the system definitions.

Hi Andres, On Fri, Apr 3, 2015 at 12:45 AM, Andres Freund wrote: > Define integer limits independently from the system definitions. > > In 83ff1618 we defined integer limits iff they're not provided by the > system. That turns out not to be the greatest idea because there's

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 11:51:00AM -0300, Alvaro Herrera wrote: > Jeff Janes wrote: > > I've added the TODO item: > > > > When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > > keyboard) make it cancel the children processes. > > > > The context where this arises is that I want

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

On Wed, Oct 14, 2015 at 3:16 AM, Josh Berkus wrote: > On 10/13/2015 11:02 AM, Masahiko Sawada wrote: >> I thought that this feature for postgresql should be simple at first >> implementation. >> It would be good even if there are some restriction such as the >> nesting level,

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

On Sat, Oct 17, 2015 at 9:16 PM, Andrew Dunstan wrote: > If all that is required is a #define, like CLOBBER_CACHE_ALWAYS, then no > special buildfarm support is required - you would just add that to the > animal's config file, more or less like this: > > config_env => >

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 08:28:34AM -0700, Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> I've added the TODO item: > >> > >> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > >> keyboard) make it cancel the children processes. >

Re: [HACKERS] Dangling Client Backend Process

On Sat, Oct 17, 2015 at 4:52 PM, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2015-10-14 17:33:01 +0900, Kyotaro HORIGUCHI wrote: >> > If I recall correctly, he concerned about killing the backends >> > running transactions which could be saved. I have a sympathy

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

Re: [HACKERS] SuperUser check in pg_stat_statements

Thanks Stephen and Shulgin for your response. Will go through the patch and will try to solve my problem using that. My scenario is that i need to have an user who cannot be a super user but a monitor user, who will be able to see all the queries executed by all users. -- View this message in

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

On Mon, Oct 19, 2015 at 10:24:37AM -0700, David Fetter wrote: > Folks, > > As I was learning how best to add native weighted statistics, coming > soon, I noticed that our ROWS FROM() constructor takes only > set-returning functions, gluing the outputs together side by side > without a join

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

Folks, As I was learning how best to add native weighted statistics, coming soon, I noticed that our ROWS FROM() constructor takes only set-returning functions, gluing the outputs together side by side without a join condition of any kind. This is a handy capability, which I don't find elsewhere

Re: [HACKERS] Checkpoint throttling issues

preexisting issues: 1) The progress passed to CheckpointWriteDelay() will often be wrong - it's calculated as num_written / num_to_write, but num_written is only incremented if the buffer hasn't since independently been written out. That's bad because it mean's we'll think we're further

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

Hi 2015-10-13 22:01 GMT+02:00 Robert Haas : > This patch is marked as Ready for Committer in the CommitFest > application. Here is my attempt to summarize the votes upthread: > > Tom Lane: plpgsql RAISE is sufficient; we don't need this. > Pavel Stehule: could be replaced

Re: [HACKERS] Checkpoint throttling issues

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 here for the checkpoint, let's do as less work as possible to avoid getting even later", and

Re: [HACKERS] pg_restore cancel TODO

On 10/19/2015 09:47 AM, Jeff Janes wrote: On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian > wrote: Sorry, I don't know how I managed to screw this up so much. pg_restore, not pg_upgrade. I've never looked into pg_restore much until recently, so my

Re: [HACKERS] [PATCH v3] GSSAPI encryption support

Stephen Frost writes: > As for this patch, the reason I've not been as involved (beyond being > ridiculously busy) is that Michael's environment, which at least appears > perfectly reasonable (and works with PG unpatched) isn't working. If we > can get that working (and I've

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, Here is a v13, which is just a rebase after 1aba62ec. I'm working on this patch, to get it into a state I think it'd be commitable. I'll review it carefully. Also, if you can include some performance feature it would help, even if I'll do some more runs. In my performance

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

On Mon, Oct 19, 2015 at 12:17 AM, Kouhei Kaigai wrote: > 1. Fetch every EPQ slot of base relations involved in this join. >In case of ForeignScan, all the required tuples of base relations >should be filled because it is preliminary fetched by whole-row var >if

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

On 10/19/15 5:16 PM, Jim Nasby wrote: Yeah, was hoping someone knew offhand why this was a problem. Guess I'll rip the checks out and see what explodes. ... and what blows up is exec_eval_datum(): case PLPGSQL_DTYPE_ROW: {

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

On 10/19/15 1:09 AM, Pavel Stehule wrote: What I was trying to say is that if the argument to a USING option is NULL then RAISE should skip over it, as if it hadn't been applied at all. Similar to how the code currently tests for \0.

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

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 weird about plpgsql's ROW datums.

Re: [HACKERS] SuperUser check in pg_stat_statements

On 10/19/15 3:48 PM, rajan wrote: Thanks Stephen and Shulgin for your response. Will go through the patch and will try to solve my problem using that. My scenario is that i need to have an user who cannot be a super user but a monitor user, who will be able to see all the queries executed by

Re: [HACKERS] SuperUser check in pg_stat_statements

On Mon, Oct 19, 2015 at 3:12 PM, Jim Nasby wrote: > On 10/19/15 3:48 PM, rajan wrote: > >> Thanks Stephen and Shulgin for your response. >> >> Will go through the patch and will try to solve my problem using that. >> >> My scenario is that i need to have an user who

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

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 something like the following would actually work: SELECT * FROM ROWS FROM ( (VALUES

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

On 10/18/15 10:16 PM, Tom Lane wrote: Jim Nasby writes: Is there a particular reason why row and record variables can't be CONSTANT in plpgsql? Well, you can't usefully do anything with such a variable unless it can be initialized, which isn't currently supported

Re: [HACKERS] Multi-column distinctness.

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 STATISTICS DROP STATISTICS (ALTER STATISTICS seems a bit excessive at this point). Another thing is

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> On Mon, Oct 19, 2015 at 12:17 AM, Kouhei Kaigai wrote: > > 1. Fetch every EPQ slot of base relations involved in this join. > >In case of ForeignScan, all the required tuples of base relations > >should be filled because it is preliminary fetched by whole-row var >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

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 baserels even if ROW_MARK_COPY is in use.

Re: [HACKERS] Dangling Client Backend Process

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 17:33:01 +0900, Kyotaro HORIGUCHI wrote: >>> > If I recall correctly, he concerned about

Re: [HACKERS] SuperUser check in pg_stat_statements

Jim, I already tried to create a view upon the pg_stat_statements, but no luck. -- View this message in context: http://postgresql.nabble.com/SuperUser-check-in-pg-stat-statements-tp5870589p5870683.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 09:26:21AM -0700, Jeff Janes wrote: > It seems like gdb eats signals that you send a process while it is being > debugged, so it is hard to figure out what is going on.  From strace, it looks > like the children do receive a signal but either ignore it, or set a flag and >

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian wrote: > On Mon, Oct 19, 2015 at 09:26:21AM -0700, Jeff Janes wrote: > > It seems like gdb eats signals that you send a process while it is being > > debugged, so it is hard to figure out what is going on. From strace, it > looks

Re: [HACKERS] SuperUser check in pg_stat_statements

Rajan, * rajan (vgmon...@gmail.com) wrote: > When monitoring using pg_stat_satements I see that postgres by default > conceals queries executed by other users from the user who is selecting the > pg_stat_statements view. > > I have edited the pg_stat_statements.c by disabling the superuser check

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 8:28 AM, Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> I've added the TODO item: > >> > >> When pg_upgrade -j ... is interrupted (for example, ctrl-C from the > >> keyboard) make it cancel the children