Richard Evans wrote:
> 1. configure.in detecting the target system versions of dllwrap,
> dlltool, windres and ar
> 2. in various makefiles, checking BUILDOS not PORTNAME when deciding
> whether to use 'pwd -W' or just 'pwd'
> 3. Using the local system's 'zic' command when cross compiling, add
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Apparently, rd_indexattr needs to get cleared someplace where it
> isn't being cleared right now. I'm sure this is related to the
> fancy dance we do for pg_class reindexing, but not sure yet where
> to fix it.
Yeah, doing the equivalent of this in gdb se
Gregory Stark <[EMAIL PROTECTED]> writes:
> Uhm. Is it possible we're mistakenly doing a HOT update because we're lying
> about what indexes exist?
Yup, exactly. Here's my proposed fix...
regards, tom lane
Index: src/backend/catalog/index.c
==
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Also, I can still reproduce it with just REINDEX TABLE pg_class instead
> of REINDEX DATABASE.
Ah, I had tried just a reindex xxx but not a reindex pg_class.
* reindex_index will attempt to update the pg_class rows for the
relation
* an
I wrote:
> What I suspect is we've broken the logic that manages REINDEX applied to
> pg_class itself.
Hm, this is a HOT bug. (Unless the OP found it on something older
than 8.3, in which case we might have more than one issue involved.)
What I'm seeing is that when heap_update checks to see if t
Gregory Stark <[EMAIL PROTECTED]> writes:
> On the other hand the problem does not occur if the CREATE TABLE is in the
> same session. Nor if the REINDEX DATABASE is skipped.
It appears that you have to do the RENAME TABLE in the same session as
the REINDEX DATABASE. Furthermore, the failure then
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> > I could not reproduce it here, but didn't try very hard.
>>
>> Did you try running the script he provided? It happened for me first try.
>
> Yep. No luck. I didn't try changing the args in generate_series though.
>
> How many CPUs are you runnin
