remaining open items - Mailing list pgsql-hackers

We've got a few open items remaining at
https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items - we should
try to get rid of them.  Of the 8 items there, 3 are documentation
issues.  It looks to me like one of those is for Stephen to deal with,
one for Andres, and one for Alvaro.  Is there any reason we can't get
those taken care of and move on?

On the remaining five issues:

- Refactoring speculative insertion with unique indexes a little.
Andres seems to think this shouldn't be an open issue, while Peter
thinks maybe it should be, or at least that's my imperfect executive
summary.  Heikki isn't sure he agrees with all of the changes.  I'm
not very clear on whether this is a new feature, a bug fix,
beautification, or something else.  What would happen if we didn't do
anything at all?

- Oversize item computation needs more testing (c.f. ereport(ERROR)
calls in brin_getinsertbuffer).  This is pretty vague, and there's no
thread linked.  If there's a stability issue here, presumably it falls
to Alvaro to fix it.  But I don't know who added this item or what
really needs to be done.

- DDL deparsing testing module should have detected that transforms
were not supported, but it failed to notice that.  There's no thread
linked to this one either, but the description of the issue seems
clear enough.  Alvaro, any chance that you can, as the comment says,
whack it until it does?

- Foreign join pushdown vs EvalPlanQual.  Attempting to use the new
foreign join pushdown support can crash the server if the query has
locking clauses (or possibly if it's an UPDATE localtab FROM remotetab
type of query, though I don't have a test case for that).  There's
been a lot of discussion about how to fix this, but unless Tom gets
involved, I don't see this getting fixed in time for 9.5, because I
don't know exactly how to fix it and I don't think anyone else does
either.  I have some ideas and I think those ideas are slowly getting
better, but the reality is that if I'd realized this issue existed, I
would not have committed the join pushdown support to 9.5.  I didn't,
and that was a screw-up on my part.   I don't know what to recommend
here: the choices seem to be (a) rip out all the foreign join pushdown
support from 9.5, or (b) leave it in and accept that trying to use it
may fail in some cases.  Since postgres_fdw doesn't have any support
for this anyway, it's not actively hurting anyone.  But it's still bad
that it's broken like this.

- Strange behavior on track_commit_timestamp.  As I've said on the
thread, I think that the idea that the redo routines care about the
value of the GUC at the time redo is performed (rather than at the
time redo is generated), is broken.  Fujii's latest post provides some
examples of how this creates weird results.  I really think this
should be changed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company