On Tue, Dec 5, 2017 at 11:04 AM, Rajkumar Raghuwanshi
wrote:
> On Mon, Dec 4, 2017 at 7:34 AM, Ashutosh Bapat
> wrote:
>> I agree, the patch looks longer than expected. I think, it's important
>> to have some testcases to test partition-wise join with default
>> partitions. I think we need at lea
On Tue, Dec 5, 2017 at 6:39 PM, Amit Kapila wrote:
> I have one another observation in the somewhat related area. From the
> code, it looks like we might have some problem with displaying sort
> info for workers for rescans. I think the problem with the sortinfo
> is that it initializes shared i
Hello,
Hi! I'm very sorry that I did not answer for so long, I was very busy in
the release of Postgres Pro 10 :(
Here is the third version of the patch for pgbench thanks to Fabien
Coelho comments. As in the previous one, transactions with
serialization and deadlock failures are rolled bac
On Tue, Dec 5, 2017 at 11:20 AM, Julien Rouhaud wrote:
> + * PartitionBoundInfoData structures for two partitioned table with
> exactly same
>
> should be "tables".
Sorry. Thanks for pointing it out. fixed in the attached patch.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgr
Hi all
TL;DR: we should delete pg_replslot/$SLOTNAME/* at the start of each
decoding session or we can accidentally re-use stale reorder buffer
contents from prior runs and $BADNESS happens. StartupReorderBuffer() is
not sufficient.
Details:
Petr and I have found a bug in logical decoding where
On Tue, Dec 5, 2017 at 5:48 AM, Ashutosh Bapat
wrote:
> Hi,
>
Hi,
> Julien Rouhaund, who has proposed a patch for partition-wise ordering
> mentioned to me offlist that the comments for PartitionBoundInfoData
> do not mention the fact that the datums in datums array are ordered. I
> think that's
On Mon, Dec 4, 2017 at 11:17 PM, Robert Haas wrote:
> On Sat, Dec 2, 2017 at 8:04 AM, Amit Kapila wrote:
>> Attached patch contains regression test as well. Note that I have
>> carefully disabled all variable stats by using (analyze, timing off,
>> summary off, costs off) and then selected paral
On Mon, Dec 4, 2017 at 7:34 AM, Ashutosh Bapat
wrote:
> I agree, the patch looks longer than expected. I think, it's important
> to have some testcases to test partition-wise join with default
> partitions. I think we need at least one test for range default
> partitions, one test for list partiti
On Mon, Dec 04, 2017 at 03:15:08PM -0500, Tom Lane wrote:
> While working through Michael Paquier's patch to clean up inconsistent
> usage of AllocateDir(), I noticed that ResetUnloggedRelations and its
> subroutines are not consistent about whether a directory open failure
> results in erroring ou
Hi,
Julien Rouhaund, who has proposed a patch for partition-wise ordering
mentioned to me offlist that the comments for PartitionBoundInfoData
do not mention the fact that the datums in datums array are ordered. I
think that's important to mention there. So here's patch to do that.
The comment I
Hi Tom,
On 12/4/17 3:15 PM, Tom Lane wrote:
> While working through Michael Paquier's patch to clean up inconsistent
> usage of AllocateDir(), I noticed that ResetUnloggedRelations and its
> subroutines are not consistent about whether a directory open failure
> results in erroring out or just emi
On 29 November 2017 at 23:59, Petr Jelinek
wrote:
> Hi,
>
> On 17/11/17 08:35, Kyotaro HORIGUCHI wrote:
> >
> > Moving around the code allow us to place ps_is_send_pending() in
> > the while condition, which seems to be more proper place to do
> > that. I haven't added test for this particular ca
On 4 December 2017 at 23:15, Nikhil Sontakke
wrote:
> PFA, latest patch for this functionality.
> This patch contains the following changes as compared to the earlier patch:
>
> - Fixed a bunch of typos and comments
>
> - Modified HeapTupleSatisfiesVacuum to return HEAPTUPLE_RECENTLY_DEAD
> if th
On Tue, Dec 5, 2017 at 11:32 AM, Tom Lane wrote:
> ISTM one key issue here is whether pgbench's expression language is
> meant to model SQL (where we have function overloading) or C (where
> there is no overloading). I don't think we've really settled on a
> fixed policy on that, but maybe now is
Hi,
Currently, txid_current and friends export a 64-bit format of
transaction id that is extended with an “epoch” counter so that it
will not wrap around during the life of an installation. The epoch
value it uses is based on the epoch that is maintained by checkpoint
(aka only checkpoint increm
On Fri, Jun 23, 2017 at 03:45:48PM -0400, Peter Eisentraut wrote:
> On 6/23/17 13:14, Alvaro Herrera wrote:
> > Andres Freund wrote:
> >> On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote:
> >>> Tom Lane wrote:
> Peter Eisentraut writes:
> > Any thoughts about keeping datumAsEqual() as a
On 13 November 2016 at 22:31, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-11-13 17:20:05 -0500, Tom Lane wrote:
>>> Why do you care? It's a pretty specialized hook.
>
>> Citus currently uses it to output additional information for distributed
>> queries. I suspect we'll instead, for now,
Michael Paquier writes:
> On Tue, Dec 5, 2017 at 11:15 AM, Tom Lane wrote:
>> The general theory I'm operating on is that we should endeavor to
>> let the database start in any situation where that doesn't involve
>> a data-corruption hazard. Yeah, it might not be nice if we leave
>> GB worth of
Michael Paquier writes:
> On Tue, Dec 5, 2017 at 5:38 AM, Robert Haas wrote:
>> I'm willing to commit any of the following things:
>>
>> 1. A patch that adds an integer version of pow() but not a double version
>> 2. A patch that adds a double version of pow() but not an integer version
>> 3. A
On Tue, Dec 5, 2017 at 11:15 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote:
>>> Uh ... I'm confused? That particular change only concerns whether we emit
>>> a log message, not whether the action is attempted or succeeds.
>
>> From the commit m
Michael Paquier writes:
> On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote:
>> Uh ... I'm confused? That particular change only concerns whether we emit
>> a log message, not whether the action is attempted or succeeds.
> From the commit mentioned upthread, this switches one hard failure
> when
On Tue, Dec 5, 2017 at 3:58 AM, Tom Lane wrote:
> Barring objection I'll remove the tblspcdir parameter and have
> do_pg_start_backup() open and close the directory immediately
> around the loop where it's read, like every other case in the
> backend.
+1. Thanks for the change. What has been comm
On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro
>> wrote:
>>> Belatedly, +1. The error hiding seemed a bit odd considering that we
>>> were prepared to log "unexpected file found ...". I probably should
>>> have questio
On Tue, Dec 5, 2017 at 5:38 AM, Robert Haas wrote:
> I'm willing to commit any of the following things:
>
> 1. A patch that adds an integer version of pow() but not a double version
> 2. A patch that adds a double version of pow() but not an integer version
> 3. A patch that adds both an integer v
Michael Paquier writes:
> On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro
> wrote:
>> Belatedly, +1. The error hiding seemed a bit odd considering that we
>> were prepared to log "unexpected file found ...". I probably should
>> have questioned that instead of extending it monkey-see-monkey-do.
>
.
On Mon, Dec 4, 2017 at 5:41 PM, Noah Misch wrote:
>> I don't think we quite have an established protocol for this. I
>> personally, but I'm biased in this specific case, is that we should
>> adopt a position that PGDLLIMPORTs should basically backpatched whenever
>> a credible extension even hal
Michael Paquier writes:
> Note I am +/-0 with exposing ReadDirExtended in back-branches, because
> there is no use for it yet there.
My thought is basically that we might end up back-patching some change
that needs that. Nothing I've done today requires it, but it seems like
a very harmless guar
On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro
wrote:
> On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane wrote:
>> Anyway, I'm inclined to reverse that choice and emit LOG messages
>> reporting failure of any of the lstat, rmdir, or unlink calls in
>> RemovePgTempFilesInDir. In the worst case, say that th
On Mon, Nov 20, 2017 at 12:02:30PM -0800, Andres Freund wrote:
> On 2017-11-20 11:58:44 -0800, Brian Cloutier wrote:
> > > please, append session_timezone to your list
> >
> > Here's a v2 patch which also includes session_timezone.
> >
> > Separately, is this the kind of thing which is eligible f
On Tue, Dec 5, 2017 at 4:11 AM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Yeah, agreed. The only thing I'm concerned about back-patching is
>> the places where a wrong errno might be reported.
>
> If we're currently reporting "could not open dir: Success" then
> backpatching such a fix is defini
On Tue, Dec 5, 2017 at 7:17 AM, Tom Lane wrote:
> Michael Paquier writes:
>> I had a close look at all the callers of AllocateDir() and noticed a
>> couple of unwelcome things (Tom noticed some of those in the thread
>> mentioned above, I found others):
>
> Pushed with some minor additional fiddl
On Thu, Nov 30, 2017 at 11:19 PM, Thomas Munro
wrote:
> On Thu, Nov 30, 2017 at 4:01 AM, Robert Haas wrote:
>>> Better ideas?
>>
>> How about this:
>>
>> 1. Remove es_query_dsa altogether.
>> 2. Add a dsa_area * to ExecParallelInitializeDSMContext.
>> 3. In ExecParallelInitializeDSM, pass the dsa
On Tue, Dec 5, 2017 at 10:03 AM, Craig Ringer wrote:
> pglogical sets up its own handler 'handle_sigterm'. However, it now does
> much the same as src/backend/tcop/postgres.c's 'die' function, just without
> the single-user mode checks.
Documentation shows a simple example of that:
https://www.po
On 5 December 2017 at 00:40, Chapman Flack wrote:
>
> Is there a known, default behavior that some signals will
> have, if I simply BackgroundWorkerUnblockSignals() without customizing?
> Will SIGINT and SIGTERM, for example, have default handlers that
> interact with the volatile flags in miscad
On 30.11.2017 05:31, Michael Paquier wrote:
I can see as well that the patches posted at the beginning of the
thread got reviews but that those did not get answered. The set of
patches also have conflicts with HEAD so they need a rebase. For those
reasons I am marking this entry as returned with
On 2 December 2017 at 03:39, Robert Haas wrote:
> On Thu, Nov 30, 2017 at 11:39 PM, David Rowley
> wrote:
>> I feel like we could do better here with little extra effort. The
>> DETACH index feature does not really seem required for this patch.
>
> Because of the dump/restore considerations menti
On 2 December 2017 at 11:10, Alvaro Herrera wrote:
> What you're saying is that I've written code for A+B, and you're
> "interested in C (which is incompatible with B), so can we have A+C and
> drop B". But in reality, there exists (unwritten) D that solves the
> incompatiblity between B and C.
On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane wrote:
> Anyway, I'm inclined to reverse that choice and emit LOG messages
> reporting failure of any of the lstat, rmdir, or unlink calls in
> RemovePgTempFilesInDir. In the worst case, say that there are a
> bunch of leftover temp files in a directory th
On Tue, Dec 5, 2017 at 2:49 AM, Robert Haas wrote:
> On Sun, Dec 3, 2017 at 3:42 PM, Stephen Frost wrote:
>> I'm not a fan of having *only* warning in the back-branches. What I
>> would think we'd do here is correct the back-branch documentation to be
>> correct, and then add a warning that it c
Michael Paquier writes:
> I had a close look at all the callers of AllocateDir() and noticed a
> couple of unwelcome things (Tom noticed some of those in the thread
> mentioned above, I found others):
Pushed with some minor additional fiddling. The most notable thing
I changed was that instead o
On Tue, Dec 5, 2017 at 5:55 AM, Marco Pfatschbacher
wrote:
> On Thu, Sep 15, 2016 at 04:40:00PM -0400, Tom Lane wrote:
>> I just noticed that kqueue appears to offer a solution to this problem,
>> ie one of the things you can wait for is exit of another process (named
>> by PID, looks like). If t
Hi Andrey,
On Sun, Dec 3, 2017 at 10:11 PM, Andrey Borodin wrote:
> I like the idea of more compact B-tree.
> Chances are that I didn't understood all your ideas.
>
> But ItemId's let you insert a tuple among two existing tuples without data
> movement. New tuple is places wherever free space st
On Mon, Dec 4, 2017 at 10:47 AM, Fabien COELHO wrote:
>> What's the name of the backend function whose behavior this matches?
>>
>> As Fabien has mentioned, it tries to behave as "numeric_power". Maybe we
>> it'd better if we switch to "dpow" (which is pow with some error handling)
>> and always r
On 12/4/17, 2:27 PM, "Robert Haas" wrote:
> Committed.
Thanks!
Nathan
On Fri, Dec 1, 2017 at 4:05 PM, Bossart, Nathan wrote:
> On 12/1/17, 2:03 PM, "Robert Haas" wrote:
>> Thanks. I think this looks fine now, except that (1) it needs a
>> pgindent run and (2) I vote for putting the test case back. Michael
>> thought the test case was too much because this is so o
While working through Michael Paquier's patch to clean up inconsistent
usage of AllocateDir(), I noticed that ResetUnloggedRelations and its
subroutines are not consistent about whether a directory open failure
results in erroring out or just emitting a LOG message and continuing.
ResetUnloggedRela
Tom Lane wrote:
> Yeah, agreed. The only thing I'm concerned about back-patching is
> the places where a wrong errno might be reported.
If we're currently reporting "could not open dir: Success" then
backpatching such a fix is definitely an improvement. OTOH if currently
we have opendir() tryin
Robert Haas writes:
> On Mon, Dec 4, 2017 at 12:05 PM, Tom Lane wrote:
>> The only part of this that seems likely to be controversial is the
>> decision to get rid of special-case error messages, eg replace
>> "could not open tablespace directory \"%s\": %m"
>> with the more generic
>> "could not
Why is it that do_pg_start_backup() expects its callers to pass in
an open DIR pointer for the pg_tblspc directory, rather than doing
the AllocateDir call for itself? This complicates the callers, provides
no flexibility (since do_pg_start_backup() is hardwired to know that
pg_tblspc is what it wa
On Sun, Dec 3, 2017 at 3:42 PM, Stephen Frost wrote:
> I'm not a fan of having *only* warning in the back-branches. What I
> would think we'd do here is correct the back-branch documentation to be
> correct, and then add a warning that it changes in v11.
>
> You didn't suggest an actual change wr
On Sat, Dec 2, 2017 at 8:04 AM, Amit Kapila wrote:
> Attached patch contains regression test as well. Note that I have
> carefully disabled all variable stats by using (analyze, timing off,
> summary off, costs off) and then selected parallel sequential scan on
> the right of join so that we have
On Tue, Sep 5, 2017 at 9:10 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 05.09.2017 04:02, Amit Langote wrote:
>
> Like Thomas, I'm not so sure about the whole predtest.c patch. The core
> logic in operator_predicate_proof() should be able to conclude that, say,
> k < 21 i
On Mon, Dec 4, 2017 at 12:05 PM, Tom Lane wrote:
> Michael Paquier writes:
>> I had a close look at all the callers of AllocateDir() and noticed a
>> couple of unwelcome things (Tom noticed some of those in the thread
>> mentioned above, I found others):
>
> The only part of this that seems likel
> 30 нояб. 2017 г., в 23:07, Andrey Borodin написал(а):
>
> Seems like it was not a big deal of patching, I've fixed those bits (see
> attachment).
> I've done only simple tests as for now, but I'm planning to do better testing
> before next CF.
> Thanks for mentioning "heapallindexed", I'll
On 04.12.2017 19:44, Alvaro Herrera wrote:
Konstantin Knizhnik wrote:
On 30.11.2017 05:16, Michael Paquier wrote:
On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik
wrote:
Concerning broken partition_join test: it is "expected" failure: my patch
removes from the plans redundant checks.
S
On Thu, Sep 15, 2016 at 04:40:00PM -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Very interesting. Perhaps that is why NetBSD shows a speedup with the
> > kqueue patch[1] but FreeBSD doesn't. I guess that if I could get the
> > kqueue patch to perform better on large FreeBSD systems, it woul
Michael Paquier writes:
> I had a close look at all the callers of AllocateDir() and noticed a
> couple of unwelcome things (Tom noticed some of those in the thread
> mentioned above, I found others):
The only part of this that seems likely to be controversial is the
decision to get rid of specia
Konstantin Knizhnik wrote:
>
>
> On 30.11.2017 05:16, Michael Paquier wrote:
> > On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik
> > wrote:
> > > Concerning broken partition_join test: it is "expected" failure: my patch
> > > removes from the plans redundant checks.
> > > So the only requir
I'm curious about handling signals in a background worker.
As I understand it, these are blocked when the BGW is born, until
enabled with BackgroundWorkerUnblockSignals() after possible
customization.
Is there a known, default behavior that some signals will
have, if I simply BackgroundWorkerUnbl
Here is the patch rebased to a852cfe9.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/executor/nodeMergejoin.c b/src/backend/executor/nodeMergejoin.c
index ef9e1ee471..c842ed2968 100644
--- a/src/backend/executor/nod
On Sun, Dec 3, 2017 at 10:30 PM, Amit Kapila wrote:
> I thought there are some cases (though less) where we want to Shutdown
> the nodes (ExecShutdownNode) earlier and release the resources sooner.
> However, if you are not completely sure about this change, then we can
> leave it as it. Thanks f
Please add the new function into the documentation table in
alphabetical order.
Fixed in the attached patch.
Yep. Patch applies cleanly. Make check & pgbench check ok. make html ok.
POW is in the right place in the table, sorry I did not check before.
What's the name of the backend funct
On 30.11.2017 04:59, Michael Paquier wrote:
On Wed, Sep 13, 2017 at 2:11 AM, Konstantin Knizhnik
wrote:
One more patch passing all regression tests with autoprepare_threshold=1.
I still do not think that it should be switch on by default...
This patch does not apply, and did not get any revi
The recent changes in commit dc6c4c9dc caused Coverity to start
complaining that RemovePgTempFilesInDir calls rmdir() without checking
its return value, as would be good practice. Now, this wasn't really a
fault of that commit, because the code was already ignoring the result of
unlink(), but it d
2017-12-04 9:29 GMT+01:00 Alexander Korotkov :
> On Mon, Dec 4, 2017 at 11:21 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> The problem is that it's hard to read arbitrary formatted psql output
>> from external program (not just gnuplot, but even especially written
>> script).
On 30.11.2017 05:02, Michael Paquier wrote:
On Wed, Sep 27, 2017 at 4:07 PM, Simon Riggs wrote:
On 15 September 2017 at 16:34, Konstantin Knizhnik
wrote:
Attached please find yet another version of the patch.
Thanks. I'm reviewing it.
Two months later, this patch is still waiting for a rev
I'm not sure why it wasn't failing before, but I have issues building the
doc:
+are built into
pgbench
Missing '/' to close the xref
Indeed, missing xml-ization. The format was still SGML when the patch was
developed.
+ 1 & 3
Expecting ';' as the previous use (&)
Indeed, a typo
PFA, latest patch for this functionality.
This patch contains the following changes as compared to the earlier patch:
- Fixed a bunch of typos and comments
- Modified HeapTupleSatisfiesVacuum to return HEAPTUPLE_RECENTLY_DEAD
if the transaction id is newer than OldestXmin. Doing this only for
CAT
On Wed, Nov 22, 2017 at 12:25 AM, Huong Dangminh
wrote:
> Thanks for your response.
> # And sorry again because I could not reply to your gmail
> # address from my environment due to security restriction.
It's okay. I can understand your environment :-)
> Sorry for not replying sooner.
>
>> > At
On Mon, Dec 4, 2017 at 8:59 AM, Lyes Ameddah wrote:
> sorry guys, yes I'm talking about a FULL VACUUM and not about Auto-Vacuum.
> Thank you very match for your feedback.
OK, but that's not the confusion. What you said is that it CRASHES,
but the behavior you described is that it BLOCKS waiting
On 1 December 2017 at 23:04, Chapman Flack wrote:
> On 11/29/2017 05:48 PM, Chapman Flack wrote:
> > I'm thinking of writing a background worker that will enumerate
> > the databases present, and spin off, for each one, another BGW
> > that will establish a connection and do stuff.
>
> Can I even
On 30 November 2017 at 06:48, Chapman Flack wrote:
> I'm thinking of writing a background worker that will enumerate
> the databases present, and spin off, for each one, another BGW
> that will establish a connection and do stuff.
>
> For the "master" one, what capabilities will it need to simply
Adds the GROUPS option to the window framing clause. This further
resolves TODO list item "Implement full support for window framing
clauses" and implements SQL:2011 T620. No other mainstream db has this
feature.
Apply this on top of my previous patch available here:
https://www.postgresql.org/mes
Hello
I update patch and also rebase to current head. I hope now it is better aligned
with project stylediff --git a/src/backend/catalog/partition.c b/src/backend/catalog/partition.c
index dd4a8d3..36bcb3f 100644
--- a/src/backend/catalog/partition.c
+++ b/src/backend/catalog/partition.c
@@ -1227,
sorry guys, yes I'm talking about a FULL VACUUM and not about Auto-Vacuum.
Thank you very match for your feedback.
That's Waht I do :
vacuum FULL VERBOSE ANALYZE;
reindex database postgres;
I would be happy if there is a patch to fix that !
2017-12-01 22:16 GMT+01:00 Bossart, Nathan :
> On 12/1
On Mon, Dec 04, 2017 at 09:48:44AM +0100, Adrien Nayrat wrote:
> On 12/01/2017 05:35 AM, Thomas Munro wrote:
> >> since it also supports "transparent" hugepages.
> > Hmm. Yeah, it does, but apparently it's not so transparent.
>
> +1. We saw performance drop with transparent_hugepage enabled on s
Hi,
Please add the new function into the documentation table in alphabetical
> order.
Fixed in the attached patch.
What's the name of the backend function whose behavior this matches?
As Fabien has mentioned, it tries to behave as "numeric_power". Maybe we
it'd
better if we switch to "dpow" (w
Hi,
> Regenerated v15 that applies cleanly on head. No changes.
I'm not sure why it wasn't failing before, but I have issues building the
doc:
+are built into
pgbench
Missing '/' to close the xref
+ 1 & 3
Expecting ';' as the previous use (&)
On Fri, Dec 1, 2017 at 1:57 PM, Fabien C
Hi,
> From: Huong Dangminh [mailto:huo-dangm...@ys.jp.nec.com]
> I attached a patch based on Sawada-san's patch with a bit of messages
> modified and remove the above check.
> Could somebody check it for me or should I add it into CF?
Sorry, I have added this thread to the next CF.
---
Thanks a
On 12/01/2017 05:35 AM, Thomas Munro wrote:
>> since it also
>> supports "transparent" hugepages.
> Hmm. Yeah, it does, but apparently it's not so transparent.
+1. We saw performance drop with transparent_hugepage enabled on server with
more than 256GB RAM. Access to the cache where slow down wh
On Mon, Dec 4, 2017 at 11:21 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> The problem is that it's hard to read arbitrary formatted psql output from
> external program (not just gnuplot, but even especially written script). I
> made my scripts read few variations, but it doesn't l
On Fri, Dec 1, 2017 at 6:36 PM, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 12:16 AM, Michael Paquier
> wrote:
> > On Sat, Nov 11, 2017 at 12:57 AM, Pavel Stehule
> wrote:
> >> 2017-11-10 16:38 GMT+01:00 Fabien COELHO :
> >>> So I switched the patch to "ready for committer".
> >>
> >> Thank you
82 matches
Mail list logo
