> On Jan 10, 2019, at 8:01 PM, Tom Lane wrote:
>
> ... estimate_rel_size() in plancat.c is where to look to find out
> about the planner's default estimates when it's lacking hard data.
Thank you! Now I see how the planner uses the rows to estimate the cost and
generates the best_plan.
To
On Fri, Jan 11, 2019 at 10:50:32AM +0900, Amit Langote wrote:
> Okay, I withdraw my objection to the wording proposed by you.
Thanks. I can commit this version if there are no objections then.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jan 10, 2019 at 6:10 PM, Imai, Yoshikazu wrote:
> > Does that not mean that the if (parent->top_parent_relids) will always
> > be false in build_dummy_partition_rel() and it'll only ever get
> > rtekind == RTE_RELATION?
>
> At least, I checked if (parent->top_parent_relids) can be true if
On 2019/01/11 11:07, Amit Langote wrote:
> On 2019/01/11 6:47, David Rowley wrote:
>> On Fri, 11 Jan 2019 at 06:56, Alvaro Herrera
>> wrote:
>>> Pushed 0001 with some minor tweaks, thanks.
>>
>> Thanks for pushing. I had looked at 0001 last night and there wasn't
>> much to report, just:
>>
>>
On Thu, Jan 10, 2019 at 2:45 PM Masahiko Sawada wrote:
>
> On Thu, Jan 10, 2019 at 5:23 AM Bossart, Nathan wrote:
> >
> > Hi,
> >
> > On 1/8/19, 7:03 PM, "Masahiko Sawada" wrote:
> > > Attached the updated version patch incorporated all comments I got.
> >
> > Thanks for the new patch!
> >
> >
Hi David,
On Thu, Jan 10, 2019 at 4:02 PM, David Rowley wrote:
> 3. I wonder if there's a better way to handle what
> build_dummy_partition_rel() does. I see the child's relid to the
> parent's relid and makes up a fake AppendRelInfo and puts it in the
> parent's slot. What's going to happen
On 01/10/19 23:48, Chapman Flack wrote:
> On 12/30/18 22:23, Chapman Flack wrote:
> (3) seems to be supported by (the only) precedent, the "Limits and
> Compatibility" sect3 within functions-posix-regexp.
>
> So, absent objection, I'll work on a Limits and Compatibility sect2
> within
On Fri, Jan 11, 2019 at 11:05 AM Andres Freund wrote:
> Hi,
>
> On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> > On Tue, Dec 18, 2018 at 11:17 PM Andres Freund
> wrote:
> > > Another would be to be aggressive in renaming, and deconflict by
> > > renaming functions like
On Wed, 9 Jan 2019 at 14:30, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Jan 8, 2019 at 6:34 PM Andres Freund wrote:
> >
> > On 2019-01-08 11:30:56 +0100, Peter Eisentraut wrote:
> > > On 08/01/2019 00:56, Andres Freund wrote:
> > > > A patch at [2] adds display of a table's access
On 2019/01/11 11:21, Etsuro Fujita wrote:
> (2019/01/10 21:23), Amit Langote wrote:
>> On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
>> wrote:
>>> Though this will solve a problem for performance when partition-wise
>>> join is not possible, we still have the same problem when
>>>
On 12/30/18 22:23, Chapman Flack wrote:
> I would like to add material to the manual, detailing the differences
> between the XPath 1.0 language supported in PG, and the XQuery/XPath 2.0+
> expected by the standard.
> ...
> I have thought of:
> ...
> 3. A sect2 at the very end of functions-xml,
Fujita-san,
On 2019/01/10 15:07, Etsuro Fujita wrote:
> Amit-san,
>
> (2019/01/10 10:41), Amit Langote wrote:
>> On 2019/01/09 20:20, Etsuro Fujita wrote:
>>> I like your patch in general. I think one way to address Ashutosh's
>>> concerns would be to use the consider_partitionwise_join flag:
Hi,
The pluggable storage patchset has a large struct full of callbacks, and
a bunch of wrapper functions for calling those callbacks. While
starting to polish the patchset, I tried to make the formatting nice.
By default pgindent yields formatting like:
/*
* API struct for a table AM. Note
Andres Freund writes:
> On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
>> Does the project have an established view on non-ASCII names in
>> sources or docs?
>> AFAICS [1], the name of the algorithm may be Ryū.
> I think it'd be a really bad idea to start having non-ascii
> filenames, and I
Hi,
On 2019-01-10 23:02:01 -0500, Chapman Flack wrote:
> Does the project have an established view on non-ASCII names in
> sources or docs?
>
> AFAICS [1], the name of the algorithm may be Ryū.
I think it'd be a really bad idea to start having non-ascii
filenames, and I quite doubt that I'm
Does the project have an established view on non-ASCII names in
sources or docs?
AFAICS [1], the name of the algorithm may be Ryū.
-Chap
[1] https://dl.acm.org/citation.cfm?id=3192369
Donald Dong writes:
> I created some empty tables and run ` EXPLAIN ANALYZE` on `SELECT * `. I found
> the results have different row numbers, but the tables are all empty.
This isn't a terribly interesting case, since you've neither loaded
any data nor vacuumed/analyzed the table, but ...
> I
On Thu, 10 Jan 2019 at 21:41, Amit Langote
wrote:
> Here's v12, which is more or less same as v11 but with the order of
> patches switched so that the code movement patch is first. Note that the
> attached v12-0001 contains no functional changes (but there's tiny note in
> the commit message
Thank you for the great explanation!
> On Jan 10, 2019, at 7:48 PM, Andrew Gierth
> wrote:
>
>> "Donald" == Donald Dong writes:
>
> Donald> Hi,
> Donald> I created some empty tables and run ` EXPLAIN ANALYZE` on
> Donald> `SELECT * `. I found the results have different row numbers,
>
> "Donald" == Donald Dong writes:
Donald> Hi,
Donald> I created some empty tables and run ` EXPLAIN ANALYZE` on
Donald> `SELECT * `. I found the results have different row numbers,
Donald> but the tables are all empty.
Empty tables are something of a special case, because the planner
Thomas Munro writes:
> On Fri, Jan 11, 2019 at 12:58 PM Andres Freund wrote:
>> A number of postgres files have sections like heapam's
>> * INTERFACE ROUTINES
>>
>> They're often out-of-date, and I personally never found them to be
>> useful. A few people, including yours truly, have been
On Thu, Jan 10, 2019 at 12:11 PM Haribabu Kommi
wrote:
> On Thu, Jan 10, 2019 at 2:32 PM Amit Kapila wrote:
>>
>> I am happy with this patch now, attached is the new version of the
>> patch where I have slightly modified the commit message, see if that
>> looks fine to you. I will push this
Rebased this patch onto current master. No functional changes; just
fixed up the copyright dates and a couple of stray missing UINT64CONSTs.
Regression tests still fail because how to fix them depends on the
issues below. Likewise docs are not changed yet for the same reason.
Decisions that need
Hi,
Thanks for the comments, and I'm sorry for the late reply.
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Friday, January 11, 2019 7:04 AM
> > Robert Haas writes:
> > On Fri, Dec 21, 2018 at 11:50 AM Tom Lane wrote:
> >> A smaller-footprint way to fix the immediate problem might be
(2019/01/10 21:23), Amit Langote wrote:
On Thu, Jan 10, 2019 at 6:49 PM Ashutosh Bapat
wrote:
Though this will solve a problem for performance when partition-wise join is
not possible, we still have the same problem when partition-wise join is
possible. And that problem really happens
2019年1月11日(金) 5:52 Robert Haas :
>
> On Wed, Jan 9, 2019 at 12:44 AM Kohei KaiGai wrote:
> > So, is it sufficient if set_rel_pathlist_hook is just relocated in
> > front of the generate_gather_paths?
> > If we have no use case for the second hook, here is little necessity
> > to have the
Sorry, I hadn't read this email before sending my earlier "thank you for
committing" email.
On 2019/01/11 6:47, David Rowley wrote:
> On Fri, 11 Jan 2019 at 06:56, Alvaro Herrera wrote:
>> Pushed 0001 with some minor tweaks, thanks.
>
> Thanks for pushing. I had looked at 0001 last night and
On Fri, Jan 11, 2019 at 09:53:16AM +0900, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 05:44:34PM -0300, Alvaro Herrera wrote:
> > It has definitely started, at least for me :-)
>
> Yes, there is no point in extending or delaying it.
>
> > We're going to have a bit of a triage session in the
On 2019/01/10 19:27, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 05:58:10PM +0900, Amit Langote wrote:
>> The reason I started this thread is due to this Stack Overflow question:
>>
>>
On 2019/01/11 2:56, Alvaro Herrera wrote:
> On 2019-Jan-10, Amit Langote wrote:
>
>> Here's v12, which is more or less same as v11 but with the order of
>> patches switched so that the code movement patch is first. Note that the
>> attached v12-0001 contains no functional changes (but there's
On Fri, Jan 11, 2019 at 10:09:04AM +0900, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 04:52:53PM -0800, Andres Freund wrote:
> > It's a minor simplification for code that's existed for quite a
> > while. Not worth it.
>
> Meh, I disagree for the ready_to_display part as it has been around
>
From: Robert Haas [mailto:robertmh...@gmail.com]
> My theory is that the number of wait events is NOT useful information,
> or at least not nearly as useful the results of a sampling approach.
> The data that LWLOCK_STATS produce are downright misleading -- they
> lead you to think that the
On Thu, Jan 10, 2019 at 04:52:53PM -0800, Andres Freund wrote:
> It's a minor simplification for code that's existed for quite a
> while. Not worth it.
Meh, I disagree for the ready_to_display part as it has been around
for a long time:
commit: 9ed551e0a4fdb046d8e5ea779adfd3e184d5dc0d
author:
On Sat, Dec 29, 2018 at 6:50 PM David Rowley
wrote:
> > Areas of extension: (given index `(a, b, c)`) include `a = 1 and b in
> > (...) order by c` and `a in (...) and b = 1 order by c` (and further
> > similar derivations with increasing numbers of equality quals).
>
> I don't quite understand
On Thu, Jan 10, 2019 at 04:41:47PM -0800, Andres Freund wrote:
> I still think this whole direction of accessing the GUC in walreceiver
> is a bad idea and shouldn't be pursued further. There's definite
> potential for startup process and WAL receiver having different states
> of GUCs, the code
Hi,
On 2019-01-11 09:34:28 +0900, Michael Paquier wrote:
> On Thu, Jan 10, 2019 at 02:20:27PM +0300, Sergei Kornilov wrote:
> > Thank you, patch looks good for me.
>
> Thanks Sergei for the review. I have been looking at the patch again
> this morning with a fresh set of eyes and the thing
On Thu, Jan 10, 2019 at 02:20:27PM +0300, Sergei Kornilov wrote:
> Thank you, patch looks good for me.
Thanks Sergei for the review. I have been looking at the patch again
this morning with a fresh set of eyes and the thing looks in a
committable shape (the GUC values for NULL checks are a bit
On Thu, Jan 10, 2019 at 8:42 PM, Robert Hass wrote:
Thanks for comments.
>or at least not nearly as useful the results of a sampling approach.
I agree with your opinion.
Because it can't be asserted that the wait event is a bottleneck just because
the number of wait event is large.
The same
On Fri, Jan 11, 2019 at 12:58 PM Andres Freund wrote:
> A number of postgres files have sections like heapam's
>
> * INTERFACE ROUTINES
> * relation_open - open any relation by relation OID
> * relation_openrv - open any relation specified by a RangeVar
> * relation_close -
Hi,
On 2018-12-19 14:21:29 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2018 at 11:17 PM Andres Freund wrote:
> > Another would be to be aggressive in renaming, and deconflict by
> > renaming functions like heap_create[_with_catalog] etc to sound more
> > accurate. I think that has some appeal,
Hi,
A number of postgres files have sections like heapam's
* INTERFACE ROUTINES
* relation_open - open any relation by relation OID
* relation_openrv - open any relation specified by a RangeVar
* relation_close - close any relation
* heap_open - open a heap
John Naylor writes:
> Thought I'd ping...
Sorry, I'd not been paying attention to this thread.
> On Sat, Dec 15, 2018 at 12:02 AM Amit Kapila wrote:
>> As pointed out by John Naylor [1], it seems during bootstrap mode, we
>> are always creating FSM files which are not required. In commit's
>>
On Thu, Jan 10, 2019 at 1:15 PM Robert Haas wrote:
> I feel like there has been some other thread where this was discussed,
> but I can't find it right now. I think that the "query construction"
> logic in transformMergeStmt is fundamentally the wrong way to do this.
> I think several others
Hi!
I've couple more notes regarding this patch.
1) There are two loops over scan key determining scan strategy:
existing loop in _bt_first(), and in new function
_bt_select_knn_search_strategy(). It's kind of redundant that we've
to process scan keys twice for knn searches. I think scan keys
Thought I'd ping...
(sorry for the top post)
On Sat, Dec 15, 2018 at 12:02 AM Amit Kapila wrote:
>
> As pointed out by John Naylor [1], it seems during bootstrap mode, we
> are always creating FSM files which are not required. In commit's
> b9d01fe288 and 3908473c80, we have added some code
On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila wrote:
> Thanks, Mithun for performance testing, it really helps us to choose
> the right strategy here. Once John provides next version, it would be
> good to see the results of regular pgbench (read-write) runs (say at
> 50 and 300 scale factor) and
Robert Haas writes:
> On Fri, Dec 21, 2018 at 11:50 AM Tom Lane wrote:
>> A smaller-footprint way to fix the immediate problem might be to
>> change the values of DEFAULT_INEQ_SEL and friends so that they're
>> even less likely to be matched by accident. That is, instead of
>>
On Fri, 11 Jan 2019 at 06:56, Alvaro Herrera wrote:
> Pushed 0001 with some minor tweaks, thanks.
Thanks for pushing. I had looked at 0001 last night and there wasn't
much to report, just:
v12 0001
1. I see you've moved translate_col_privs() out of prepunion.c into
appendinfo.c. This required
Hello Alvaro,
There's a lot of the new code in pgbench that can be simplified if we
remove \cset.
I'm not very happy with the resulting syntax, but IMO the feature is
useful. My initial design was to copy PL/pgSQL "into" with some "\into"
orthogonal to \; and ;, but the implementation was
On Thu, Jan 3, 2019 at 2:11 AM Pavan Deolasee wrote:
> On Tue, Nov 27, 2018 at 4:48 PM Pavan Deolasee
> wrote:
>> In the meanwhile, I am posting a rebased version.
>
> Another rebase on the current master.
I feel like there has been some other thread where this was discussed,
but I can't find
Hello Tom,
So who needs that? Just merge the queries, if it's so important that
you avoid multiple round trips.
Pgbench is about testing (measuring) performance in various settings and
realistic scenarii: queries prepared or not, possible combined, and so on.
As postgres allows to send
Julien Demoor writes:
> [ postgres-notify-all-v8.patch ]
I took a quick look through this. A few comments:
* I find the proposed syntax extension for NOTIFY to be fairly bizarre;
it's unlike the way that we handle options for any other utility
statement. It's also non-orthogonal, since you
On Wed, Jan 9, 2019 at 12:44 AM Kohei KaiGai wrote:
> So, is it sufficient if set_rel_pathlist_hook is just relocated in
> front of the generate_gather_paths?
> If we have no use case for the second hook, here is little necessity
> to have the post_rel_pathlist_hook() here.
> (At least, PG-Strom
On Fri, Dec 21, 2018 at 11:50 AM Tom Lane wrote:
> A smaller-footprint way to fix the immediate problem might be to
> change the values of DEFAULT_INEQ_SEL and friends so that they're
> even less likely to be matched by accident. That is, instead of
> 0., use 0.342 or
On 2019-Jan-10, Tom Lane wrote:
> David Fetter writes:
> > We're 10 days into the Commitfest, the first few having been the new
> > year, with people maybe paying attention to other things.
> > I'd like to propose extending this CF by some period, maybe as long
> > as ten days, so people get all
On Thu, Dec 20, 2018 at 8:48 PM Yotsunaga, Naoki
wrote:
> If so, is not that the number of wait events is useful information?
My theory is that the number of wait events is NOT useful information,
or at least not nearly as useful the results of a sampling approach.
The data that LWLOCK_STATS
David Fetter writes:
> We're 10 days into the Commitfest, the first few having been the new
> year, with people maybe paying attention to other things.
> I'd like to propose extending this CF by some period, maybe as long
> as ten days, so people get all the opportunities they might have had
> if
Folks,
We're 10 days into the Commitfest, the first few having been the new
year, with people maybe paying attention to other things.
I'd like to propose extending this CF by some period, maybe as long
as ten days, so people get all the opportunities they might have had
if it had started on
On 2019-Jan-10, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jan-10, Tom Lane wrote:
> >> This \cset thing seem like an incredibly badly thought out kluge.
> >> What is its excuse to live?
>
> > The reason is that you can set variables from several queries in one
> > network trip.
>
>
Alvaro Herrera writes:
> On 2019-Jan-10, Tom Lane wrote:
>> This \cset thing seem like an incredibly badly thought out kluge.
>> What is its excuse to live?
> The reason is that you can set variables from several queries in one
> network trip.
So who needs that? Just merge the queries, if it's
Alvaro Herrera writes:
> Now let's see how the buildfarm likes this ...
This \cset thing seem like an incredibly badly thought out kluge.
What is its excuse to live?
regards, tom lane
On 2019-Jan-10, Amit Langote wrote:
> Here's v12, which is more or less same as v11 but with the order of
> patches switched so that the code movement patch is first. Note that the
> attached v12-0001 contains no functional changes (but there's tiny note in
> the commit message mentioning the
On Wed, 26 Dec 2018 at 22:09, Tomas Vondra wrote:
>
> Attached is an updated version of the patch - rebased and fixing the
> warnings reported by Thomas Munro.
>
Here are a few random review comments based on what I've read so far:
On the CREATE STATISTICS doc page, the syntax in the new
On 2019-Jan-10, Fabien COELHO wrote:
> However, I switched "pg_free" to "termPQExpBuffer", which seems more
> appropriate, even if it just does the same thing. I also ensured that
> prefixes are allocated & freed. I've commented about expr which is not
> freed.
Oops, of course, thanks.
> I'm
On Fri, Jan 11, 2019 at 12:58 AM Tom Lane wrote:
> Dean Rasheed writes:
> > The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
> > message on 8 Jan with an initial proposed patch and my response later
> > that day both CC'ed -hackers and seem to have been rejected, and so
> >
Dean Rasheed writes:
> Has the policy on cross-posting to multiple lists been hardened recently?
Not that I've heard of.
> The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
> message on 8 Jan with an initial proposed patch and my response later
> that day both CC'ed -hackers
On 1/10/19 4:20 PM, Dean Rasheed wrote:
> On Wed, 9 Jan 2019 at 15:40, Tomas Vondra
> wrote:
>> On 1/8/19 3:18 PM, Dean Rasheed wrote:
>>> So actually, the estimate for a group of values will be either the MCV
>>> item's frequency (if the MCV item is kept), or (roughly) the MCV
>>> item's
On Wed, 9 Jan 2019 at 15:40, Tomas Vondra wrote:
> On 1/8/19 3:18 PM, Dean Rasheed wrote:
> > So actually, the estimate for a group of values will be either the MCV
> > item's frequency (if the MCV item is kept), or (roughly) the MCV
> > item's base_frequency (if the MCV item is not kept). That
Hi
čt 10. 1. 2019 v 14:00 odesílatel Arthur Zakirov
napsal:
> Hello Pavel,
>
> On 09.11.2018 07:07, Pavel Stehule wrote:
> > I used your patch and append regress tests. I checked the result against
> > Oracle.
>
> I checked the patch with Chap cases. The patch fixes handling of
> boolean,
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> Stephen Frost wrote:
> > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > > Clearly, not having to do that at all is better, but if this is all
> > > there is to it, then I'm confused by the characterizations of how
Stephen Frost wrote:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> > Clearly, not having to do that at all is better, but if this is all
> > there is to it, then I'm confused by the characterizations of how awful
> > and terrible this feature is and how we must rush to remove
Hello Pavel,
On 09.11.2018 07:07, Pavel Stehule wrote:
I used your patch and append regress tests. I checked the result against
Oracle.
I checked the patch with Chap cases. The patch fixes handling of
boolean, number types which mentioned in the wiki.
I have a few comments related to the
On Thu, Jan 10, 2019 at 01:10:16PM +0300, Sergei Kornilov wrote:
> Without both ready_to_display and cleaning in RequestXLogStreaming
> we do not show outdated PrimaryConnInfo in case walreceiver just
> started, but does not connected yet? While waiting walrcv_connect
> for example.
Good point.
On Thu, Jan 10, 2019 at 05:58:10PM +0900, Amit Langote wrote:
> The reason I started this thread is due to this Stack Overflow question:
>
> https://stackoverflow.com/questions/53554727/logical-replication-and-declarative-partitioning-in-postgresql-11
>
> So, it appears that there may be an
Hello
> I was just double-checking the code, and it is possible to remove the
> part from RequestXLogStreaming() which sets slotname and conninfo to
> '\0', so I removed that part from my local branch to simplify the
> code.
Without both ready_to_display and cleaning in RequestXLogStreaming we
Has the policy on cross-posting to multiple lists been hardened recently?
The "Crash on ALTER TABLE" thread [1] started on -bugs, but Andrew's
message on 8 Jan with an initial proposed patch and my response later
that day both CC'ed -hackers and seem to have been rejected, and so
are missing from
On Thu, Jan 10, 2019 at 7:12 AM Amit Langote
wrote:
> Fujita-san,
>
> On 2019/01/09 20:20, Etsuro Fujita wrote:
> > (2019/01/09 9:30), Amit Langote wrote:
> >> So, while the patch at [1] can take care of this issue as I also
> mentioned
> >> upthread, I was trying to come up with a solution that
On Wed, 9 Jan 2019 at 23:24, Andrew Dunstan
wrote:
> Here's another attempt. For the rewrite case it kept the logic of the
> previous patch to clear all the missing attributes, but if we're not
> rewriting we reconstruct the missing value according to the new type
> settings.
>
Looks good to me.
On Thu, 10 Jan 2019 at 21:41, Amit Langote
wrote:
> In the v13 that I will try to post tomorrow, I will have hopefully
> addressed David's and Imai-san's review comments. Thank you both!
I'd been looking at v11's 0002 and started on 0003 too. I'll include
my notes so far if you're about to send
Hello Alvaro,
Here are my proposed final changes.
Thanks again for improving the patch!
I noticed that you were allocating the prefixes for all cases even when
there were no cset/gset in the command; I changed it to delay the
allocation until needed.
Ok, why not.
I also noticed you
Hi,
On 2019/01/10 17:46, Arkhena wrote:
>> Your rewritten version is perhaps fine, although I remain a bit concerned
>> that some users might be puzzled when they see this error, that is, if
>> they interpret the message as "it's impossible to use a partitioned table
>> as logical replication
> > On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
> >> I can see your point, though I would stick with
> >> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
> >> because the code is intended to not work on anything else than plain
> >> tables, at least now.
>
On 2019/01/10 14:25, Michael Paquier wrote:
> On Tue, Jan 08, 2019 at 04:42:35PM +0900, Michael Paquier wrote:
>> I can see your point, though I would stick with
>> ERRCODE_WRONG_OBJECT_TYPE for consistency with the existing code and
>> because the code is intended to not work on anything else
Hi!
> 8 янв. 2019 г., в 22:57, Alexander Korotkov
> написал(а):
>
> On Tue, Jan 8, 2019 at 1:06 AM Stephen Frost wrote:
>> All the entries are marked with '2018' to indicate they were pulled from
>> last year. If the project from last year is still relevant, please
>> update it to be '2019'
84 matches
Mail list logo
