At 2015-03-14 09:44:02 +0200, hlinn...@iki.fi wrote:
>
> Perhaps it would be time to restart the discussion on standardizing
> SRP as a SASL mechanism in IETF.
I haven't seen much evidence that there's any interest in doing this; in
fact, I can't remember the author of the draft you pointed to bei
On 2015-03-17 20:50:48 -0700, Peter Geoghegan wrote:
> On Mon, Mar 16, 2015 at 6:22 AM, Petr Jelinek wrote:
> >> Do you think it is ready for committer?
> >>
> >
> > In my opinion, yes.
>
> If it wasn't for the autoconf parts of this, I'd probably agree with
> you. I need to go over that more care
Hello, The attached is non-search version of unique join.
It is not fully examined but looks to work as expected. Many
small changes make the patch larger but affected area is rather
small.
What do you think about this?
> Hello, I don't have enough time for now but made some
> considerations on
As a followup, I spoke to an IETF friend who's used and implemented both
SRP and SCRAM. He agrees that SRP is cryptographically solid, that it's
significantly more difficult to implement (and therefore has a bit of a
monoculture risk overall, though of course that wouldn't apply to us if
we were to
On 17 March 2015 at 23:25, Peter Geoghegan wrote:
>> Possibly I'm missing something though.
>
> I think that you may have. Did you read the commit message/docs of the
> RLS commit 0004-*? You must consider the second point here, I believe:
>
>
> The 3 places that RLS policies are enforced are
2015-03-18 3:45 GMT+01:00 Jim Nasby :
> On 3/17/15 8:06 PM, Alvaro Herrera wrote:
>
>> My main question regarding this patch is whether the behavior with MD
>> arrays is useful at all. Suppose I give it this:
>>
>> alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}',
>> 3);
On 3/18/15 12:27 PM, Pavel Stehule wrote:
On 3/17/15 8:06 PM, Alvaro Herrera wrote:
My main question regarding this patch is whether the behavior with MD
arrays is useful at all. Suppose I give it this:
alvherre=# select array_offset('{{{1,2},{3,4},{5,6}},{{2,3},{4,5},{6,7}}}',
3);
array_o
2015-03-18 12:41 GMT+01:00 Marko Tiikkaja :
> On 3/18/15 12:27 PM, Pavel Stehule wrote:
>
>> On 3/17/15 8:06 PM, Alvaro Herrera wrote:
>>>
>>> My main question regarding this patch is whether the behavior with MD
arrays is useful at all. Suppose I give it this:
alvherre=# select a
On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai wrote:
> So, overall consensus for the FDW hook location is just before the
> set_chepest()
> at standard_join_search() and merge_clump(), isn't it?
Yes, I think so.
> Let me make a design of FDW hook to reduce code duplications for each FDW
> dri
A few days ago I posted a question on general concerning the new feature
SKIP LOCKED in PostgreSQL 9.5-dev.
For the orginal question can be found here:
http://www.postgresql.org/message-id/54f723c3.1020...@boerngen-schmidt.de
What I'm trying to archieve is to match a point from my data which
On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane wrote:
This would have one significant drawback, which is that planning for
large inheritance trees (many children) would probably get noticeably
slower. (But in the common case that constraint exclusion limits a
query to scanning jus
Jeevan Chalke writes:
> I am more concerned about this:
> 1.
> postgres=# create or replace function
> f1(a abc.test.id%type) returns int as
> $$ select 1; $$
> language sql;
> ERROR: schema "abc" does not exist
> Is that expected?
Yes, or at least, if it's not what we want it's not this patch
> On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai wrote:
> > So, overall consensus for the FDW hook location is just before the
> > set_chepest()
> > at standard_join_search() and merge_clump(), isn't it?
>
> Yes, I think so.
>
> > Let me make a design of FDW hook to reduce code duplications for
=?UTF-8?B?QmVuamFtaW4gQsO2cm5nZW4tU2NobWlkdA==?=
writes:
> The Lateral statement does return a result, which I do not expect. I
> returns an end point multiple times for diverent start points. Why? I
> thought, that the selected point by the lateral is locked by the FOR
> UPDATE and if the lat
Robert Haas writes:
> On Tue, Mar 17, 2015 at 11:26 AM, Tom Lane wrote:
>> Also, you're ignoring the prospect of getting better estimates and hence
>> better plans through having stats that dynamically adapt to the set of
>> partitions being scanned. Given the lousy state of maintenance of
>> wh
On 9 February 2015 at 20:52, Thom Brown wrote:
> Hi all,
>
> Google Summer of Code 2015 is approaching. I'm intending on registering
> PostgreSQL again this year.
>
> Before I do that, I'd like to have an idea of how many people are interested
> in being either a student or a mentor.
>
> I've vol
On Wed, Mar 18, 2015 at 2:22 AM, Amit Kapila wrote:
>> Can you try this:
>>
>> diff --git a/src/backend/postmaster/bgworker.c
>> b/src/backend/postmaster/bgworker.c
>> index f80141a..39b919f 100644
>> --- a/src/backend/postmaster/bgworker.c
>> +++ b/src/backend/postmaster/bgworker.c
>> @@ -244,6 +
I believe there's been a behavior change, and not sure if it's deliberate. I
don't think there's a negative consequence for our production use, but it
confused me while summing relpages for analysis purposes, as our 9.4 customers
behaved differently.
Documentation indicates that in pg9.0, ANALYZE
On Wed, Mar 18, 2015 at 9:33 AM, Kouhei Kaigai wrote:
>> On Wed, Mar 18, 2015 at 2:34 AM, Kouhei Kaigai wrote:
>> > So, overall consensus for the FDW hook location is just before the
>> > set_chepest()
>> > at standard_join_search() and merge_clump(), isn't it?
>>
>> Yes, I think so.
>>
>> > Let
Justin Pryzby writes:
> I believe there's been a behavior change, and not sure if it's deliberate. I
> don't think there's a negative consequence for our production use, but it
> confused me while summing relpages for analysis purposes, as our 9.4 customers
> behaved differently.
I don't see any
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
This is a midway review, a later will complete it.
The patch ap
On Tue, Mar 17, 2015 at 3:11 PM, Heikki Linnakangas wrote:
> I've been thinking that it would be nice to be able to specify a constraint
> name. Naming an index directly feels wrong, as in relational and SQL
> philosophy, indexes are just an implementation detail, but naming a
> constraint is a fa
On Tue, Mar 17, 2015 at 6:27 PM, Peter Geoghegan wrote:
> On Tue, Mar 17, 2015 at 12:11 PM, Heikki Linnakangas wrote:
>> I'm still not sure the way the speculative locking works is the best
>> approach. Instead of clearing xmin on super-deletion, a new flag on the heap
>> tuple seems more straigh
On Tue, Mar 17, 2015 at 1:24 PM, Alvaro Herrera
wrote:
> If we ever implement something like
>
> COMMENT ON CURRENT_DATABASE IS ...
>
> it will be useful, because you will be able to restore a dump into
> another database and have the comment apply to the target database.
> (Also, I wonder about
>
>
> I think someone already mentioned it, but it would be very neat if the
> optimizer could be pluggable. Then many different algorithms could be
> evaluated more easily.
Does it mean just to make the join order optimizer pluggable? If yes then
it is already pluggable as an extension. Is this th
Benjamin Börngen-Schmidt wrote:
> The Lateral statement does return a result, which I do not expect. I returns
> an end point multiple times for diverent start points. Why? I thought, that
> the selected point by the lateral is locked by the FOR UPDATE and if the
> lateral selects a point that is
Jeevan Chalke wrote:
> Álvaro,
>
> I think, there are few open questions here and thus marking it back to
> "Waiting on Author".
>
> Please have your views on the review comments already posted.
For some reason I missed your previous email.
> Also make changes as Tom suggested about placing ps
Abhijit Menon-Sen wrote:
> P.S. I don't know why the SRP code was removed from LibreSSL; nor am I
> sure how seriously to take that. It's possible that it's only because
> it's (still) rather obscure.
As I recall, the working principle of the LibreSSL guys is to remove
everything that can't be un
On Wed, Mar 18, 2015 at 12:11:22PM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > I believe there's been a behavior change, and not sure if it's deliberate.
> > I
> > don't think there's a negative consequence for our production use, but it
> > confused me while summing relpages for analysis
Grzegorz Parka writes:
> I'm thinking of testing and improving SAIO as an extension before reaching
> a satisfactory quality of code and returned plans.
> Would then the destination be the /contrib and then main source tree or
> would it ever stay as an extension?
I'd like to push it into the ma
Robert Haas writes:
> On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
>> Basically, the same rules apply to all commitfests, i.e. a committer can
>> apply anything during that period. I think the only restriction for the
>> last commitfest is that the committer can not apply a new patch th
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
> As a followup, I spoke to an IETF friend who's used and implemented both
> SRP and SCRAM. He agrees that SRP is cryptographically solid, that it's
> significantly more difficult to implement (and therefore has a bit of a
> monoculture risk overall
On Sat, Mar 14, 2015 at 1:04 AM, Amit Kapila wrote:
>> # EXPLAIN SELECT DISTINCT bid FROM pgbench_accounts;
>> ERROR: too many dynamic shared memory segments
>
> This happens because we have maximum limit on the number of
> dynamic shared memory segments in the system.
>
> In function dsm_postmas
On Wed, Mar 18, 2015 at 1:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 17, 2015 at 8:01 PM, Bruce Momjian wrote:
>>> Basically, the same rules apply to all commitfests, i.e. a committer can
>>> apply anything during that period. I think the only restriction for the
>>> last commi
On Wed, Mar 18, 2015 at 1:24 PM, Robert Haas wrote:
>
> On Tue, Mar 17, 2015 at 1:24 PM, Alvaro Herrera
> wrote:
> > If we ever implement something like
> >
> > COMMENT ON CURRENT_DATABASE IS ...
> >
> > it will be useful, because you will be able to restore a dump into
> > another database and h
On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
wrote:
>> > If we ever implement something like
>> >
>> > COMMENT ON CURRENT_DATABASE IS ...
>> >
>> > it will be useful, because you will be able to restore a dump into
>> > another database and have the comment apply to the target database
On 2015-03-18 13:12:11 -0400, Tom Lane wrote:
> Indeed. In this case, since the patch in question is one that
> improves/simplifies a patch that's already in the current commitfest,
> I'm going to go ahead and push it. If you want to call a vote on
> revoking my commit bit, go right ahead.
Serio
On Wed, Mar 18, 2015 at 10:26 AM, Andres Freund wrote:
> On 2015-03-18 13:12:11 -0400, Tom Lane wrote:
>> Indeed. In this case, since the patch in question is one that
>> improves/simplifies a patch that's already in the current commitfest,
>> I'm going to go ahead and push it. If you want to ca
On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas wrote:
>
> On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
> wrote:
> >> > If we ever implement something like
> >> >
> >> > COMMENT ON CURRENT_DATABASE IS ...
> >> >
> >> > it will be useful, because you will be able to restore a dump into
>
Michael Paquier wrote:
> I had a look at your modified version, and it looks good to me.
Thanks, pushed. (Without the va_cols change proposed downthread.)
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Se
Andres Freund writes:
> Seriously? In my opinion it has to be possible to doubt whether a patch
> should be committed in certain release without it being interpreted as a
> personal attack.
I don't think anyone's said anything in this thread that amounts to a
personal attack. We have a differenc
Jeevan,
Thanks for the review.
Jeevan Chalke wrote:
> I think, there are few open questions here and thus marking it back to
> "Waiting on Author".
>
> Please have your views on the review comments already posted.
> Also make changes as Tom suggested about placing pstate at the beginning.
Pus
On Wed, Mar 18, 2015 at 2:42 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
>
> On Wed, Mar 18, 2015 at 2:24 PM, Robert Haas
wrote:
> >
> > On Wed, Mar 18, 2015 at 1:23 PM, Fabrízio de Royes Mello
> > wrote:
> > >> > If we ever implement something like
> > >> >
> > >> > COMMENT
On Wed, Mar 18, 2015 at 2:01 PM, Tom Lane wrote:
> Andres Freund writes:
>> Seriously? In my opinion it has to be possible to doubt whether a patch
>> should be committed in certain release without it being interpreted as a
>> personal attack.
>
> I don't think anyone's said anything in this thre
On Wed, Mar 18, 2015 at 2:09 PM, Fabrízio de Royes Mello
wrote:
> Just one last doubt. Do we expose a new function called "current_database"
> like "current_catalog", "current_user", ... ?
Why would we do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL C
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> Just one last doubt. Do we expose a new function called "current_database"
> like "current_catalog", "current_user", ... ?
There already is one. But that would have nothing to do with the proposed
patch anyway, because the bits of syntax in ques
Michael Paquier wrote:
> On Wed, Mar 18, 2015 at 3:13 AM, Alvaro Herrera
> wrote:
> > I mean, can't we just do the "push" unconditionally here?
>
> Why should we install unnecessary stuff? This complicates the
> installation contents, the point being to have only shared libraries's
> dll install
On 2015-03-18 14:01:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Seriously? In my opinion it has to be possible to doubt whether a patch
> > should be committed in certain release without it being interpreted as a
> > personal attack.
>
> I don't think anyone's said anything in this thre
On Wed, Mar 18, 2015 at 3:13 PM, Robert Haas wrote:
>
> On Wed, Mar 18, 2015 at 2:09 PM, Fabrízio de Royes Mello
> wrote:
> > Just one last doubt. Do we expose a new function called
"current_database"
> > like "current_catalog", "current_user", ... ?
>
> Why would we do that?
>
We don't need it.
On 03/18/2015 06:23 PM, Robert Haas wrote:
On Tue, Mar 17, 2015 at 6:27 PM, Peter Geoghegan wrote:
On Tue, Mar 17, 2015 at 12:11 PM, Heikki Linnakangas wrote:
I'm still not sure the way the speculative locking works is the best
approach. Instead of clearing xmin on super-deletion, a new flag
On Wed, Mar 18, 2015 at 3:13 PM, Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > Just one last doubt. Do we expose a new function called
"current_database"
> > like "current_catalog", "current_user", ... ?
>
> There already is one. But that would have nothing to do with
On 03/17/2015 09:00 AM, Julien Tachoires wrote:
Here is a new version fixing this issue. I've added a new kind of TOC
entry for being able to handle pg_restore --no-tablespace case.
Looks good but I think one minor improvement could be to set the table
space of the toast entires to the same as
Pavel Stehule wrote:
> 2015-03-18 12:41 GMT+01:00 Marko Tiikkaja :
> >> I am thinking, so this behave is correct (there is no other
> >> possible), but it is only corner case for this functionality - and
> >> if you are thinking, so better to disallow it, I am not against. My
> >> main focus is 1N
On Wed, Mar 18, 2015 at 11:41 AM, Heikki Linnakangas wrote:
> AFAICS, there is no need to go and clear the tag after the insert has
> completed.
>
> Here's what I had in mind: the inserter tags the tuple with the speculative
> insertion token, by storing the token in the t_ctid field. If the inser
On Fri, Mar 6, 2015 at 12:19:36PM -0500, Bruce Momjian wrote:
> On Fri, Mar 6, 2015 at 10:50:27AM +0300, Vladimir Borodin wrote:
> > What I have done is to update the pg_upgrade instructions to add this
> > required step. Updated doc patch attached. (I also added the --delete
> > fl
On Wed, Mar 18, 2015 at 9:19 AM, Robert Haas wrote:
> On Tue, Mar 17, 2015 at 3:11 PM, Heikki Linnakangas wrote:
>> I've been thinking that it would be nice to be able to specify a constraint
>> name. Naming an index directly feels wrong, as in relational and SQL
>> philosophy, indexes are just a
Hello devs,
As stated earlier I was thinking to propose the integration of Postgres and
CUDA for faster execution of order by queries thru optimizing the sorting code
and sorting it with CUDA. I saw and tried to run PG Strom and ran into issues.
Moreover, PG Strom is implemented in OpenCL, not C
On Wed, Mar 18, 2015 at 1:05 AM, Andres Freund wrote:
> I think it's a pretty direct copy of the 64bit code. I'm not entirely
> sure why this needs a AC_TRY_RUN with a compile fallback (for cross) and
> why a AC_TRY_LINK isn't sufficient? But then, you just copied that
> decision.
Good point.
An
Hi,
Reading the README first, the rest later. So you can comment on my
comments, while I actually look at the code. Parallelism, yay!
On 2015-03-18 12:02:07 -0400, Robert Haas wrote:
> +Instead, we take a more pragmatic approach: we try to make as many of the
> +operations that are safe outside o
In September, while researching the to_char() buffer overflow bugs fixed
in 9.4.1 (commit 0150ab567bcf5e5913e2b62a1678f84cc272441f), I found an
inconsistency in how to_char() does zero-padding for float4/8 values.
Now that 9.4.1 is released and I am home for a while, I am ready to
address this.
F
On 2015-03-18 14:00:51 -0700, Peter Geoghegan wrote:
> Anyway, I think that it's not quite the same. For one thing, we're
> talking about a GCC extension, not a type described by C99. We don't
> care about snprintf support, for example.
I don't see that that has any consequence wrt Andreas' test.
On Wed, Mar 18, 2015 at 3:16 PM, Andres Freund wrote:
>> For another, Andreas has chosen to lump together __int128 and unsigned
>> __int128 into one test, where the latter really doesn't receive
>> coverage.
>
> On my urging actually. It's pretty darn unlikely that only one variant
> will work.
I
On 2015-03-18 15:59:52 -0700, Peter Geoghegan wrote:
> Okay. Attached revision has a few tweaks that reflect the status of
> int128/uint128 as specialized types that are basically only useful for
> this optimization, or other similar optimizations on compilers that
> either are GCC, or aim to be co
On 2015-03-18 12:02:07 -0400, Robert Haas wrote:
> diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> index cb6f8a3..173f0ba 100644
> --- a/src/backend/access/heap/heapam.c
> +++ b/src/backend/access/heap/heapam.c
> @@ -2234,6 +2234,17 @@ static HeapTuple
> heap_
On Wed, Mar 18, 2015 at 4:07 PM, Andres Freund wrote:
> Given that we don't rely on C99, I don't think that actually
> matters. Lots of our platforms build on pre C99 compilers... I think it
> makes sense to say that this currently only tests for a gcc extension
> and might be extended in the futu
On 03/18/2015 11:59 PM, Peter Geoghegan wrote:
Okay. Attached revision has a few tweaks that reflect the status of
int128/uint128 as specialized types that are basically only useful for
this optimization, or other similar optimizations on compilers that
either are GCC, or aim to be compatible wit
On Thu, Mar 19, 2015 at 2:44 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> I had a look at your modified version, and it looks good to me.
>
> Thanks, pushed. (Without the va_cols change proposed downthread.)
Thanks a lot! I will shortly work on the rebase for the other patch.
--
Mich
On Thu, Mar 19, 2015 at 3:30 AM, Alvaro Herrera wrote:
> Makes sense.
>
> I have pushed your patch; we'll see what the buildfarm thinks of it.
Thanks.
> (Sadly, the number of MSVC members is rather small and they don't run
> often.)
Once Windows 10 is out, it could be installed on a Raspberry PI
On Sat, Mar 14, 2015 at 4:07 PM, Simon Riggs wrote:
> -1 for a time based setting.
>
> After years of consideration, bloat is now controllable by altering
> the size of the undo tablespace.
>
Hm. Well, fwiw the situation is rather more complicated than that. You're
correct that you can create a
On Wed, Sep 10, 2014 at 08:10:45PM -0400, Bruce Momjian wrote:
> On Tue, Jun 10, 2014 at 10:30:24AM -0400, Robert Haas wrote:
> > On Tue, Jun 10, 2014 at 10:18 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > >> I don't agree with this analysis. If the connection is closed after
> > >> the clie
On Wed, Mar 18, 2015 at 10:45 PM, Robert Haas wrote:
>
> On Sat, Mar 14, 2015 at 1:04 AM, Amit Kapila
wrote:
> >> # EXPLAIN SELECT DISTINCT bid FROM pgbench_accounts;
> >> ERROR: too many dynamic shared memory segments
> >
> > This happens because we have maximum limit on the number of
> > dynam
The error code is used in two places:
ereport(ERROR,
(errcode(ERRCODE_T_R_DEADLOCK_DETECTED),
errmsg("canceling statement due to conflict with
recovery"),
errdetail("User transaction caused buffer deadlock with
recovery.")));
Hi,
Background info first: PL/Ruby was originally maintained by Guy Decoux,
who passed away in 2008: https://www.ruby-forum.com/topic/166658 . After
his death, Akinori MUSHA forked the project and maintained it until
2010: https://github.com/knu/postgresql-plruby . Last release was on Jan
2010, a
On Fri, Mar 6, 2015 at 1:07 PM, Michael Paquier
wrote:
> On Fri, Mar 6, 2015 at 12:44 PM, Fujii Masao wrote:
>> On Thu, Mar 5, 2015 at 9:49 PM, Michael Paquier
>> wrote:
>>> On Thu, Mar 5, 2015 at 7:10 PM, Fujii Masao wrote:
With the patch, VACUUM ANALYZE VERBOSE doesn't emit any verbose me
On Thu, Mar 19, 2015 at 12:23 PM, Fujii Masao wrote:
> Are you planning to update the patch so that it's based on the commit 0d83138?
Yes... Very soon.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Wed, Mar 18, 2015 at 9:14 PM, Robert Haas wrote:
>
> On Wed, Mar 18, 2015 at 2:22 AM, Amit Kapila
wrote:
> >
> > It didn't fix the problem. IIUC, you have done this to ensure that
> > if worker is not already started, then update it's pid, so that we
> > can get the required status in WaitFor
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> One thing that Stephen commented on was the ALTER TABLE preparatory
> patch. He said why not return ObjectAddress from the subcommand
> routines instead of just Oid/attnum? The reason is that to interpret
> the address correctly you will still
77 matches
Mail list logo
