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 produced by the join from whole-row images of th
> 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 whole-row images of the baserels.
> >> But th
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 prev
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 $$ d
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 Profess
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 b
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)
+ {
+ (*recheckMtd
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 wrot
> -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
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 raid
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
> install
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 eac
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 t
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,
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
> different ways some
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 t
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 t
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, the group setting.
>>
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 pg_stat_statements.c by disabling the su
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 into a new
>> installation com
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.
> >>
> >> The context where
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 with
>> > the opinion.
>>
>>
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 =>
> {
> CPPF
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
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 processes.
> >>
> >> The context where this aris
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
> t
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
> > like the childr
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
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 not looked at what's
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 conditi
On 10/19/2015 09:47 AM, Jeff Janes wrote:
On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian mailto:br...@momjian.us>> 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 fingers just autocom
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 by custom function, but
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 t
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 a
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 thus
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 = a + 1 WHERE b = 1;
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
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 earlier row-locking, or
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 al
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 either:
regression=# do $$ d
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 cannot be a super user but
>>
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:
{
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.
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 (...
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.
What the row datum mechani
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 t
> 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 earlier row-lo
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. Consider:
A=# BEGIN;
A=# UPDAT
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 killing the backends
>>> > runni
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 pgsql
> -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
51 matches
Mail list logo