On Thu, Jan 28, 2016 at 10:10 PM, Masahiko Sawada wrote:
> By the discussions so far, I'm planning to have several replication
> methods such as 'quorum', 'complex' in the feature, and the each
> replication method specifies the syntax of s_s_names.
> It means that s_s_names could have the number o
On Sun, Jan 31, 2016 at 5:08 PM, Masahiko Sawada wrote:
> On Sun, Jan 31, 2016 at 1:17 PM, Michael Paquier
> wrote:
>> On Thu, Jan 28, 2016 at 10:10 PM, Masahiko Sawada wrote:
>>> By the discussions so far, I'm planning to have several replication
>>> methods
On Sun, Jan 31, 2016 at 5:28 PM, Masahiko Sawada wrote:
> On Sun, Jan 31, 2016 at 5:18 PM, Michael Paquier
> wrote:
>> On Sun, Jan 31, 2016 at 5:08 PM, Masahiko Sawada
>> wrote:
>>> On Sun, Jan 31, 2016 at 1:17 PM, Michael Paquier
>>> wrote:
>>>
On Sun, Jan 31, 2016 at 9:01 PM, Piotr Stefaniak
wrote:
> - result = sign * cosd_q1(arg1) / sind_q1(arg1);
> + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45);
>
> and
>
> - result = sign * sind_q1(arg1) / cosd_q1(arg1);
> + result = sign * ((sind_q1(arg1) / cosd_q1(arg1)) / tan_45);
>
On Sat, Jan 30, 2016 at 11:08 PM, Michael Paquier
wrote:
> On Fri, Jan 29, 2016 at 9:13 PM, Michael Paquier wrote:
>> Well, to put it short, I am just trying to find a way to make the
>> backend skip unnecessary checkpoints on an idle system, which results
>> in the fol
On Sun, Jan 31, 2016 at 7:55 AM, Michael Paquier
wrote:
> On Sun, Jan 31, 2016 at 5:32 AM, Craig Ringer wrote:
>> On 29 January 2016 at 22:41, Stephen Frost wrote:
>>>
>>> Michael,
>>>
>>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>
On Thu, Jan 21, 2016 at 1:08 PM, Michael Paquier
wrote:
> On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote:
>> The only things I know of still lacking is:
>> 1) Documentation
>> 2) Decision on REVOKE ... FROM PUBLIC
>
> Yep, regarding 2) I am the only one actually mak
On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote:
> On 01/29/2016 03:05 PM, Alvaro Herrera wrote:
>> Joshua D. Drake wrote:
>> One of the offers is to credit them (I'm not exactly clear
>> on what is the group to benefit from this, but the phrasing used in the
>> meeting was "contributors to t
On Thu, Jan 7, 2016 at 4:50 PM, Craig Ringer wrote:
> On 7 January 2016 at 01:17, Peter Eisentraut wrote:
>> On 12/22/15 4:55 AM, Craig Ringer wrote:
>> and we could probably go through them
>> one by one and ask, why do we need this bit? So that kind of system
>> will be very hard to review as
On Mon, Feb 1, 2016 at 8:13 AM, Vitaly Burovoy wrote:
> While I was searching for a function which checks doubles for
> infinity, I discovered a function "isinf" in a file src/port/isinf.c
> where one of three versions returns different value for "-inf" ("1"
> instead of "-1") comparing to the oth
On Mon, Feb 1, 2016 at 2:38 PM, Michael Paquier
wrote:
> Actually, is there actually a reason to keep this file in the code
> tree? Are there platforms that do not have isinf()? Even for Windows
> environments using MSVC < 1800 this is emulated using _fpclass.
Looking at what is in t
On Mon, Feb 1, 2016 at 1:21 PM, Fujii Masao wrote:
> On Fri, Jan 29, 2016 at 1:02 PM, Michael Paquier
> wrote:
>> On Fri, Jan 29, 2016 at 11:53 AM, Fujii Masao wrote:
>>> I removed the above and added the following for that case.
>>>
>>> +/* Com
On Fri, Jan 29, 2016 at 5:16 AM, Fabien COELHO <
fabien.coe...@mines-paristech.fr> wrote:
> v22 compared to previous:
Thanks for the new patch!
> - remove the short macros (although IMO it is a code degradation)
FWIW, I like this suggestion from Robert.
> - check for INT64_MIN / -1 (although
On Fri, Jan 29, 2016 at 11:28 PM, Fabien COELHO wrote:
> Here is a rebase of the 3 remaining parts:
> - 15-c: per script stats
> - 15-d: weighted scripts
> - 15-e: prefix selection for -b
Regarding patch d.
+ /* compute total_weight */
+ for (i = 0; i < num_scripts; i++)
+
On Mon, Feb 1, 2016 at 4:04 PM, Tom Lane wrote:
> 1. I don't think the buildfarm is sufficient evidence to conclude that
> isinf.c is required nowhere. It was in use as late as 2004, judging
> by the git history, and I don't know of good reason to assume we do not
> need it now.
>
This was 12 y
On Mon, Feb 1, 2016 at 6:13 PM, Alvaro Herrera
wrote:
> Joshua D. Drake wrote:
> > On 01/31/2016 04:34 PM, Michael Paquier wrote:
>
> > >This page would need a refresh IMO. I think it has not been touched
> > >for the last couple of years.
> >
> > No
On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund wrote:
> I personally, and I realize that I'm likely alone on that, would really
> like to see references to relevant threads. A year after a commit or
> such it often starts to get hard to know which threads a commit was
> about. Often it's easy enou
On Mon, Feb 1, 2016 at 9:15 PM, Fujii Masao wrote:
> If we do that, we also should change the tab-completion for SET command
> so that "=" is suggested. But I'm afraid that which might decrease that
> tab-completion.
>
> Imagine the case of "SET work_mem ". If "TO" and "=" are suggested,
> we need
On Mon, Feb 1, 2016 at 7:44 PM, Magnus Hagander wrote:
> On Thu, Jan 28, 2016 at 1:39 PM, Michael Paquier
> wrote:
>> I found a couple of typos as per the $subject.
>> A patch is attached.
>
> Applied, thanks.
Thanks.
--
Michael
--
Sent via pgsql-hackers mai
On Tue, Feb 2, 2016 at 1:08 AM, Andres Freund wrote:
> On 2016-02-01 16:49:46 +0100, Alvaro Herrera wrote:
>> Yeah. On 9.4 there are already some conflicts, and I'm sure there will
>> be more in almost each branch. Does anyone want to volunteer for
>> producing per-branch versions?
>
>> The next
On Tue, Feb 2, 2016 at 12:49 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Mon, Jan 25, 2016 at 6:50 PM, Tomas Vondra
>> wrote:
>> > Seems OK to me. Thanks for the time and improvements!
>>
>> Thanks. Perhaps a committer could have a look then? I h
On Mon, Feb 1, 2016 at 10:34 PM, Robert Haas wrote:
> On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier
> wrote:
>> On Fri, Jan 29, 2016 at 11:21 PM, Fabien COELHO wrote:
>>> +/* overflow check (needed for INT64_MIN) */
>>> +if (lval !=
On Mon, Feb 1, 2016 at 10:22 PM, Fujii Masao wrote:
> Pushed. Thanks!
>
OK. And attached is the promised patch for ALTER FUNCTION.
--
Michael
diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c
index 5f27120..3369a3d 100644
--- a/src/bin/psql/tab-complete.c
+++ b/src/bin/psql
On Mon, Feb 1, 2016 at 11:28 PM, Fujii Masao wrote:
> [first version]
> Add only synchronous_standby_num which specifies the number of standbys
> that the master must wait for before marking sync replication as completed.
> This version supports simple use cases like "I want to have two synchrono
On Mon, Feb 1, 2016 at 8:21 PM, Dmitry Ivanov
wrote:
> This patch was originally developed by Teodor Sigaev and Oleg Bartunov in
> 2009, so all credit goes to them. Any feedback is welcome.
>
This is not a small patch:
28 files changed, 2441 insertions(+), 380 deletions(-)
And the last CF of 9.6
On Tue, Feb 2, 2016 at 1:24 PM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 9:46 PM, Michael Paquier
> wrote:
> > On Mon, Feb 1, 2016 at 10:34 PM, Robert Haas
> wrote:
> >> On Sat, Jan 30, 2016 at 7:36 AM, Michael Paquier
> >> wrote:
> >>> On
On Tue, Feb 2, 2016 at 1:35 PM, Michael Paquier
wrote:
> And now there are patches. Well, nobody has complained about that until now
> except me... So we could live without patching back-branches, but it don't
> think it hurts much to fix those holes.
Meh, s/it don't/I
On Tue, Feb 2, 2016 at 1:16 PM, Noah Misch wrote:
> On Tue, Feb 02, 2016 at 01:13:20AM +0100, Andres Freund wrote:
>> is there any reason for the rather arbitrary and low checkpoint_timeout
>> limit?
>
> Not that I know, and it is inconvenient.
>
>> I'm not sure what'd actually be a good upper lim
On Tue, Feb 2, 2016 at 1:07 AM, Andres Freund wrote:
> On 2016-01-25 16:30:47 +0900, Michael Paquier wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index a2846c4..b124f90 100644
>> --- a/src/backend/access/transam/
On Tue, Feb 2, 2016 at 1:42 PM, Amit Kapila wrote:
> On Sat, Jan 30, 2016 at 7:38 PM, Michael Paquier
> wrote:
>>
>> On Fri, Jan 29, 2016 at 9:13 PM, Michael Paquier wrote:
>> > Well, to put it short, I am just trying to find a way to make the
>> > backend ski
On Wed, Feb 3, 2016 at 11:28 PM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 9:46 PM, Michael Paquier
> wrote:
>> OK, here are patches for 9.1~9.4. The main differences are that in
>> 9.3/9.4 int64 is used for the division operations, and in 9.2/9.1
>> that's int3
On Tue, Feb 2, 2016 at 9:59 AM, Andres Freund wrote:
> On 2016-02-02 09:56:40 +0900, Michael Paquier wrote:
>> And there is no actual risk of data loss
>
> Huh?
More precise: what I mean here is that should an OS crash or a power
failure happen, we would fall back to recovery at n
On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
> Not wrong, and this leads to the following:
> void rename_safe(const char *old, const char *new, bool isdir, int elevel);
> Controlling elevel is necessary per the multiple code paths that would
> use it. Some use ERROR, most o
Hi all,
I just bumped into the following typo in slot.c:
/*
* If we'd now fail - really unlikely - we wouldn't know
whether this slot
* would persist after an OS crash or not - so, force a restart. The
-* restart would try to fysnc this again till it works.
+
On Thu, Feb 4, 2016 at 5:23 PM, Stas Kelvich wrote:
(Please do not top-post, this breaks the thread flow.)
> I’ve looked over proposed patch and migrated my shell tests scripts that i’ve
> used for testing twophase commits on master/slave to this test framework.
> Everything looks mature, and
On Thu, Feb 4, 2016 at 12:02 PM, Michael Paquier
wrote:
> On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
>> Not wrong, and this leads to the following:
>> void rename_safe(const char *old, const char *new, bool isdir, int elevel);
>> Controlling elevel is necessary
On Thu, Feb 4, 2016 at 4:43 PM, Victor Wagner wrote:
> On Thu, 4 Feb 2016 12:59:03 +0300
> Michael Paquier wrote:
>> > 1) Better to raise more meaningful error when IPC::Run is absent.
>>
>> This has been discussed before, and as far as I recall the current
>&g
On Thu, Feb 4, 2016 at 4:10 PM, Andres Freund wrote:
> On 2016-02-04 18:21:41 +0530, Amit Kapila wrote:
>> I think generally it is good idea, but one thing worth a thought is that
>> by doing so, we need to acquire all WAL Insertion locks every
>> LOG_SNAPSHOT_INTERVAL_MS to check the last_insert_
On Thu, Feb 4, 2016 at 9:18 PM, Victor Wagner wrote:
> It's quite good that patch sets standard of using 'use strict; use
> warnings;' in the test script.
FWIW, this is decided as being a standard rule for any modules/script
added in the main tree.
> It is bad, that Postgres-specific perl modules
On Thu, Feb 4, 2016 at 7:27 PM, Robert Haas wrote:
> I don't in the end care very much about how we solve this problem.
> But I'm glad you agree that whatever we do to solve the simple problem
> should be a logical subset of what the full solution will eventually
> look like, not a completely diff
On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
>> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
>> wrote:
>>> Yes, please let's use the custom language, and let's not care of not
>>&g
On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
> wrote:
>> Yes, please let's use the custom language, and let's not care of not
>> more than 1 level of nesting so as it is possible to represent
>> pg_stat_r
On Thu, Feb 4, 2016 at 11:58 PM, Stas Kelvich wrote:
>> On 04 Feb 2016, at 12:59, Michael Paquier wrote:
>>> 0) There are several routines that does actual checking, like
>>> is/command_ok/command_fails. I think it will be very handy to have wrappers
>>> p
On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
> wrote:
>> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
>>> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
>>> wrote:
>>>> Yes, pleas
On Thu, Feb 4, 2016 at 2:34 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 12:02 PM, Michael Paquier
> wrote:
>> On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
>>> Not wrong, and this leads to the following:
>>> void rename_safe(const char *old, co
On Fri, Feb 5, 2016 at 12:19 PM, Masahiko Sawada wrote:
> On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
> wrote:
> I agree with adding new system catalog to easily checking replication
> status for user. And group name will needed for this.
> What about adding group n
hem into 9.4, though, not 9.5, since many of these issues are
> already fixed in 9.5.0 and will not need to appear in the 9.5.1 section.
+
+
+ Ensure that dynloader.h is included in the installed
+ header files in MSVC builds (Michael Paquier)
+
+
Bruce is the main author
On Sat, Feb 6, 2016 at 2:11 AM, Tomas Vondra
wrote:
> On 02/04/2016 09:59 AM, Michael Paquier wrote:
>>
>> On Tue, Feb 2, 2016 at 9:59 AM, Andres Freund wrote:
>>>
>>> On 2016-02-02 09:56:40 +0900, Michael Paquier wrote:
>>>>
>>>>
On Thu, Feb 4, 2016 at 6:38 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 4:10 PM, Andres Freund wrote:
>> On 2016-02-04 18:21:41 +0530, Amit Kapila wrote:
>>> I think generally it is good idea, but one thing worth a thought is that
>>> by doing so, we need t
On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote:
> On 2016-02-06 22:03:15 +0900, Michael Paquier wrote:
>> + /*
>> + * Update the progress LSN positions. At least one WAL insertion lock
>> + * is already taken appropriately before doing that, an
On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote:
> On 2016-02-06 22:03:15 +0900, Michael Paquier wrote:
>> The patch attached will apply on master, on 9.5 there is one minor
>> conflict. For older versions we will need another reworked patch.
>
> FWIW, I don't thin
On Mon, Feb 8, 2016 at 6:18 PM, Andres Freund wrote:
> On 2016-02-08 15:58:49 +0900, Michael Paquier wrote:
>> On Sun, Feb 7, 2016 at 2:49 AM, Andres Freund wrote:
>> /*
>> + * XLogInsert
>> + *
>> + * A shorthand for XLogInsertExtended, to update the progress
On Mon, Feb 8, 2016 at 6:47 AM, Peter Eisentraut wrote:
> On 1/26/16 10:56 AM, Simon Riggs wrote:
>> Removing one of "archive" or "hot standby" will just cause confusion and
>> breakage, so neither is a good choice for removal.
>>
>> What we should do is
>> 1. Map "archive" and "hot_standby" to on
On Fri, Feb 5, 2016 at 12:53 AM, Fabien COELHO wrote:
>> Something is wrong with patch d. I noticed two things,
>> 1. the total_weight stuff can overflow,
>
> It can generate an error on overflow by checking the total_weight while it
> is being computed. I've switched total_weight to int64 so it
On Mon, Feb 8, 2016 at 11:24 PM, Amit Kapila wrote:
> On Mon, Feb 8, 2016 at 12:28 PM, Michael Paquier
> wrote:
>>
>>
>> >> /*
>> >> + * Fetch the progress position before taking any WAL insert lock.
>> >> This
>> >&
On Tue, Feb 9, 2016 at 12:16 PM, kharagesuraj
wrote:
> Hello,
>
>
>
>
>
> >> I agree with first version, and attached the updated *patch* which are
> >> modified so that it supports simple multiple sync replication you
> >>suggested.
> >> (but test cases are not included yet.)
>
>
>
> I have trie
On Tue, Feb 9, 2016 at 1:16 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Tue, 9 Feb 2016 00:48:57 +0900, Fujii Masao wrote
> in
>> On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
>> > wr
On Tue, Feb 9, 2016 at 1:22 PM, Ashutosh Bapat
wrote:
> The userid being printed is from UserMapping. The new API
> GetUserMappingById() allows an FDW to get user mapping by its OID. This API
> is intended to be used by FDWs to fetch the user mapping inferred by the
> core for given join between f
On Tue, Feb 9, 2016 at 4:22 AM, Fabien COELHO wrote:
>> + /* compute total_weight */
>> + for (i = 0; i < num_scripts; i++)
>> + {
>> + total_weight += sql_script[i].weight;
>> +
>> + /* detect overflow... */
>> If let as int64, you may want to remove
On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
> Thanks for updating the patch!
> Attached is the updated version of the patch.
> I removed unnecessary assertion check and change of source code
> that you added, and improved the source comment.
> Barring objection, I'll commit this patch.
So,
On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila wrote:
> Do you see any benefit in allowing checkpoints for such cases considering
> bgwriter will anyway take care of logging standby snapshot for such
> cases?
Well, the idea is to improve the system responsiveness. Imagine that
the call to GetProgres
On Wed, Feb 3, 2016 at 7:33 AM, Robert Haas wrote:
> Also, to be frank, I think we ought to be putting more effort into
> another patch in this same area, specifically Thomas Munro's causal
> reads patch. I think a lot of people today are trying to use
> synchronous replication to build load-balan
On Wed, Feb 10, 2016 at 2:57 AM, Fujii Masao wrote:
> On Wed, Feb 10, 2016 at 1:36 AM, Masahiko Sawada
> wrote:
>> Attached first version dedicated language patch (document patch is not yet.)
>
> Thanks for the patch! Will review it.
>
> I think that it's time to write the documentation patch.
>
- email subject limit -
> Change delimiter used for display of NextXID
>
> NextXID has been rendered in the form of a pg_lsn even though it
> really is not. This can cause confusion, so change the format from
> %u/%u to %u:%u, per discussion o
On Wed, Feb 10, 2016 at 2:23 AM, Fujii Masao wrote:
> On Wed, Feb 10, 2016 at 2:21 AM, Fujii Masao wrote:
>> On Tue, Feb 9, 2016 at 9:11 PM, Michael Paquier
>> wrote:
>>> On Tue, Feb 9, 2016 at 4:27 PM, Fujii Masao wrote:
>>>> Thanks for updating the patch!
On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote:
> On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote:
>> Well, the idea is to improve the system responsiveness. Imagine that
>> the call to GetProgressRecPtr() is done within the exclusive lock
>> portion, but that w
On Wed, Feb 10, 2016 at 1:17 AM, Yury Zhuravlev
wrote:
> I've just run into a problem with these macro. Function ginStepRight breaks
> completely when compiled using the MSVC2013 and MSVC2015 (since these
> releases use C99's bools but without stdbool.h like C++).
> I don't understand why the patc
On Wed, Feb 10, 2016 at 3:45 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Your patch looks right to me, so I will commit, barring objections... with
>> backpatch. Likely to 9.0, AFAICS.
>
> 9.0 is out of support and should not be patched anymore.
>
> I agree that the patch is basically correct, t
On Mon, Feb 8, 2016 at 11:32 PM, Andres Freund wrote:
> Frequently when reading postgres logs to do some post mortem analysis
> I'm left wondering what process emitted an error/log message. After the
> fact it's often hard to know wether an error message was emitted by a
> user backend or by somet
On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
wrote:
> Yes, I will implement regression test patch and documentation patch as
well.
Cool, now that we have a clear picture of where we want to move, that would
be an excellent thing to have. Having the docs in the place is clearly
mandatory.
>
On Wed, Feb 10, 2016 at 3:13 PM, Michael Paquier
wrote:
> On Wed, Feb 10, 2016 at 11:25 AM, Masahiko Sawada
> wrote:
> I am personally fine with () and [] as you mention, we could even consider
> {}, each one of them has a different meaning mathematically..
>
> I am not enter
On Wed, Feb 10, 2016 at 12:41 PM, Amit Kapila
wrote:
> On Wed, Feb 10, 2016 at 7:17 AM, Michael Paquier <
michael.paqu...@gmail.com>
> wrote:
>>
>> On Tue, Feb 9, 2016 at 10:42 PM, Amit Kapila wrote:
>> > On Tue, Feb 9, 2016 at 6:08 PM, Michael Paquier wrote:
&
On Wed, Feb 10, 2016 at 4:11 PM, Amit Kapila
wrote:
> On Wed, Feb 10, 2016 at 12:16 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 10, 2016 at 12:41 PM, Amit Kapila
>> wrote:
>> > On Wed, Feb 10, 2016 at 7:17 AM
On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila wrote:
> Okay, but isn't it better that we remove the snapshot taken
> at checkpoint time in the main branch or till where this code is
> getting back-patched. Do you see any need of same after
> having the logging of snapshot in bgwriter?
But this o
On Wed, Feb 10, 2016 at 5:34 PM, Kyotaro HORIGUCHI
wrote:
>
> Hello,
>
> At Wed, 10 Feb 2016 15:22:44 +0900, Michael Paquier
> wrote in
>
> > On Wed, Feb 10, 2016 at 3:13 PM, Michael Paquier
> > wrote:
> > > On Wed, Feb 10, 2016 at 11:25 AM, M
On Tue, Feb 9, 2016 at 5:06 AM, Alvaro Herrera wrote:
> Fabien COELHO wrote:
>>
>> Hello,
>>
>> >>v23 attached, which does not change the message but does the other fixes.
>> >
>> >This doesn't apply anymore
>>
>> Indeed, but the latest version was really v25.
>>
>> >-- please rebase and submit to
On Thu, Feb 11, 2016 at 5:20 PM, Andres Freund wrote:
> On 2016-02-11 09:25:30 +0530, Amit Kapila wrote:
>> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier
>> wrote:
>> >
>> > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila
>> wrote:
>> > > Ok
On Thu, Feb 11, 2016 at 12:37 AM, Fabien COELHO wrote:
> v26 attached implements these changes.
+/* the argument list has been built in reverse order, it is fixed here */
+expr->u.function.args = reverse_elist(args);
Hm. I may be missing something, but why is that necessary? This is
basic
On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote:
> For your consideration, here is a new version of GSSAPI encryption
> support. For those who prefer, it's also available on my github:
> https://github.com/frozencemetery/postgres/commit/c92275b6605d7929cda5551de47a4c60aab7179e
Yeah! Glad t
On Fri, Feb 12, 2016 at 2:56 AM, Robert Haas wrote:
> On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier
> wrote:
>> So, here are some thoughts to make that more user-friendly. I think
>> that the critical issue here is to properly flatten the meta data in
>> the custom l
On Fri, Feb 12, 2016 at 2:46 AM, Robert Haas wrote:
> On Wed, Feb 10, 2016 at 12:44 AM, Jeff Janes wrote:
>> I did not bump the extension version. I realized the migration file
>> would be empty, as there no change to SQL-level functionality (the new
>> s2k-count is parsed out of a string down i
On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote:
> On Wed, Feb 10, 2016 at 10:23:41AM +0900, Michael Paquier wrote:
>> On Wed, Feb 10, 2016 at 9:57 AM, Joe Conway wrote:
>> > I'll commit the attached tomorrow if there are no other concerns voiced.
>>
>>
On Fri, Feb 12, 2016 at 2:41 AM, Fabien COELHO wrote:
>
> Hello Michaël,
>
>> +/* the argument list has been built in reverse order, it is fixed
>> here */
>> +expr->u.function.args = reverse_elist(args);
>> Hm. I may be missing something, but why is that necessary? This is
>> basically do
On Fri, Feb 12, 2016 at 3:56 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>> On Thu, Feb 11, 2016 at 6:06 AM, Robbie Harwood wrote:
>>> - The GSSAPI authentication code has been moved without modification.
>>> In doing so, the temptation to modify it (
On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-02-11 13:37:17 -0500, Tom Lane wrote:
>>> Absolutely; they don't work safely for testing bits that aren't in the
>>> rightmost byte of a flag word, for instance. I'm on board with making
>>> these fixes, I'm just
On Thu, Feb 11, 2016 at 5:46 PM, Michael Paquier
wrote:
> On Thu, Feb 11, 2016 at 5:20 PM, Andres Freund wrote:
>> On 2016-02-11 09:25:30 +0530, Amit Kapila wrote:
>>> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier
>>> wrote:
>>> >
>>> > On W
On Sat, Feb 13, 2016 at 7:54 AM, Bruce Momjian wrote:
> On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote:
>> No, that is not an improvement --- see my previous comment:
>>
>> > We could get more sophisticated by checking the catalog version number
>> > where the format was changed, bu
On Sat, Feb 13, 2016 at 1:01 PM, Robert Haas wrote:
> On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund wrote:
>> On 2016-02-12 12:37:35 -0500, Robert Haas wrote:
>>> On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund wrote:
>>> > I'm not really a fan. I'd rather change existing callers to add a
>>> >
On Sat, Feb 13, 2016 at 3:05 AM, David Steele wrote:
> On 11/16/15 8:53 AM, Michael Paquier wrote:
>> On Sat, Sep 5, 2015 at 9:31 AM, Bruce Momjian wrote:
>>> On Fri, Sep 4, 2015 at 04:51:33PM -0400, Stephen Frost wrote:
>>>>> Coming in late, but can you explain
On Sat, Feb 13, 2016 at 1:47 PM, Robert Haas wrote:
> On Fri, Feb 12, 2016 at 8:20 AM, Eugene Kazakov
> wrote:
>> TAP-tests need two Perl modules: Test::More and IPC::Run.
>>
>> The patch adds checking of modules in configure.in and configure.
>
> Why would we want that?
I was doubtful at the be
On Sat, Feb 13, 2016 at 4:37 PM, Fabien COELHO wrote:
>
>> For example, I just realized that this patch allows values to be
>> either a double or an integer and extends the operators to handle
>> double values. But variables can still only be integers.
>
> Indeed.
That's exactly the first impres
On Sat, Feb 13, 2016 at 10:15 PM, Magnus Hagander wrote:
> So, I suggest the following changes to the defaults:
> wal_level=hot_standby
> max_wal_senders=10
> max_replication_slots=10
10 seems a bit high. I would think that max_wal_senders and
max_replication_slots set at 3 are sufficient enough,
On Sat, Feb 13, 2016 at 1:48 AM, Tom Lane wrote:
> Andres Freund writes:
>> On February 12, 2016 5:29:44 PM GMT+01:00, Tom Lane
>> wrote:
>>> We should standardize on the "((var & FLAG) != 0)"
>>> pattern, which works reliably in all cases.
>
>> That's what the second version of my patch, and I
On Sun, Feb 14, 2016 at 12:37 AM, Fabien COELHO wrote:
> The two features are highly intermix, so it can only be dependent patches,
> first to add a function infrastructure and probably some support for doubles
> altough it would not be used, then to add doubles & their functions.
>
> A real pain i
On Sun, Feb 14, 2016 at 10:05 AM, Robert Haas wrote:
> On Sat, Feb 13, 2016 at 6:19 PM, Michael Paquier
> wrote:
>> On Sun, Feb 14, 2016 at 12:37 AM, Fabien COELHO wrote:
>>> The two features are highly intermix, so it can only be dependent patches,
>>> first to add
On Sun, Feb 14, 2016 at 4:42 PM, Fabien COELHO wrote:
>
>> So I would be fine to do a portion of the legwork and extract from this
>> patch something smaller that adds only functions as a first step, with the
>> minimum set of functions I mentioned upthread. Robert, Alvaro, Fabien, does
>> that so
On Mon, Feb 15, 2016 at 9:17 AM, Stephen Frost wrote:
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Sat, Feb 13, 2016 at 3:05 AM, David Steele wrote:
>> > On 11/16/15 8:53 AM, Michael Paquier wrote:
>> >> On Sat, Sep 5, 2015 at 9:3
On Mon, Feb 15, 2016 at 9:56 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> We'd need as well to switch pg_shadow to have an array of elements
>> made of protocol:identifier instead of a single password field. There
>> can be onl
On Mon, Feb 15, 2016 at 10:23 AM, Stephen Frost wrote:
> I would start by pointing out that pg_user currently uses pg_shadow..
> Why do we need pg_shadow or pg_user or related views at all..?
pg_user/pg_shadow have the advantage to be world-readable and mask
password values.
--
Michael
--
Sen
On Mon, Feb 15, 2016 at 10:51 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Stephen Frost writes:
>> > Why do we need pg_shadow or pg_user or related views at all..?
>>
>> A lot of code looks at those just to get usernames. I am not in favor of
>> breaking such stuff witho
301 - 400 of 5507 matches
Mail list logo
