On 21 July 2015 at 21:24, Robert Haas wrote:
> On Tue, Jun 30, 2015 at 4:32 AM, Simon Riggs
> wrote:
> > Yes, I suggest just a single column on pg_stat_activity called
> pct_complete
> >
> > trace_completion_interval = 5s (default)
> >
> > Every interval, we report the current % complete for any
Hello, thank you for the comment.
At Fri, 17 Jul 2015 14:34:53 -0400, Robert Haas wrote
in
> On Fri, Jul 3, 2015 at 4:41 PM, Heikki Linnakangas wrote:
> > At a quick glance, I think this has all the same problems as starting the
> > execution at ExecInit phase. The correct way to do this is to
On Wed, Jul 22, 2015 at 8:48 AM, Michael Paquier
wrote:
> On Mon, Jul 20, 2015 at 9:18 PM, Alexander Korotkov
> wrote:
> > attached patch allows pg_rewind to work when target timeline was
> switched.
> > Actually, this patch fixes TODO from pg_rewind comments.
> >
> > /*
> >* Trace the his
Fujita-san,
Sorry for my late response.
> The latest foreign-join pushdown patch allows fdw_scan_tlist to be set
> to a targetlist even for simple foreign table scans. However, since I
> think we assume that the test tuple of a foreign table for an EPQ
> testing, whether it may be copied from th
On 10 July 2015 at 00:06, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-07-06 11:49:54 -0400, Tom Lane wrote:
> >> Rather than reverting cab9a0656c36739f, which would re-introduce a
> >> different performance problem, perhaps we could have COPY create a new
> >> relfilenode when it does th
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro HORIGUCHI
> Sent: Wednesday, July 22, 2015 4:10 PM
> To: robertmh...@gmail.com
> Cc: hlinn...@iki.fi; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Asyn
On 07/11/2015 12:19 AM, Pavel Stehule wrote:
2015-07-10 18:43 GMT+02:00 Tom Lane :
An example of what would presumably happen if we adopted this sort of rule
(I've not checked whether the patch as written does this, but it would
logically follow) is that appending a float to an integer array wo
Hi KaiGai-san,
On 2015/07/22 16:44, Kouhei Kaigai wrote:
>> The latest foreign-join pushdown patch allows fdw_scan_tlist to be set
>> to a targetlist even for simple foreign table scans. However, since I
>> think we assume that the test tuple of a foreign table for an EPQ
>> testing, whether it m
Hello,
>I think it'd be better to combine both numbers into one report:
>It'd also be good to standardize on where the * 100 is happening.
Done
>can be replaced by
>(itemptr->ipblkid != vacrelstats->last_scanned_page)
Get compiler error : invalid operands to binary != (have ‘BlockIdData’ and
‘Bloc
While working on the issue "Foreign join pushdown vs EvalPlanQual", I
happened to notice odd behaviors of late row locking in FDWs. An
example will be shown below using the attached postgres_fdw patch, which
is basically the same as [1], but I changed its isolation level to READ
COMMITTED and modi
Thakur, Sameer wrote:
> Hello,
> >I think it'd be better to combine both numbers into one report:
> >It'd also be good to standardize on where the * 100 is happening.
> Done
> >can be replaced by
> >(itemptr->ipblkid != vacrelstats->last_scanned_page)
> Get compiler error : invalid operands to bina
On Wed, Jul 22, 2015 at 8:19 PM, Alvaro Herrera
wrote:
>
> Not sure what Jim meant. Maybe he meant to be aware of when spilling to
> disk happens? Obviously, things become slower, so maybe you need to
> consider it for progress reporting purposes.
>
Perhaps the m_w_m determines how many dead tu
On Wed, Jul 22, 2015 at 3:02 AM, Simon Riggs wrote:
> For me, the user workflow looks like these
>
> Worried: "Task X is taking ages? When is it expected to finish?"
> Ops: 13:50
>
> Worried: "Task X is still running? But I thought its ETA was 13:50?"
> Ops: Now says 14:30
> Worried: "Is it s
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Wednesday, July 22, 2015 7:05 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] fdw_scan_tlist for foreign table scans breaks EPQ
> testing,
> doesn't it?
>
> Hi
On 22 July 2015 at 13:00, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 3:02 AM, Simon Riggs
> wrote:
> > For me, the user workflow looks like these
> >
> > Worried: "Task X is taking ages? When is it expected to finish?"
> > Ops: 13:50
> >
> > Worried: "Task X is still running? But I though
Hi!
Following discussion at https://commitfest.postgresql.org/5/190/ patch, I found
(at seems to me) a way to stringify MAKE_SQLSTATE(), the idea is to use char
array as string:
#include
#define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \
((char[]){(char)(ch1),(char)(ch2),(char)(ch3),(char)(ch4),
On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes wrote:
> Attached is a patch that implements the vm scan for truncation. It
> introduces a variable to hold the last blkno which was skipped during the
> forward portion. Any blocks after both this blkno and after the last
> inspected nonempty page (wh
Teodor Sigaev writes:
> Following discussion at https://commitfest.postgresql.org/5/190/ patch, I
> found
> (at seems to me) a way to stringify MAKE_SQLSTATE(), the idea is to use char
> array as string:
> #define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \
> ((char[]){(char)(ch1),(char)(ch2),(char)(
On Mon, Jul 20, 2015 at 8:20 AM, Michael Paquier
wrote:
> After a certain amount of time without anything happening, I would
> recommend just adding it to a CF to have it get attention. I imagine
> that it is one of the reasons why there is as well a category "Bug
> Fix".
+1. I would recommend a
On Wed, Jul 22, 2015 at 8:24 AM, Simon Riggs wrote:
> * An estimate of the estimated time of completion - I liked your view that
> this prediction may be costly to request
I'm saying it may be massively unreliable, not that it may be costly.
(Someone else may have said that it would be costly, bu
On Wed, Jul 22, 2015 at 8:13 AM, Kouhei Kaigai wrote:
>> No, what I'm concerned about is the case when scanrelid > 0.
>>
> Hmm. if scanrelid > 0, then fdw_scan_tlist should be NIL.
> I want to put Assert(scanrelid==0 || fdw_scan_tlist == NIL) just after
> the GetForeignPlan() in createplan.c.
>
>
#define MAKE_SQLSTATE(ch1,ch2,ch3,ch4,ch5) \
((char[]){(char)(ch1),(char)(ch2),(char)(ch3),(char)(ch4),(char)(ch5),(char)'\0'})
I'm pretty sure that's a gcc-ism, not standard C.
Hmm, after some digging: the feature is called compound literals and it was
introduced in c99 although gcc has suppor
On Wed, Jul 22, 2015 at 5:00 PM, Robert Haas wrote:
> +1. I would recommend adding it to the CF *immediately* to have it
> get attention. The CF app is basically our patch tracker.
Thanks, I have done so now: https://commitfest.postgresql.org/6/313/
Regards,
Marti
--
Sent via pgsql-hackers
On Wed, Jul 15, 2015 at 11:52 AM, Simon Riggs wrote:
> On 15 July 2015 at 16:44, Andres Freund wrote:
>> On 2015-07-15 16:36:12 +0100, Simon Riggs wrote:
>> > On 15 July 2015 at 16:28, Andres Freund wrote:
>> > > I think that's generally a fair point. But here we're discussing to
>> > > add
>> >
On Wed, Jul 22, 2015 at 2:50 AM, Etsuro Fujita
wrote:
> On 2015/07/22 12:40, Noah Misch wrote:
>> I vote for alpha2. Comparing the "Open Issues" and "resolved after
>> 9.5alpha1"
>> sections of https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items,
>> we've
>> not transitioned to a qualitati
On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
wrote:
> On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas wrote:
>> Notice that the collation specifier is gone. Oops.
>
> As it is not possible to specify directly a constraint for a PRIMARY
> KEY expression, what about switching dumpConstraint to ha
On 07/22/2015 09:10 AM, Kyotaro HORIGUCHI wrote:
Hello,
At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev
wrote in <55ae2cd9.4050...@postgrespro.ru>
On 07/21/2015 01:18 PM, Andres Freund wrote:
On 2015-07-21 13:11:36 +0300, Ildus Kurbangaliev wrote:
/*
* Top-level transactions
Hello,
I've performed some tests on pg_strom according to the wiki. But it seems that
queries run slower on GPU than CPU. Can someone shed a light on what's wrong
with my settings. My setup was Quadro K620 + CUDA 7.0 (For Ubuntu 14.10) +
Ubuntu 15.04. And the results was
with pg_strom
==
On 7/22/15 6:58 AM, Amit Langote wrote:
On Wed, Jul 22, 2015 at 8:19 PM, Alvaro Herrera
wrote:
Not sure what Jim meant. Maybe he meant to be aware of when spilling to
disk happens? Obviously, things become slower, so maybe you need to
consider it for progress reporting purposes.
Perhaps t
On 7/22/15 9:15 AM, Robert Haas wrote:
I'm not proposing this feature, I'm merely asking for it to be defined in a
>way that makes it work for more than just VACUUM. Once we have a way of
>reporting useful information, other processes can be made to follow that
>mechanism, like REINDEX, ALTER TAB
On Mon, Jul 6, 2015 at 8:49 PM, Haribabu Kommi wrote:
> I ran some performance tests on a 16 core machine with large shared
> buffers, so there is no IO involved.
> With the default value of cpu_tuple_comm_cost, parallel plan is not
> getting generated even if we are selecting 100K records from 40
On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes wrote:
> > Attached is a patch that implements the vm scan for truncation. It
> > introduces a variable to hold the last blkno which was skipped during the
> > forward portion. Any blocks after bo
On 07/22/2015 11:18 AM, Simon Riggs wrote:
On 10 July 2015 at 00:06, Tom Lane wrote:
Andres Freund writes:
On 2015-07-06 11:49:54 -0400, Tom Lane wrote:
Rather than reverting cab9a0656c36739f, which would re-introduce a
different performance problem, perhaps we could have COPY create a new
Jeff Janes wrote:
> On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner wrote:
>> Kevin Grittner wrote:
>>
>>> If you run `make installcheck` against a cluster with
>>> default_transaction_isolation = 'repeatable read' you get one
>>> failure:
>>
>>> + ERROR: brin_summarize_new_values() cannot run i
On 07/22/2015 08:16 AM, YANG wrote:
>
> Hello,
>
> I've performed some tests on pg_strom according to the wiki. But it seems that
> queries run slower on GPU than CPU. Can someone shed a light on what's wrong
> with my settings. My setup was Quadro K620 + CUDA 7.0 (For Ubuntu 14.10) +
> Ubuntu 15
On 07/21/2015 10:25 PM, Fabien COELHO wrote:
>
> Hello Josh,
>
>>> Maybe -f file.sql:weight (yuk from my point of view, but it can be done
>>> easily).
>>
>> Maybe it's past time for pgbench to have a config file?
>
> That is an idea. For "simple" usage, for backward compatibility and for
> peo
All:
Sounds like the overwhemling consensus is Alpha2 then. Will run with it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Tue, Jul 21, 2015 at 4:06 PM, Peter Geoghegan wrote:
> Design considerations and consequences
>
Good write-up.
> I'm not concerned about synchronized scans breaking my assumption of a
> physical ordering of heaptuples being fed to tuple
Kevin Grittner wrote:
> If you run `make installcheck` against a cluster with
> default_transaction_isolation = 'repeatable read' you get one
> failure:
So there's some code that's specifically intended to handle this case:
/*
* If
Hey everyone,
You have probably heard that Mike Stonebraker recently won the Turing award. A
recording of his award lecture is available at:
https://www.youtube.com/watch?v=BbGeKi6T6QI
It is an entertaining talk overall. If you fast forward to about the 1:07 mark,
he makes some comments about
On Thu, Jul 16, 2015 at 9:49 AM, Fujii Masao wrote:
> Volatilities of pg_xact_commit_timestamp() and pg_last_committed_xact()
> are now STABLE. But ISTM that those functions can return different results
> even within a single statement. So we should change the volatilities of them
> to VOLATILE?
On Tue, Jul 21, 2015 at 2:27 PM, Andres Freund wrote:
> But I'm not going to complain too loudly if we don't do invalidation.
Not doing invalidation seems silly to me. But I don't want to bend
Paul too far around the axle, either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
On Tue, Jul 21, 2015 at 6:42 PM, Jolly Chen wrote:
> You have probably heard that Mike Stonebraker recently won the Turing award.
> A recording of his award lecture is available at:
> https://www.youtube.com/watch?v=BbGeKi6T6QI
>
> It is an entertaining talk overall. If you fast forward to about
Hi
It looks like we have broken the ROW expression without explicit
ROW keyword in GROUP BY.
I mean, after Grouping sets merge, if we have (c1, c2) in group by,
we are treating it as ROW expression for grouping, but at the same
time we are allowing individual column in the target list.
However thi
If so, I would vote for:
-f script1.bench:3 -f script2.bench:1
over:
-f script1.bench -w 3 -f script2.bench -w 1
Ok, I'll take that into consideration. Any other opinion out there? The
current v3 version is:
-w 3 -f script1.bench -w 1 -f script2.bench
With provision to generate error
Hi,
On 2015-07-22 23:53:26 +0530, Jeevan Chalke wrote:
> It looks like we have broken the ROW expression without explicit
> ROW keyword in GROUP BY.
That was "intentional", and is actually standards required
behaviour. GROUP BY (a, b) is the same as GROUP BY a,b. It'd otherwise
be pretty confusin
On 2015-07-22 10:54:14 -0700, Josh Berkus wrote:
> Making command-line options order-dependant breaks a lot of system call
> libraries in various languages, as well as being easy to mess up.
What?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Robert Haas writes:
> On Tue, Jul 21, 2015 at 2:27 PM, Andres Freund wrote:
>> But I'm not going to complain too loudly if we don't do invalidation.
> Not doing invalidation seems silly to me. But I don't want to bend
> Paul too far around the axle, either.
Just to be clear here: the case we a
On 2015-07-22 14:55:15 -0400, Tom Lane wrote:
> Just to be clear here: the case we are concerned about is, given that
> we have determined that function X is or is not a member of one of the
> extensions marked "shippable" for a given connection, is it likely that
> that status will change (while t
On Wed, Jul 22, 2015 at 11:03 AM, Robert Haas wrote:
>> I'm not concerned about synchronized scans breaking my assumption of a
>> physical ordering of heaptuples being fed to tuplesort.c. I think that
>> it is unlikely to ever be worth seriously considering this case.
>
> Why not?
The case for do
On July 22, 2015 at 12:15:14 PM, Andres Freund (and...@anarazel.de) wrote:
It doesn't seem that unlikely that somebody does an ALTER SERVER OPTIONS
SET .. to add an extension to be shippable while connections are already
using the fdw. It'll be confusing if some clients are fast and some
others
> I don't think there's any line near pg_dumpall. That tool seems to
> have grown out of desperation without much actual design. I think it
> makes more sense to plan around that's the best pg_dump behavior for the
> various use cases.
Ok.
> I like Noah's proposal of having pg_dump --create rep
On Wed, Jul 22, 2015 at 4:42 PM, Adam Brightwell <
adam.brightw...@crunchydatasolutions.com> wrote:
>
> [...]
>
> Also, I think this would potentially conflict with what Fabrízio is
> doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
> preferable solution.
>
> https://commitfest
Why is this message logged by default in a fresh installation? The
technicality of that message doesn't seem to match the kinds of messages
that we normally print at startup.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On 3 July 2015 at 20:50, Tom Lane wrote:
> Petr Korobeinikov writes:
>> Fixed. Now both \ev and \sv numbering lines starting with "1". New version
>> attached.
>
> Applied with a fair amount of mostly-cosmetic adjustment.
>
>> As I've already noticed that pg_get_viewdef() does not support full s
Dean Rasheed writes:
> On 3 July 2015 at 20:50, Tom Lane wrote:
>> Oh? If that were true, pg_dump wouldn't work on such views. It is kind
>> of a PITA for this purpose that it doesn't include the CREATE text for
>> you, but we're surely not changing that behavior now.
> This appears to be miss
On Wed, Jul 22, 2015 at 4:11 PM, Peter Eisentraut wrote:
> Why is this message logged by default in a fresh installation? The
> technicality of that message doesn't seem to match the kinds of messages
> that we normally print at startup.
It seems nobody likes that message.
I did it that way bec
On Wed, Jul 22, 2015 at 7:34 AM, Robert Haas wrote:
> On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
> wrote:
> > On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas
> wrote:
> >> Notice that the collation specifier is gone. Oops.
> >
> > As it is not possible to specify directly a constraint for a
On Wed, Jul 22, 2015 at 2:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 21, 2015 at 2:27 PM, Andres Freund wrote:
>>> But I'm not going to complain too loudly if we don't do invalidation.
>
>> Not doing invalidation seems silly to me. But I don't want to bend
>> Paul too far aroun
On Tue, Jul 21, 2015 at 9:23 AM, Robert Haas wrote:
> rhaas=# create unique index on foo (a collate "C");
> CREATE INDEX
> rhaas=# alter table foo add primary key using index foo_a_idx;
> ALTER TABLE
>
> Now dump and restore this database. Then:
>
> Notice that the collation specifier is gon
On 22 July 2015 at 21:37, Tom Lane wrote:
> Dean Rasheed writes:
>> On 3 July 2015 at 20:50, Tom Lane wrote:
>>> Oh? If that were true, pg_dump wouldn't work on such views. It is kind
>>> of a PITA for this purpose that it doesn't include the CREATE text for
>>> you, but we're surely not chang
On 21 July 2015 at 04:53, Michael Paquier wrote:
> On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost wrote:
>> We need to be careful to avoid the slippery slope of trying to prevent
>> all covert channels, which has been extensively discussed previously.
I think this is more serious than the covert
On 06/13/2015 05:02 AM, Thomas Munro wrote:
Since the multixact equivalent of this problem[1] fell through the
cracks on the multixact mega-thread, here is an updated patch that
addresses this problem for both pg_subtrans and pg_multixact/offsets
using the same approach: always step back one mult
I wrote:
> We could alternatively provide two scan-initialization callbacks,
> one that analyzes the parameters before we do heap_beginscan,
> and another that can do additional setup afterwards. Actually,
> that second call would really not be meaningfully different from
> the ReScan call, so ano
On Thu, Jul 23, 2015 at 5:47 AM, Gurjeet Singh wrote:
> On Wed, Jul 22, 2015 at 7:34 AM, Robert Haas wrote:
>>
>> On Tue, Jul 21, 2015 at 8:34 PM, Michael Paquier
>> wrote:
>> > On Wed, Jul 22, 2015 at 1:23 AM, Robert Haas
>> > wrote:
>> >> Notice that the collation specifier is gone. Oops.
>>
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Wednesday, July 22, 2015 11:19 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Etsuro Fujita; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] fdw_scan_tli
On Thu, Jul 16, 2015 at 10:36 PM, Michael Paquier
wrote:
>
> I had a look at this patch, and here are some minor comments:
> 1) In alter_table.sgml, you need a space here:
> [ IF NOT EXISTS ] 2)
> + check_for_column_name_collision(targetrelation, newattname,
false);
> (void) needs to be adde
Hello,
> Let me ask an elemental question.
>
> If we have ParallelAppend node that kicks a background worker process for
> each underlying child node in parallel, does ForeignScan need to do something
> special?
Although I don't see the point of the background worker in your
story but at least f
Hi All,
On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote:
> Jim Nasby writes:
> > On 7/13/15 3:39 PM, dinesh kumar wrote:
> >> Ah. It's' my bad interpretation. Let me work on it, and will send a new
> >> patch as a wrapper sql function for ereport.
>
> > You might want to present a plan for that
Hello,
At Wed, 22 Jul 2015 17:50:35 +0300, Ildus Kurbangaliev
wrote in <55afadbb.9090...@postgrespro.ru>
> On 07/22/2015 09:10 AM, Kyotaro HORIGUCHI wrote:
> > Hello,
> >
> > At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev
> > wrote in
> > <55ae2cd9.4050...@postgrespro.ru>
> >> On 07/21/
Hi All,
Would like to propose PERMISSIVE mode for the COPY created out files.
I mean, at this moment, if do "COPY" as postgres instance owner, i can able
to read the file as non instance user as well, and would like to restrict
this to
instance owner WITH PERMISSIVE option.
Let me know your thoug
Hi, I forgot to mention a significant point.
> At Wed, 22 Jul 2015 17:50:35 +0300, Ildus Kurbangaliev
> wrote in <55afadbb.9090...@postgrespro.ru>
> > On 07/22/2015 09:10 AM, Kyotaro HORIGUCHI wrote:
> > > Hello,
> > >
> > > At Tue, 21 Jul 2015 14:28:25 +0300, Ildus Kurbangaliev
> > > wrote in
On 23 June 2015 at 05:37, Robert Haas wrote:
> When a PostgreSQL system wedges, or when it becomes dreadfully slow
> for some reason, I often find myself relying on tools like strace,
> gdb, or perf to figure out what is happening. This doesn't tend to
> instill customers with confidence; they w
On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar wrote:
> Hi All,
>
> On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote:
>>
>> Jim Nasby writes:
>> > On 7/13/15 3:39 PM, dinesh kumar wrote:
>> >> Ah. It's' my bad interpretation. Let me work on it, and will send a new
>> >> patch as a wrapper sql fun
On Wed, Jul 22, 2015 at 8:56 PM, Michael Paquier
wrote:
> On Thu, Jul 23, 2015 at 10:56 AM, dinesh kumar
> wrote:
> > Hi All,
> >
> > On Mon, Jul 13, 2015 at 2:12 PM, Tom Lane wrote:
> >>
> >> Jim Nasby writes:
> >> > On 7/13/15 3:39 PM, dinesh kumar wrote:
> >> >> Ah. It's' my bad interpretat
Hi Yang,
> I've performed some tests on pg_strom according to the wiki. But it seems that
> queries run slower on GPU than CPU. Can someone shed a light on what's wrong
> with my settings. My setup was Quadro K620 + CUDA 7.0 (For Ubuntu 14.10) +
> Ubuntu 15.04. And the results was
>
:
>
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh Berkus
> Sent: Thursday, July 23, 2015 2:49 AM
> To: YANG; pgsql-hackers@postgresql.org; KaiGai Kohei
> Subject: Re: [HACKERS] Queries runs slow on GPU with PG-Str
On Thu, Jul 23, 2015 at 9:55 AM, Fabrízio de Royes Mello wrote:
> Thank you for the review.
+ /* skipp if the name already exists and if_not_exists is true */
s/skipp/skip.
Except that this looks in good shape to me (see attached for a version
fixing the typo) so switched to "Ready for comm
On Wed, Jul 22, 2015 at 5:17 PM, Dean Rasheed wrote:
> There's another issue here though -- just adding filters to the
> pg_stats view won't prevent a determined user from seeing the contents
> of the underlying table. For that, the view needs to have the
> security_barrier property. Arguably the
On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson wrote:
> On 07/02/2015 06:13 PM, Peter Eisentraut wrote:
>>
>> I think this would be a useful feature, and the implementation looks
>> sound. But I don't like how the reload is organized. Reinitializing
>> the context in the sighup handler, aside
Hello,
> > 2015-07-19 20:54 GMT+02:00 Pavel Stehule :
> >> I am sending updated version. It implements new long option
> >> "--strict-names". If this option is used, then for any entered name
> >> (without any wildcard char) must be found least one object. This option has
> >> not impact on patter
After few failed attempt to propose Autonomous transaction earlier. I along
with Simon Riggs would like to propose again but completely different in
approach.
We also had discussion about this feature in last PGCon2015 Unconference Day,
those who missed this discussion, please refer
Sorry for the bogus on bogus.
At Thu, 23 Jul 2015 14:22:59 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20150723.142259.200902861.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
>
> > > 2015-07-19 20:54 GMT+02:00 Pavel Stehule :
> > >> I am sending updated version. It implements new long
On Wed, Jul 22, 2015 at 03:42:58PM -0400, Adam Brightwell wrote:
> > I like Noah's proposal of having pg_dump --create reproduce all
> > database-level state.
>
> Should it be enabled by default? If so, then wouldn't it make more
> sense to call it --no-create and do the opposite? So, --no-creat
84 matches
Mail list logo
