Horton

Re: Bugs/slowness inserting and indexing cubes

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jay Levitt <jay.levitt@gmail.com>, pgsql-hackers@postgresql.org
Date: 2012-02-08T19:38:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_dump: Further reduce reliance on global variables.

  2. Fix postmaster to attempt restart after a hot-standby crash.

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 8, 2012 at 2:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ISTM there are two ways we could fix this:
>> 
>> 1. Introduce a duplicative test at the start of gistbuild().
>> 
>> 2. Rearrange the order of operations in index_build() so that the init
>> fork is made first.
>> 
>> Both of these are kinda ugly, but #2 puts the ugliness into someplace
>> that shouldn't have to know about it, and furthermore someplace that's
>> unlikely to get reverted if/when gist is fixed to not have this problem.
>> So I think I favor #1. Other opinions anyone?

> I don't think I understand your object to #2.  It appears to be a
> trivial rearrangement?

Yeah, but then we are wiring into index_build the idea that ambuildempty
is more important, or more likely to throw an error, or something, than
ambuild is.  It seems weird.  And fragile, since somebody could decide
to re-order those two steps again for reasons unrelated to gist.
Basically, I think this problem is gist's to deal with and so that's
where the fix should be.

			regards, tom lane