On Mon, Oct 3, 2016 at 3:25 PM, Vitaly Burovoy wrote:
> I guess for ability to use filtering like:
>
> SELECT * FROM pg_hba_rules WHERE options->>radiusserver LIKE '%.example.com';
>
> I think it would be harder if options is an array of strings...
With unnest() and a matching pattern, not that h
On 10/2/16, Michael Paquier wrote:
> + push_jsonb_string_key(&parseState, "map");
> + push_jsonb_string_value(&parseState, hba->usermap);
> [...]
> +
> + options
> + jsonb
> + Configuration options set for authentication method
> +
> Why is it an advantage to use js
> This thread has basically died, so marking as returned with feedback.
Well, not exactly died, but it's kind of in blind lead.
I'll summarize a bit for future references:
1. cube extension for indexing lowered dimensionality data (2d in 3d)
is broken. Queries effectively will degrade to full inde
On Mon, Oct 3, 2016 at 2:01 PM, Michael Paquier
wrote:
> There was something like 60~70 patches still listed as active in the
> CF app on Friday my time, so doing the vacuum cleanup has taken some
> time by marking patches as returned with feedback, rejected (few) and
> moved to next CF. A couple
Hi all,
Per $subject, I would like to thank on behalf of Fabrizio everybody
who has taken the time to send patches, review them and argue about
them. This has been by experience the largest commit fest ever, with
more than 200 entries in total. The delay in stabilizing 9.6 is likely
the explanatio
On Mon, Sep 5, 2016 at 4:09 PM, Haribabu Kommi wrote:
> On Sun, Sep 4, 2016 at 1:44 AM, Simon Riggs wrote:
>> On 15 August 2016 at 12:17, Haribabu Kommi
>> wrote:
>>
>> > comments?
>>
>> This looks like a good feature contribution, thanks.
>>
>> At present the patch doesn't apply cleanly, please
On 2016/10/03 13:26, Michael Paquier wrote:
> On Fri, Sep 30, 2016 at 9:10 AM, Robert Haas wrote:
>> On Thu, Sep 29, 2016 at 8:09 AM, Amit Langote
>> wrote:
>>> I removed DEPENDENCY_IGNORE. Does the following look good or am I still
>>> missing something?
>>
>> You missed your commit message, bu
On Mon, Jul 18, 2016 at 8:10 PM, Magnus Hagander wrote:
>
>
> On Thu, Jul 14, 2016 at 8:27 PM, Andres Freund wrote:
>>
>> On 2016-07-14 13:46:23 +0200, Magnus Hagander wrote:
>> > Currently, if you run pg_xlogdump with -f, you have to specify an end
>> > position in an existing file, or if you do
On Sat, Jul 2, 2016 at 8:56 AM, Karl O. Pinc wrote:
> On Tue, 28 Jun 2016 11:06:24 +0200
> Gilles Darold wrote:
>
>> Thank you very much for the patch review and please apologies this too
>> long response delay. I was traveling since end of April and totally
>> forgotten this patch. I have applie
On Sun, Sep 11, 2016 at 12:38 PM, Vitaly Burovoy
wrote:
> On 9/10/16, Jim Nasby wrote:
>> On 9/3/16 6:01 PM, Gavin Flower wrote:
>>> I am curious as to the use cases for other possibilities.
>>
>> A hex or base64 type might be interesting, should those ever get created...
>> --
>> Jim Nasby, Data
On Sat, Jul 16, 2016 at 5:55 PM, Pavel Stehule wrote:
> I am sending fresh version of COPY RAW patch.
Moved to next CF per this status.
+++ b/src/interfaces/libpq/test/copy-raw-regress.pl
@@ -0,0 +1,48 @@
+#!/usr/bin/perl -w
+
+use strict;
I don't understand why this is shaped this way, I mean t
On Fri, Sep 30, 2016 at 9:10 AM, Robert Haas wrote:
> On Thu, Sep 29, 2016 at 8:09 AM, Amit Langote
> wrote:
>> I removed DEPENDENCY_IGNORE. Does the following look good or am I still
>> missing something?
>
> You missed your commit message, but otherwise looks fine.
I have moved this patch to
On Sun, Jun 5, 2016 at 11:33 AM, David G. Johnston
wrote:
> As an aside; most (all?) of our INEs apply to persistent schema objects.
> Extending that to session objects is a conceptual leap.
There is close to no activity here, so I marked the patch as returned
with feedback. I am doubtful about t
At Mon, 3 Oct 2016 13:14:23 +0900, Michael Paquier
wrote in
> On Thu, Sep 29, 2016 at 5:50 PM, Kyotaro HORIGUCHI
> wrote:
> > Sorry for no response, but, the answer is yes. We could be able
> > to avoid the problem by managing execution state for every
> > node. But it needs an additional flag
On Sat, Sep 10, 2016 at 7:28 AM, Kevin Grittner wrote:
> v6 fixes recently-introduced bit-rot.
Not as big as I thought, only 2k when both patches are combined... The
patch without noapi in its name needs to be applied first, and after
the patch with noapi can be applied.
60 files changed, 2073 i
On Sat, Oct 1, 2016 at 1:50 AM, Anastasia Lubennikova
wrote:
> 23.09.2016 21:06, Peter Eisentraut:
>>
>> Here is an updated patch set. Compared to the initial set, I have
>> changed pg_dump's sorting priorities so that sequence data is always
>> after table data. This would otherwise have introd
On Thu, Sep 29, 2016 at 5:50 PM, Kyotaro HORIGUCHI
wrote:
> Sorry for no response, but, the answer is yes. We could be able
> to avoid the problem by managing execution state for every
> node. But it needs an additional flag in *State structs and
> manipulating on the way shuttling up and down aro
On Fri, Sep 30, 2016 at 8:58 PM, Jeevan Chalke
wrote:
> On Mon, Sep 26, 2016 at 6:15 PM, Ashutosh Bapat
> wrote:
>>
>> This patch will need some changes to conversion_error_callback(). That
>> function reports an error in case there was an error converting the
>> result obtained from the foreign
On 2016-10-02 02:59:04 +0200, Tomas Vondra wrote:
> On 10/02/2016 02:17 AM, Andres Freund wrote:
> > Hi,
> > ...
> >
> > > > > I think a crucial part of the benchmarking will be identifying and
> > > > > measuring corner cases, e.g. a lot of rows with the same key, etc.
> > > > > Although that pro
On Tue, Jul 19, 2016 at 3:42 PM, Haribabu Kommi
wrote:
> The above changes are based on my understanding to the discussion occurred in
> this mail. In case if I miss anything, please let me know, i will
> correct the same.
The patch series still apply.
+ " ((classid = (select o
On Sun, Sep 11, 2016 at 2:15 PM, Amit Kapila wrote:
> On Sun, Sep 11, 2016 at 12:39 AM, Andres Freund wrote:
>> On 2016-09-10 17:23:21 +0530, Amit Kapila wrote:
>>> >
>>>
>>> I may be missing something here, but why would it contend on a lock,
>>> as per locking scheme proposed by Alvaro, access
On Thu, Sep 1, 2016 at 1:08 PM, Craig Ringer wrote:
> Attached is a rebased and updated logical decoding timeline following
> patch for 10.0.
Moved to next CF, nothing has happened since submission.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On Fri, Sep 16, 2016 at 6:12 AM, Tom Lane wrote:
> I'm happy to get rid of the LCM behavior, I just want to have some wiggle
> room to be able to get it back if somebody really needs it.
Er, actually no that's this thread for this CF entry:
https://commitfest.postgresql.org/10/759/
Still there ha
On Wed, Aug 24, 2016 at 3:55 AM, Andres Freund wrote:
> Comments?
This thread has no activity for some time now and it is linked to this CF entry:
https://commitfest.postgresql.org/10/759/
I am marking it as returned with feedback..
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 3 Oct. 2016 10:15, "Michael Paquier" wrote:
>
> On Tue, Sep 27, 2016 at 11:05 AM, Craig Ringer
wrote:
> > On 26 September 2016 at 21:52, Vladimir Gordiychuk
wrote:
> >>>You should rely on time I tests as little as possible. Some of the test
> >>> hosts are VERY slow. If possible something det
On Wed, Aug 31, 2016 at 6:03 AM, Andres Freund wrote:
> On 2016-08-30 21:59:44 +0100, Greg Stark wrote:
>> On Tue, Aug 30, 2016 at 11:12 AM, Heikki Linnakangas wrote:
>> > While profiling some queries and looking at executor overhead, I realized
>> > that we're not making much use of TupleTableSl
On 3 October 2016 at 10:10, Michael Paquier wrote:
> On Tue, Sep 6, 2016 at 8:01 PM, Craig Ringer wrote:
>> On 6 September 2016 at 16:10, Daniel Verite wrote:
>>> Craig Ringer wrote:
>>>
Updated patch attached.
>>>
>>> Please find attached a couple fixes for typos I've came across i
On Thu, Sep 22, 2016 at 3:45 AM, Andrew Borodin wrote:
> [blah]
>
> Practically, this algorithm cannot be implemented in current GiST API
> (only if we provide non-penalty-based choose subtree function,
> optional for GiST extension), but it certainly has scientific value.
This thread has basical
On Thu, Sep 29, 2016 at 12:55 AM, Mithun Cy wrote:
> On Tue, Sep 27, 2016 at 1:53 AM, Jeff Janes wrote:
> > I think that this needs to be updated again for v8 of concurrent and v5
> of wal
>
> Adding the rebased patch over [1] + [2]
>
> [1] Concurrent Hash index.
> [2] Wal for hash index.
Moved
On Wed, Sep 14, 2016 at 3:48 PM, Heikki Linnakangas wrote:
> If we flushed the tree to a tape instead, then we could perhaps use the
> machinery that Peter's parallel B-tree patch is adding to tuplesort.c, to
> merge the tapes. I'm not sure if that works out, but I think it's worth some
> experime
On Fri, Sep 30, 2016 at 5:47 PM, Michael Paquier
wrote:
> On Fri, Sep 30, 2016 at 1:48 AM, Robert Haas wrote:
>> The way that we're constructing the wait event ID that ultimately gets
>> advertised in pg_stat_activity is a bit silly in this patch. We start
>> with an event ID (which is an intege
On Mon, Oct 3, 2016 at 11:06 AM, Robert Haas wrote:
> On Sun, Oct 2, 2016 at 9:00 PM, Thomas Munro
> wrote:
>> On Mon, Oct 3, 2016 at 1:36 PM, Robert Haas wrote:
>>> On Sat, Oct 1, 2016 at 3:33 PM, Tom Lane wrote:
Copy-editing for contrib/pg_visibility documentation.
Add omitted
On Mon, Oct 3, 2016 at 11:40 AM, Michael Paquier
wrote:
> On Fri, Sep 30, 2016 at 2:00 AM, Jeff Janes wrote:
>> What do you think of Jim Nasby's idea of making a settable level, rather
>> just on or off?
>
> [reading the code]
> That would be a better idea. The interface proposed, aka 2 GUCs doin
On Wed, Sep 28, 2016 at 10:12 PM, Peter Eisentraut
wrote:
> On 9/23/16 9:28 PM, Petr Jelinek wrote:
>>> Document to what extent other relation types are supported (e.g.,
>>> > materialized views as source, view or foreign table or temp table as
>>> > target). Suggest an updatable view as target i
On Thu, Sep 29, 2016 at 7:18 PM, Jeevan Chalke
wrote:
> Hi Stephen,
>
>
>> > 4. It will be good if we have an example for this in section
>> > "5.7. Row Security Policies"
>>
>> I haven't added one yet, but will plan to do so.
>>
> I think you are going to add this in this patch itself, right?
>
>
On Fri, Sep 30, 2016 at 2:00 AM, Jeff Janes wrote:
> What do you think of Jim Nasby's idea of making a settable level, rather
> just on or off?
[reading the code]
That would be a better idea. The interface proposed, aka 2 GUCs doing
basically the same thing is quite confusing I think. I am markin
On Fri, Sep 30, 2016 at 12:34 PM, Amul Sul wrote:
> The new status of this patch is: Ready for Committer
And moved to next CF with same status.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova
wrote:
> Ok, I'll write it in a few days.
Marked as returned with feedback per last emails exchanged.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
On Sat, Oct 1, 2016 at 1:23 AM, Julien Rouhaud
wrote:
> On 23/09/2016 21:10, Robert Haas wrote:
>> On Fri, Sep 23, 2016 at 8:54 AM, Peter Eisentraut
>> wrote:
>>> On 9/20/16 4:07 PM, Robert Haas wrote:
No, I'm assuming that the classes would be built-in. A string tag
seems like over-en
On Tue, Sep 27, 2016 at 2:29 PM, Pavel Stehule wrote:
> 2016-09-27 5:53 GMT+02:00 Craig Ringer :
>>
>> [...]
>> ... so please delete that text. I thought I'd tested it but the state
>> of my tests dir says I just got distracted by another task at the
>> wrong time.
Moved patch to next CF with sam
On Wed, Sep 28, 2016 at 3:30 PM, Ashutosh Bapat
wrote:
> I agree, but we need to cope with above two problems.
I have marked the patch as returned with feedback per the last output
Ashutosh has provided.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, Sep 27, 2016 at 11:05 AM, Craig Ringer wrote:
> On 26 September 2016 at 21:52, Vladimir Gordiychuk wrote:
>>>You should rely on time I tests as little as possible. Some of the test
>>> hosts are VERY slow. If possible something deterministic should be used.
>>
>> That's why this changes d
On Sat, Oct 1, 2016 at 8:45 AM, Jim Nasby wrote:
> On 9/29/16 1:51 PM, Heikki Linnakangas wrote:
>>
>> Jim, I was confused, but you agreed with me. Were you also confused, or
>> am I missing something?
>
>
> I was confused by inputs:
I have marked the patch as returned with feedback. Or Heikki, d
On Tue, Sep 6, 2016 at 8:01 PM, Craig Ringer wrote:
> On 6 September 2016 at 16:10, Daniel Verite wrote:
>> Craig Ringer wrote:
>>
>>> Updated patch attached.
>>
>> Please find attached a couple fixes for typos I've came across in
>> the doc part.
>
> Thanks, will apply and post a rebased
On Sun, Oct 2, 2016 at 9:00 PM, Thomas Munro
wrote:
> On Mon, Oct 3, 2016 at 1:36 PM, Robert Haas wrote:
>> On Sat, Oct 1, 2016 at 3:33 PM, Tom Lane wrote:
>>> Copy-editing for contrib/pg_visibility documentation.
>>>
>>> Add omitted names for some function parameters.
>>> Fix some minor grammat
On Fri, Sep 16, 2016 at 6:56 PM, Masahiko Sawada wrote:
> Yeah, I don't have a good solution for this problem so far.
> We might need to improve group locking mechanism for the updating
> operation or came up with another approach to resolve this problem.
> For example, one possible idea is that t
On 10/02/2016 07:21 PM, Tom Lane wrote:
I wrote:
It occurs to me that a back-patchable workaround for this would be to
make get_loadable_libraries sort the library names in order by length
(and I guess we might as well sort same-length names alphabetically).
This would for example guarantee th
On Mon, Sep 26, 2016 at 5:26 AM, Rahila Syed wrote:
> Some initial comments on optimize_lazy_scan_heap_v2.patch.
Seems worth pursuing. Marking as returned with feedback because of
lack of activity and some basic reviews sent.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Mon, Sep 5, 2016 at 1:53 PM, Pavan Deolasee wrote:
> 0001_track_root_lp_v4.patch: This patch uses a free t_infomask2 bit to track
> latest tuple in an update chain. The t_ctid.ip_posid is used to track the
> root line pointer of the update chain. We do this only in the latest tuple
> in the cha
On Mon, Oct 3, 2016 at 12:42 AM, Pavel Stehule wrote:
>
>
> 2016-10-02 12:40 GMT+02:00 Michael Paquier :
>>
>> On Sun, Oct 2, 2016 at 3:31 AM, Greg Stark wrote:
>> > On Fri, Sep 30, 2016 at 2:11 AM, Robert Haas
>> > wrote:
>> >> For one thing, we can stop shipping a totally broken feature in rel
On Tue, Sep 13, 2016 at 5:32 PM, Alexander Korotkov
wrote:
> On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan wrote:
>>
>> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov
>> wrote:
>> > Hmm... I'm not completely agree with that. In typical usage partial sort
>> > should definitely use quicks
On Thu, Sep 8, 2016 at 3:44 AM, Peter Geoghegan wrote:
> On Fri, Sep 2, 2016 at 11:19 AM, Kevin Grittner wrote:
>> IMV the process is to post a patch to this list to certify that it
>> is yours to contribute and free of IP encumbrances that would
>> prevent us from using it. I will wait for that
On Fri, Sep 30, 2016 at 8:10 PM, Heikki Linnakangas wrote:
> This patch set is in pretty good shape, the only problem is that it's so big
> that no-one seems to have the time or courage to do the final touches and
> commit it.
Did you see my suggestions about simplifying its SQL structure? You
co
On Sun, Oct 2, 2016 at 10:15 AM, Tomas Vondra
wrote:
> One more comment about GenSlab, particularly about unpredictability of the
> repalloc() behavior. It works for "large" chunks allocated in the AllocSet
> part, and mostly does not work for "small" chunks allocated in the
> SlabContext. Moreove
On Wed, Aug 19, 2015 at 1:25 PM, Paul A Jungwirth
wrote:
> This is my first patch, so my apologies if anything is missing. I went
> the guidelines and I think I have everything covered. :-)
I am moving this patch to next CF, removing Julien Rouhaud and Teodor
Sigaev as reviewers because they have
On Tue, Apr 19, 2016 at 3:42 AM, Yuri Niyazov wrote:
> Should I update the documentation patch to instruct the use of
> pg_controldata exclusively?
I guess so. Marked as returned with feedback because the thread has died.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Fri, Sep 30, 2016 at 12:29 AM, Tom Lane wrote:
> The fundamental thing we have to do in order to move forward on this is
> to rethink what's the division of labor between pg_dump and pg_dumpall.
> I find the patch as presented quite unacceptable because it's made no
> effort to do that (or even
On Mon, Oct 3, 2016 at 1:36 PM, Robert Haas wrote:
> On Sat, Oct 1, 2016 at 3:33 PM, Tom Lane wrote:
>> Copy-editing for contrib/pg_visibility documentation.
>>
>> Add omitted names for some function parameters.
>> Fix some minor grammatical issues.
>
> Why do you keep insisting on changing case
On Thu, Sep 29, 2016 at 2:16 AM, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 9:37 PM, Gerdan Rezende dos Santos
> wrote:
>> After review, I realized that there is a call to the function:
>> doShellQuoting (pgdumpopts, OPTARG), which no longer seems to exist ...
>> After understand the code, I saw
On Fri, Sep 30, 2016 at 5:44 PM, Victor Wagner wrote:
> But backward compatibility is more
> important thing, so I now assume, that user tries to connect just one
> node, and this node is read only, user knows what he is doing.
Moved this patch to next CF.
(Note that I am in CF-vacuuming mode th
On Sun, Oct 2, 2016 at 10:47 PM, Michael Paquier
wrote:
> And seeing nothing happening here, I still don't know what to do with
> this patch. Thoughts? If we are going to do nothing I would suggest to
> just remove the comment in string_utils.c saying that such LF and CR
> will be unsupported in a
On Sat, Oct 1, 2016 at 3:33 PM, Tom Lane wrote:
> Copy-editing for contrib/pg_visibility documentation.
>
> Add omitted names for some function parameters.
> Fix some minor grammatical issues.
Why do you keep insisting on changing case where I've written "which"
to instead say "that" in situation
I wrote:
> It occurs to me that a back-patchable workaround for this would be to
> make get_loadable_libraries sort the library names in order by length
> (and I guess we might as well sort same-length names alphabetically).
> This would for example guarantee that hstore_plpython is probed after
>
Andres Freund writes:
> On 2016-10-02 17:59:47 -0400, Tom Lane wrote:
>> So now I'm thinking you're right, it'd be better to have some solution
>> whereby dfmgr.c knows about cross-module dependencies and loads the
>> dependencies first. Not sure how to approach that. The extension
>> "requires"
On 2016-10-02 17:59:47 -0400, Tom Lane wrote:
> I've found that the Linux '-l:hstore.so' solution works on HPUX as well,
> at least to the extent of being able to run LOAD. However, it doesn't
> seem to be possible to make it work on macOS, which has a hard distinction
> between "loadable modules"
I wrote:
> So it doesn't seem that we've broken anything since 9.5 --- it didn't
> work before either. The seeming successes may have been due to chance,
> i.e. pg_upgrade probing the libraries in an order that happened to work.
> I see no evidence that get_loadable_libraries/check_loadable_librar
Andrew Dunstan writes:
> On 10/02/2016 12:54 PM, Tom Lane wrote:
>> [ digs more deeply ... ] Oh, weird: it looks like this succeeded in
>> every case except 9.6->HEAD upgrade. Did we break something recently?
> Yeah, my latest version of the test module (soon to hit githyb) also
> does a self
Re: Tom Lane 2016-09-29 <18642.1475159...@sss.pgh.pa.us>
> > Possibly the longer version could be added as an example in the
> > documentation.
>
> I suspect that simply having a nonempty default in the first place
> is going to do more to raise peoples' awareness than anything we
> could do in th
On 10/02/2016 12:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
The biggest issue is this: the upgrade fails completely on
ltree-plpython and hstore-plpython, presumably because these modules
rely on the plpython module being loaded first. pg_upgrade rather
simple-mindedly calls LOAD on the ob
Andrew Dunstan writes:
> On 10/02/2016 01:53 PM, Tom Lane wrote:
>> Because pg_dump with --binary-upgrade neglects to emit
>> ALTER EXTENSION bloom ADD ACCESS METHOD bloom;
>> which it would need to do in order to make this work right. The other
>> small problem is that there is no such ALTER EXT
On 10/02/2016 01:53 PM, Tom Lane wrote:
So then why are the pre-upgrade and post-upgrade dumps different?
Because pg_dump with --binary-upgrade neglects to emit
ALTER EXTENSION bloom ADD ACCESS METHOD bloom;
That's what I suspected.
which it would need to do in order to make this work ri
Andrew Dunstan writes:
> On 10/02/2016 09:50 AM, Michael Paquier wrote:
>> On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote:
>>> It looks like we have some work to do to teach pg_dump about handling access
>>> methods in extensions. This doesn't look quite as bad as the first issue,
>>> but
I wrote:
> I suspect the explanation is that macOS's dynamic linker is smart enough
> to pull in plpython when one of those modules is LOAD'ed. The ideal fix
> would be to make that happen on all platforms. I'm not actually sure
> why it doesn't already; surely every dynamic linker in existence h
Andrew Dunstan writes:
> The biggest issue is this: the upgrade fails completely on
> ltree-plpython and hstore-plpython, presumably because these modules
> rely on the plpython module being loaded first. pg_upgrade rather
> simple-mindedly calls LOAD on the object library to test if it's usabl
2016-10-02 12:40 GMT+02:00 Michael Paquier :
> On Sun, Oct 2, 2016 at 3:31 AM, Greg Stark wrote:
> > On Fri, Sep 30, 2016 at 2:11 AM, Robert Haas
> wrote:
> >> For one thing, we can stop shipping a totally broken feature in release
> after release
> >
> > For what it's worth I'm for any patch th
On 10/02/2016 09:50 AM, Michael Paquier wrote:
On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote:
It looks like we have some work to do to teach pg_dump about handling access
methods in extensions. This doesn't look quite as bad as the first issue,
but it's a pity 9.6 escaped into the wil
On Thu, Sep 22, 2016 at 7:48 PM, Rushabh Lathia
wrote:
> I performed basic test with patch,
>
> a) patch get applied cleanly on latest source,
> b) able to build documentation cleanly.
>
> Marking this as ready for committer.
Oops, incorrect patch... I am moving it to next CF. Discussion can
cont
On Wed, Jan 27, 2016 at 7:52 PM, Etsuro Fujita
wrote:
> Here is a small patch to do s/for/For/ to two section titles in
> fdwhandlers.sgml, for consistency.
I am grepping 54 places where "for" is used in a , and none of
them use an upper case for its first letter. I am marking this patch
as rejec
On Wed, Sep 28, 2016 at 5:14 PM, Michael Paquier
wrote:
> OK, so I have done a review of this patch keeping that in mind as
> that's the consensus. I am still getting familiar with the code...
Returned with feedback for now. This just needs polishing so feel free
to move it to the next CF once yo
On Sun, Oct 2, 2016 at 10:55 PM, Michael Paquier
wrote:
> Let's remove it and move on then. By looking again at this thread and
> particularly
> https://www.postgresql.org/message-id/20160926190618.gh5...@tamriel.snowman.net
> (thanks Stephen for the summary) that's where we are heading to.
(Mov
On Sat, Oct 1, 2016 at 9:47 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>>> My vote (which was not counted by Stephen) was to remove it from \df+
>>> altogether. I stand by that. People who are used to seeing the output
>>> in \df+ will wonder "where the
On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan wrote:
> It looks like we have some work to do to teach pg_dump about handling access
> methods in extensions. This doesn't look quite as bad as the first issue,
> but it's a pity 9.6 escaped into the wild with this issue.
562f06f3 has addressed thi
On Mon, Sep 12, 2016 at 11:38 AM, Michael Paquier
wrote:
> On Mon, Sep 12, 2016 at 10:01 AM, Noah Misch wrote:
>> I discourage documenting LF/CR restrictions. For the epsilon of readers who
>> would benefit from this knowledge, the error message suffices. For everyone
>> else, it would just dil
On Tue, Sep 27, 2016 at 10:41 AM, Amit Langote
wrote:
> On 2016/09/26 20:27, Fabien COELHO wrote:
>>
>> Hello Amit,
>>
I am marking the pgbench-into-5.patch [1] as "Ready for Committer" as I
have no further comments at the moment.
>>>
>>> Wait... Heikki's latest commit now requires this
On Sat, Oct 1, 2016 at 11:35 PM, Fabien COELHO wrote:
> Attached version changes:
> - removes C operators not present in psql
> - document operators one per line
Moved to next CF with same status: "Ready for committer".
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
I'm working on updating and making production ready my experimental
cross version pg_upgrade testing module for the buildfarm. A couple of
things have emerged that are of concern. This module does a much more
complete test that our normal test for pg_upgrade, which only checks
upgrading the s
On Fri, Sep 30, 2016 at 10:12 PM, Daniel Verite wrote:
> Tomas Vondra wrote:
>
>> A few minor comments regarding the patch:
>>
>> 1) CopyStartSend seems pretty pointless - It only has one function call
>> in it, and is called on exactly one place (and all other places simply
>> call allowL
> So, if I understand correctly, then we can mark the version posted by
> you upthread [1] which includes a test along with Kyotaro's fix can be
> marked as Ready for committer. If so, then please change the status
> of patch accordingly.
Patch moved to next CF 2016-11, still with status "ready f
On Tue, Sep 6, 2016 at 9:36 PM, Michael Paquier
wrote:
> OK, let's get to the next step of the game and get a committer to look
> at this patch.
Moved to next CF. It would be good to get a committer on this one. We
have come on a conclusion on what to do. Actually, 0001 can be just
HEAD-only per
On Fri, Sep 30, 2016 at 1:09 AM, Ashutosh Bapat
wrote:
>>
>>> The attached patch adds the
>>> dependencies from create_foreignscan_plan() which is called for any
>>> foreign access. I have also added testcases to test the functionality.
>>> Let me know your comments on the patch.
>>
>>
>> Hmm. I'
On Thu, Sep 29, 2016 at 10:02 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 29 Sep 2016 16:59:55 +0900, Michael Paquier
> wrote in
>
>> On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI
>> wrote:
>> > Hello, I return to this before my things:)
>> >
>> > Though I haven't played with the p
On 10/01/2016 02:01 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/30/2016 12:24 PM, Tom Lane wrote:
Seems to be some additional prep work needed somewhere ...
No upgrade_install_root at
/home/bfarm/bf-scripts/build-farm-4.17/PGBuild/Modules/TestUpgradeXversion.pm
line 51.
Oh sorry, you
On Sun, Oct 2, 2016 at 3:31 AM, Greg Stark wrote:
> On Fri, Sep 30, 2016 at 2:11 AM, Robert Haas wrote:
>> For one thing, we can stop shipping a totally broken feature in release
>> after release
>
> For what it's worth I'm for any patch that can accomplish that.
>
> In retrospect I think we sho
On Sat, Oct 1, 2016 at 1:15 PM, Peter Geoghegan wrote:
> It also looks like the DO NOTHING variant is similarly affected, even
> when the isolation level is READ COMMITTED.:-(
Actually, the DO NOTHING variant is also only affected in isolation
levels greater than READ COMMITTED. Not sure why
94 matches
Mail list logo
