Re: Getting to 9.3 beta - Mailing list pgsql-hackers

On 2013-03-29 12:28:59 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-03-29 10:15:42 -0400, Bruce Momjian wrote:
> >> What is a reasonable timeframe to target for completion of these items?
>
> > Here's my take on it:
>
> Thanks for annotating these!  I've commented on the ones where I
> come to a different conclusion:
>
> > - replace plugins directory with GUC
> >   Peter has agreed to boot it to the next fest afaics
> >   (515357F4.6000307@gmx.net)
> >   => move (done)
>
> It looks to me more like a RWF situation, since Peter has evidently lost
> interest in committing this feature at all.  So I marked it that way.

Yea, after a second reading of Peter's email I agree.

> > - Patch to compute Max LSN of Data Pages:
> >   I *personally* don't really see a point in including it in postgres,
> >   there doesn't really seem to be any real demand met by the tool
> >   => reject?
>
> Not sure.  It certainly hasn't drawn that much enthusiasm on the list,
> but it strikes me as the sort of thing that when you need it you really
> need it.  It would be interesting to hear opinions about it from people
> who deal with data recovery situations on a regular basis.

I only have done so infrequently, but I guess my real problem is that I
can't see it being all that helpful in such a situation. If you've lost
pg_xlog - otherwise there doesn't seem to be much use in this - you can just use
pg_resetxlog to set an insanely high lsn and then dump & restore the
database. The only reason to use something more complex than this is if
you want to continue using the cluster which seems like a really bad
idea.
Am I missing a usecase here?

I guess it can be useful as a template utility to start hacking on for
more complex scenarios, but I don't think that warrants /contrib.

> > - REINDEX CONCURRENTLY:
> >   Imo pretty close to being comittable and pretty useful, but it got
> >   redesigned pretty late and it mostly had review from me and fujii and
> >   it could use a bit more input
> >   => unclear
>
> I think this really has no hope of being bulletproof until we have
> MVCC-based catalog scans.  The work up to now has been good exploratory
> effort, but it's not going to be committable without that
> infrastructure, IMHO anyway.

I think its fair not to commit it in 9.3, the patch came late and has
undergone significant issues since then. And there are some things in it
I am not sure about yet.
But I am not sure why its only acceptable with MVCC scans? Sure, it
takes an exclusive lock for a very short time when switching the
relations, but thats still a huge step up over the status quo:
* toast indexes currently cannot be created/dropped at all. So you have to reindex the table which will need to be
lockedover the whole time.
 
* you currently cannot replace indexes that are referenced by foreign keys without doing manual catalog hackery which
isdefinitely unsafe
 
* you cannot create constraints that use an index concurrently. Parts of that is emulatable by creating the constraint
withan existing index, but that doesn't help e.g. for exclusion constraints.
 
* there's no convenient way to issue CREATE INDEX CONCURRENLTY new_index; DROP INDEX CONCURRENTLY old_index; RENAME
new_indexold_index; for all indexes.
 

The last alone imnsho is already a good enough usecase for the patch.

Also, the part that deals with the (locked) switch of the relfilenodes
is a really small part of the patch, improving that later is not going
to throw away much.

Imo having this would have made
e.g. beb850e1d873f8920a78b9b9ee27e9f87c95592f way much less painful. We
(as in 2ndq) had to write scripts for customers to deal with this in a
remotely sane manner. And those were *ugly*.

> > - psql watch
> >   Waiting on author since 4 days
> >   => wait or boot?
>
> If there is agreement on the basic design of the feature, ie
> "\watch [n]" as a repeating version of "\g", it seems to me that
> this could be fixed and committed in a day or less.  I'd be willing
> to look at it sometime next week.

Cool.

> > - transforms:
> >   I am not sure what solution is proposed for the dependency issue
> >   between shared objects.
> >   There also hasn't been code level review for a while...
> >   => unclear
>
> Needs to be moved; no way this is ready in the next week or two.

Good. I haven't looked at it in a long time and nobody else did, so I
just wasn't sure.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services