On Wed, Dec 07, 2016 at 03:16:09PM +0530, Ashutosh Sharma wrote:
> Problem Analysis:
> -
> Allthough i am very new to Windows, i tried debugging the issue and
> could find that Backend is not receiving the query executed after
> "SELECT pldbg_attach_to_port(2)" and is
On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote:
> On 12/08/2016 10:18 AM, Michael Paquier wrote:
>> Hmmm. How do we handle the case where the user name does not match
>> then? The spec gives an error message e= specifically for this case.
>
> Hmm, interesting. I wonder
On 2016/12/07 20:23, Etsuro Fujita wrote:
On 2016/12/07 15:39, Ashutosh Bapat wrote:
On 2016/11/22 18:28, Ashutosh Bapat wrote:
I guess, the reason why you are doing it this way, is SELECT clause for
the
outermost query gets deparsed before FROM clause. For later we call
2016-12-08 16:11 GMT+09:00 Craig Ringer :
> On 8 December 2016 at 12:01, Kohei KaiGai wrote:
>
>>> At a higher level, I don't understand exactly where such giant
>>> ExpandedObjects would come from. (As you point out, there's certainly
>>> no easy way
On 12/7/16 9:38 AM, Tom Lane wrote:
>> Even with that change, dynamic shared memory is still vulnerable to be
>> removed.
> Really? I thought we concluded that it is safe because it is detectably
> attached to running processes.
The DSM implementation uses POSIX shared memory, which doesn't have
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I have a vague feeling that the code for dumping casts and/or transforms
>> may have some assumptions that the underlying function is also being
>> dumped. Although maybe the assumption was really only what's
On 2016/12/07 21:11, Ashutosh Bapat wrote:
On Wed, Dec 7, 2016 at 4:51 PM, Etsuro Fujita
wrote:
On 2016/12/05 20:20, Ashutosh Bapat wrote:
3. Why is foreignrel variable changed to rel?
-extern void deparseSelectStmtForRel(StringInfo buf, PlannerInfo *root,
-
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> In HEAD, we could change the RTE data structure so that
> >> transformValuesClause could save the typmod information in the RTE,
> >> keeping the lookups cheap.
>
> > Hmm, I think this would be useful for
On 12/7/16 9:28 PM, Alex Hunsaker wrote:
> Hrm, the following incantation seems to break for me on a fresh Fedora
> 25 system:
> 1) As root su to $USER and start postgres.
> 2) ssh in as $USER and then logout
> 3) # psql localhost
>
> FATAL: semctl(4980742, 3, SETVAL, 0) failed: Invalid argument
2016-12-08 14:03 GMT+01:00 Alvaro Herrera :
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Tom Lane wrote:
> > >> In HEAD, we could change the RTE data structure so that
> > >> transformValuesClause could save the typmod information in the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > As pointed out by Peter E, this also impacts CASTs. Attached is a patch
> > which addresses both by simply also pulling any functions which are
> > referenced from pg_cast or pg_transform when they have OIDs
Hi!
We are now accepting talk proposals for PgConf.Russia 2017.
The Russian PostgreSQL conference will take place on 15-17 March 2017 in
Moscow, at the Digital October venue, same as for PgConf.Russia 2015. The
audience include a wide range of application and system developers,
database
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> Hmm, I had mixed feeling about what to do about that as well. So now, we
> have the description of various new features buried into VI. Reference
> section of the documentation, which is simply meant as a command
> reference. I agree
On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote:
> Attached those here, as add-on patches to your latest patch set.
Thanks for looking at it!
> I'll continue reviewing, but a couple of things caught my eye that you may
> want
> to jump on, in the meanwhile:
>
> On
Hi!
(Copying this one to -hackers as well, for git coverage)
We were just notified by one of our hosting providers, MeetMe, that they
are about to start physically moving two of our servers to a different
datacenter. Unfortunately, we were only given about an hours warning on
this, so we have
On 12/08/2016 10:18 AM, Michael Paquier wrote:
On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote:
Attached those here, as add-on patches to your latest patch set.
Thanks for looking at it!
I'll continue reviewing, but a couple of things caught my eye that you may
On Thu, Dec 8, 2016 at 4:39 PM, Michael Paquier
wrote:
> On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas wrote:
>> You could do that, but first I would code up the simplest, cleanest
>> algorithm you can think of and see if it even shows up in a
On Thu, Dec 8, 2016 at 9:49 AM, Magnus Hagander wrote:
> Hi!
>
> (Copying this one to -hackers as well, for git coverage)
>
> We were just notified by one of our hosting providers, MeetMe, that they
> are about to start physically moving two of our servers to a different
>
Dear PostgreSQL Hackers,
I am working in PostgreSQL 9.4.* optimizer module. In costsize.c file and
final_cost_hashjoin() function, the innerbucketsize is either:
a) calculated using a cached copy
OR
b) calculated afresh using statistics
On 2016/12/08 3:20, Robert Haas wrote:
> On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote:
>>> My bad. The fix I sent last night for one of the cache flush issues
>>> wasn't quite right. The attached seems to fix it.
>> Yes, fixed here too. Thanks.
>
> Thanks for the report
On 12/08/2016 05:51 PM, Christoph Berg wrote:
Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi>
Committed this patch now.
Hi,
I've just taken up work again on PG 10 on Debian unstable.
With openssl 1.1.0c-2, pgcrypto errors out with:
Yeah, sorry about that.
On 8 December 2016 at 15:54, Aleksander Alekseev
wrote:
> Hi.
>
> I noticed that there is a lot of repeating code like this:
>
> ```
> if (strspn(str, " \t\n\r\f") == strlen(str))
> ```
>
> I personally don't find it particularly readable, not mentioning that
>
Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi>
> Committed this patch now.
Hi,
I've just taken up work again on PG 10 on Debian unstable.
With openssl 1.1.0c-2, pgcrypto errors out with:
gcc -Wall -Wmissing-prototypes -Wpointer-arith
On Thu, Dec 8, 2016 at 11:13 AM, Dmitry Ivanov wrote:
> We (PostgresPro) have been working on pg_pathman for quite a while, and
> since it's obviously going to become the thing of the past, it would be a
> wasted effort if we didn't try to participate.
>
> For starters,
Aleksander Alekseev writes:
> How about rewriting such a code like this?
> if (pg_str_containsonly(str, " \t\n\r\f"))
Function name seems weirdly spelled. Also, I believe that in nearly all
use-cases the number of data characters that would typically be examined
is
Hi everyone,
Of course, this is the beginning, not the end. I've been thinking
about next steps -- here's an expanded list:
- more efficient plan-time partition pruning (constraint
exclusion is too slow)
- run-time partition pruning
- try to reduce lock levels
...
We (PostgresPro) have
On Wed, Dec 7, 2016 at 11:42 PM, Michael Paquier
wrote:
>> Congrats to everyone working on this! This is a large step forward.
>
> Congratulations to all! It was a long way to this result.
Yes. The last effort in this area which I can remember was by Itagaki
Takahiro
Hi.
I noticed that there is a lot of repeating code like this:
```
if (strspn(str, " \t\n\r\f") == strlen(str))
```
I personally don't find it particularly readable, not mentioning that
traversing a string twice doesn't look as a good idea (you can check
using objdump that latest GCC 6.2
That would be fantastic. I and my colleagues at EnterpriseDB can
surely help review; of course, maybe you and some of your colleagues
would like to help review our patches, too.
Certainly, I'll start reviewing as soon as I get familiar with the code.
Do you think this is
likely to be
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
> >> dumped.
It make sense. I would like to share more comments as following i.e.
static int
> bf_check_supported_key_len(void)
> {
> ...
> /* encrypt with 448bits key and verify output */
> evp_ctx = EVP_CIPHER_CTX_new();
> if (!evp_ctx)
> return 1;
> if
On Thu, Dec 8, 2016 at 7:29 PM, Robert Haas wrote:
> On Thu, Dec 8, 2016 at 11:13 AM, Dmitry Ivanov
> wrote:
> > We (PostgresPro) have been working on pg_pathman for quite a while, and
> > since it's obviously going to become the thing of the
I have a setup where a 9.6.1 server uses postgres_fdw to connect to a 9.4.9
hot standby server.
I have a DML statement which triggers the error:
ERROR: XX000: outer pathkeys do not match mergeclauses
LOCATION: create_mergejoin_plan, createplan.c:3722
The error first starts appearing with this
On Wed, Dec 7, 2016 at 11:02 PM, Karl O. Pinc wrote:
> I read this and knew that I hadn't finished review, but didn't
> immediately respond because I thought the patch had to be
> marked "ready for committer" on commitfest.postgresql.org
> before the committers would spend a lot of
On Thu, Dec 8, 2016 at 11:44 AM, Dmitry Ivanov wrote:
>> That would be fantastic. I and my colleagues at EnterpriseDB can
>> surely help review; of course, maybe you and some of your colleagues
>> would like to help review our patches, too.
>
> Certainly, I'll start
On Thu, Dec 8, 2016 at 11:43 AM, Alexander Korotkov
wrote:
> Great! And it is very cool that we have basic infrastructure already
> committed. Thanks a lot to you and everybody involved.
Thanks.
>> of course, maybe you and some of your colleagues
>> would like to
Robert Haas writes:
> Maybe it would help for Jeff to use elog_node_display() to the nodes
> that are causing the problem - e.g. outerpathkeys and innerpathkeys
> and best_path->path_mergeclauses, or just best_path - at the point
> where the error is thrown. That might give
Well, we are currently passing INFINITE timeout value to
WaitForMultipleObjects() API which is hanging. I thought of changing this
INIFINTE timeout interval to some finite value like say 1 sec and could not
reproduce the issue. But, having said that i checked the older code where
this issue does
On Thu, Dec 8, 2016 at 12:40 PM, Tom Lane wrote:
> Ah-hah, thanks for the insight. I can now reproduce it, and I confirm
> that aside from removing the semaphores, our POSIX shmem segment(s)
> are removed from /dev/shm. They presumably still are attached to whatever
>
On 12/6/16 11:58 AM, Peter Eisentraut wrote:
> On 12/5/16 6:24 PM, Petr Jelinek wrote:
>> I think that the removal of changes to ReplicationSlotAcquire() that you
>> did will result in making it impossible to reacquire temporary slot once
>> you switched to different one in the session as the if
Tom, Geoff,
Thanks for your feedback! Here is version 2 of this patch.
> You could just change it to
> if (str[strspn(str, " \t\n\r\f")] == '\0')
> to mitigate calling strlen. It's safe to do so because strspn will
> only return values from 0 to strlen(str).
> [...] I have serious doubts that
* Robert Haas (rh...@postgresql.org) wrote:
> Implement table partitioning.
My compiler apparently doesn't care for this:
.../src/backend/catalog/partition.c: In function ‘partition_rbound_cmp’:
.../src/backend/catalog/partition.c:1787:13: warning: ‘cmpval’ may be used
uninitialized in this
Jeff Janes writes:
> I have a DML statement which triggers the error:
> ERROR: XX000: outer pathkeys do not match mergeclauses
> LOCATION: create_mergejoin_plan, createplan.c:3722
Hmm.
> Any tips on investigating this further in situ? Or is the best option just
> to
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 8, 2016 at 1:49 PM, Stephen Frost wrote:
> > * Robert Haas (rh...@postgresql.org) wrote:
> >> Implement table partitioning.
> >
> > My compiler apparently doesn't care for this:
> >
> >
On Thu, Dec 8, 2016 at 12:50 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I have a DML statement which triggers the error:
>> ERROR: XX000: outer pathkeys do not match mergeclauses
>> LOCATION: create_mergejoin_plan, createplan.c:3722
>
> Hmm.
>
>> Any
Peter Eisentraut writes:
> On 12/7/16 9:28 PM, Alex Hunsaker wrote:
>> Hrm, the following incantation seems to break for me on a fresh Fedora
>> 25 system:
>> 1) As root su to $USER and start postgres.
>> 2) ssh in as $USER and then logout
>> 3) # psql localhost
On Thu, Dec 8, 2016 at 1:49 PM, Stephen Frost wrote:
> * Robert Haas (rh...@postgresql.org) wrote:
>> Implement table partitioning.
>
> My compiler apparently doesn't care for this:
>
> .../src/backend/catalog/partition.c: In function ‘partition_rbound_cmp’:
>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 8, 2016 at 2:11 PM, Stephen Frost wrote:
> > Yes, that makes the compiler warning go away.
>
> Great, pushed.
Awesome, thanks!
> > ... your compiler knows that key->partnatts will always be >= 1?
>
> :-)
>
> I
Stephen Frost writes:
> Ok, thinking a bit more on this and testing, it looks like we record the
> initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3.
> Therefore, we could use that as the gating factor for getFuncs() instead
> of FirstNormalObjectId and
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Ok, thinking a bit more on this and testing, it looks like we record the
> > initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3.
> > Therefore, we could use that as the gating factor
On Thu, Dec 8, 2016 at 2:11 PM, Stephen Frost wrote:
> Yes, that makes the compiler warning go away.
Great, pushed.
> ... your compiler knows that key->partnatts will always be >= 1?
:-)
I think my compiler is too dumb to notice that int x; printf("%d", x);
is a reference
On Wed, Dec 7, 2016 at 9:23 PM, Amit Kapila wrote:
> Attached patch changes the comment based on above suggestions.
Thanks. Committed and back-patched to 9.6.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas wrote:
> Should we be worried about breaking the API of tuplesort_get* functions?
> They might be used by extensions. I think that's OK, but wanted to bring it
> up. This would be only for master, of course, and any breakage
Peter Geoghegan writes:
> On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas wrote:
>> Should we be worried about breaking the API of tuplesort_get* functions?
>> They might be used by extensions. I think that's OK, but wanted to bring it
>> up. This would be
On Thu, 8 Dec 2016 11:27:34 -0500
Robert Haas wrote:
> On Wed, Dec 7, 2016 at 11:02 PM, Karl O. Pinc wrote:
> > I read this and knew that I hadn't finished review, but didn't
> > immediately respond because I thought the patch had to be
> > marked "ready
Hi,
I'm wondering if it's not time for $subject:
- V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
forgotten
- They have us keep weird hacks around just for the sake of testing V0
- they actually cost performance, because we have to zero initialize Datums,
even if
the
On 12/04/2016 07:21 PM, Michael Paquier wrote:
> On Mon, Dec 5, 2016 at 11:34 AM, Haribabu Kommi
> wrote:
>> As there was a feedback from others related to the patch and doesn't find
>> any
>> update from author.
>>
>> Closed in 2016-11 commitfest with "returned with
On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier
wrote:
> OK, I rewrote a bit the patch as attached. What do you think?
Committed and back-patched all the way back to 9.2.
>> Right (I think). If we set and clear delayChkpt around this work, we
>> don't need the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> I have a vague feeling that the code for dumping casts and/or transforms
> >> may have some assumptions that the underlying function is also being
> >> dumped.
I've pushed the previous patch to HEAD. Attached is a proposed patch
(against 9.6) that we could use for the back branches; it takes the
brute force approach of just computing the correct value on-demand
in the two functions at issue. The key question of course is whether
this is acceptable from
On 08/12/16 20:16, Peter Eisentraut wrote:
> On 12/6/16 11:58 AM, Peter Eisentraut wrote:
>> On 12/5/16 6:24 PM, Petr Jelinek wrote:
>>> I think that the removal of changes to ReplicationSlotAcquire() that you
>>> did will result in making it impossible to reacquire temporary slot once
>>> you
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> (Actually, the most likely way in which this would break things is if
>> it started causing built-in casts to get dumped ... have you checked?)
> So, this is fun. Apparently casts had OIDs >
Stephen Frost writes:
> That's a good point, we might be doing things wrong in other places in
> the code by using FirstNormalObjectId on pre-8.1 servers.
> What I suggest then is an independent patch which uses a different
> variable than FirstNormalObjectId and sets it
Andres Freund writes:
> I'm wondering if it's not time for $subject:
> - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> forgotten
> - They have us keep weird hacks around just for the sake of testing V0
> - they actually cost performance, because we have
Andres Freund writes:
> On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
>> The habit of zero-initializing Datums has got exactly nothing to do with
>> V0 functions; it's about ensuring consistent results and avoiding
>> heisenbugs from use of uninitialized memory. I do not
On Mon, Aug 22, 2016 at 4:20 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-08-17 17:41:28 -0700, Andres Freund wrote:
>>> Tom, do you think this is roughly going in the right direction?
>
> I've not had time to look at this patch, I'm afraid. If
Andres, all,
* Andres Freund (and...@anarazel.de) wrote:
> I'm wondering if it's not time for $subject:
> - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> forgotten
> - They have us keep weird hacks around just for the sake of testing V0
> - they actually cost performance,
On Wed, Nov 23, 2016 at 3:33 AM, Andres Freund wrote:
> On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
>> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote:
>> > I've a working fix for this, and for a similar issue Robert found. I'm
>> > still playing
Robert Haas writes:
> Tom, it's been about 3.5 months since you wrote this. I think it
> would be really valuable if you could get to this RSN because the
> large patch set posted on the "Changed SRF in targetlist handling"
> thread is backed up behind this -- and I think
On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I'm wondering if it's not time for $subject:
> > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> > forgotten
> > - They have us keep weird hacks around just for the sake of testing
On 2016-12-08 18:03:04 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> >> The habit of zero-initializing Datums has got exactly nothing to do with
> >> V0 functions; it's about ensuring consistent results and avoiding
> >>
On Fri, Dec 9, 2016 at 3:02 PM, vinayak wrote:
> On 2016/12/05 14:42, Ashutosh Bapat wrote:
>>
>> On Mon, Dec 5, 2016 at 11:04 AM, Haribabu Kommi
>> wrote:
>>
>>
>> On Fri, Nov 11, 2016 at 5:38 PM, Masahiko Sawada
Hi,
I am testing the partitioning feature from the latest master and got the
following error while loading the data -
db01=# create table orders_y1993 PARTITION OF orders FOR VALUES FROM
('1993-01-01') TO ('1993-12-31');
CREATE TABLE
db01=# copy orders from '/data/orders-1993.csv' delimiter
Hello hackers,
I met SIGSEGV when using `array_position()` with record type
arguments, so I've written a patch which corrects this problem. It
seems that `array_position...()` sets wrong memory context for the
cached function (in this case `record_eq()`) which is used to find a
matching element.
On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier
wrote:
> This basically means that if the latch is set, we don't wait at all
> and drop the ball. I am wondering: isn't that a problem even if
> WL_LATCH_SET is *not* set? If I read this code correctly, even if
> caller
On 2016/12/05 14:42, Ashutosh Bapat wrote:
On Mon, Dec 5, 2016 at 11:04 AM, Haribabu Kommi
wrote:
On Fri, Nov 11, 2016 at 5:38 PM, Masahiko Sawada
wrote:
2PC is a basic building block to support the atomic commit and there
are some
On Fri, Dec 9, 2016 at 2:38 AM, Ashutosh Sharma wrote:
> Well, we are currently passing INFINITE timeout value to
> WaitForMultipleObjects() API which is hanging. I thought of changing this
> INIFINTE timeout interval to some finite value like say 1 sec and could not
>
On Fri, Dec 9, 2016 at 3:14 PM, Junseok Yang wrote:
> I met SIGSEGV when using `array_position()` with record type
> arguments, so I've written a patch which corrects this problem. It
> seems that `array_position...()` sets wrong memory context for the
> cached function (in
Josh Berkus writes:
> On 12/01/2016 05:58 PM, Magnus Hagander wrote:
>> And in fairness, having such a "guide to changes" chapter in each
>> release probably *would* be a good idea. But it would take resources to
>> make that. The release notes are good, but having a more
On 12/08/2016 04:16 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 12/01/2016 05:58 PM, Magnus Hagander wrote:
>>> And in fairness, having such a "guide to changes" chapter in each
>>> release probably *would* be a good idea. But it would take resources to
>>> make that. The
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alexander
> Korotkov
> Yes. Getting at least some of this features committed to v10 would be great
> and improve partitioning usability a lot.
I'm sorry for not contributing to the real
On 2016/12/09 10:09, Tsunakawa, Takayuki wrote:
> Another requirement was subpartitioning. Will this be possible with the
> current infrastructure, or does this need drastic change?
It does support sub-partitioning, although the syntax is a bit different.
Thanks,
Amit
--
Sent via
From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> On 2016/12/09 10:09, Tsunakawa, Takayuki wrote:
> > Another requirement was subpartitioning. Will this be possible with the
> current infrastructure, or does this need drastic change?
>
> It does support sub-partitioning, although the
On 12/01/2016 05:58 PM, Magnus Hagander wrote:
> >> * Add docs: "Guide to changes in recovery.conf in 10.0"
> >
> > Hmm, we don't usually write the docs in terms of how things are
> > different from a previous version. Might seem strange in 5 years.
> > Not sure what's best,
On Fri, Dec 9, 2016 at 9:34 AM, Josh Berkus wrote:
> On 12/08/2016 04:16 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> On 12/01/2016 05:58 PM, Magnus Hagander wrote:
And in fairness, having such a "guide to changes" chapter in each
release
On Fri, Dec 9, 2016 at 4:54 AM, Robert Haas wrote:
> On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier
> wrote:
>> OK, I rewrote a bit the patch as attached. What do you think?
>
> Committed and back-patched all the way back to 9.2.
Thanks!
>>>
On Fri, Dec 9, 2016 at 1:11 AM, Asif Naeem wrote:
> It make sense. I would like to share more comments as following i.e.
>
>> static int
>> bf_check_supported_key_len(void)
>> {
>> ...
>> /* encrypt with 448bits key and verify output */
>> evp_ctx =
Hi Stephen,
On 2016/12/08 22:35, Stephen Frost wrote:
>>> * The fact that there's no implementation of row movement should be
>>> documented as a limitation. We should also look at removing that
>>> limitation.
>>
>> Yes, something to improve. By the way, since we currently mention INSERT
>>
On Thu, Dec 8, 2016 at 10:05 PM, Michael Paquier
wrote:
> On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote:
>> On 12/08/2016 10:18 AM, Michael Paquier wrote:
>>> Hmmm. How do we handle the case where the user name does not match
>>> then? The
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> (Actually, the most likely way in which this would break things is if
> >> it started causing built-in casts to get dumped ... have you checked?)
>
> > So, this is
On 2016-12-08 14:53:58 -0800, Andres Freund wrote:
> On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> > The habit of zero-initializing Datums has got exactly nothing to do with
> > V0 functions; it's about ensuring consistent results and avoiding
> > heisenbugs from use of uninitialized memory. I
On 2016/12/09 0:25, Robert Haas wrote:
> On Wed, Dec 7, 2016 at 11:42 PM, Michael Paquier
> wrote:
>>> Congrats to everyone working on this! This is a large step forward.
>>
>> Congratulations to all! It was a long way to this result.
>
> Yes. The last effort in this
92 matches
Mail list logo