On Thu, Oct 1, 2009 at 5:02 PM, Tom Lane wrote:
> APseudoUtopia writes:
>>> Here's what happened:
>>>
>>> $ vacuumdb --all --full --analyze --no-password
>>> vacuumdb: vacuuming database "postgres"
>>> vacuumdb: vacuuming database "web_main"
>>> vacuumdb: vacuuming of database "web_main" failed:
Teodor Sigaev writes:
> ginHeapTupleFastCollect and ginEntryInsert checked tuple's size for
> TOAST_INDEX_TARGET, but ginHeapTupleFastCollect checks without one
> ItemPointer,
> as ginEntryInsert does it. So ginHeapTupleFastCollect could produce a tuple
> which 6-bytes larger than allowed by g
Teodor Sigaev writes:
>> Will you apply this, or do you want me to?
> I'm not able to provide a good error message in good English :(
OK, I'll take care of it later today.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make c
Looks reasonable, although since the error is potentially user-facing
I think we should put a bit more effort into the error message
(use ereport and make it mention the index name, at least --- is there
any other useful information we could give?)
Only sizes as it's done in BTree, I suppose.
W
Teodor Sigaev writes:
> Patch removes checking of TOAST_INDEX_TARGET and use checking only by
> GinMaxItemSize which is greater than TOAST_INDEX_TARGET. All size's check is
> now
> in GinFormTuple.
Looks reasonable, although since the error is potentially user-facing
I think we should put a bi
APseudoUtopia writes:
Here's what happened:
$ vacuumdb --all --full --analyze --no-password
vacuumdb: vacuuming database "postgres"
vacuumdb: vacuuming database "web_main"
vacuumdb: vacuuming of database "web_main" failed: ERROR: б═huge tuple
PostgreSQL 8.4.0 on i386-portbld-freebsd7.2, comp
APseudoUtopia writes:
>> Here's what happened:
>>
>> $ vacuumdb --all --full --analyze --no-password
>> vacuumdb: vacuuming database "postgres"
>> vacuumdb: vacuuming database "web_main"
>> vacuumdb: vacuuming of database "web_main" failed: ERROR: Â huge tuple
> PostgreSQL 8.4.0 on i386-portbld-
Scott Marlowe escribió:
> Wow, that's pretty slow. I'd assumed it was a semi-automated process
> and the new version would be out now, 3 weeks later. At least look
> through the release notes to see if any mention is made of this bug
> being fixed in 8.4.1 I guess.
Both files on which that erro
On Thu, Oct 1, 2009 at 2:27 PM, APseudoUtopia wrote:
> On Thu, Oct 1, 2009 at 4:21 PM, Scott Marlowe wrote:
>> On Thu, Oct 1, 2009 at 1:12 PM, APseudoUtopia
>> wrote:
>>
>>> Sorry, I failed to mention:
>>>
>>> PostgreSQL 8.4.0 on i386-portbld-freebsd7.2, compiled by GCC cc (GCC)
>>> 4.2.1 20070
On Thu, Oct 1, 2009 at 4:21 PM, Scott Marlowe wrote:
> On Thu, Oct 1, 2009 at 1:12 PM, APseudoUtopia wrote:
>
>> Sorry, I failed to mention:
>>
>> PostgreSQL 8.4.0 on i386-portbld-freebsd7.2, compiled by GCC cc (GCC)
>> 4.2.1 20070719 [FreeBSD], 32-bit
>
> Have you tried updating to 8.4.1 to see
On Thu, Oct 1, 2009 at 1:12 PM, APseudoUtopia wrote:
> Sorry, I failed to mention:
>
> PostgreSQL 8.4.0 on i386-portbld-freebsd7.2, compiled by GCC cc (GCC)
> 4.2.1 20070719 [FreeBSD], 32-bit
Have you tried updating to 8.4.1 to see if that fixes the problem?
--
Sent via pgsql-general mailing
On Thu, Oct 1, 2009 at 3:10 PM, APseudoUtopia wrote:
> Hey list,
>
> After some downtime of my site while completing rigorous database
> maintenance, I wanted to make sure all the databases were fully
> vacuumed and analyzed. I do run autovacuum, but since I made several
> significant changes, I w
Hey list,
After some downtime of my site while completing rigorous database
maintenance, I wanted to make sure all the databases were fully
vacuumed and analyzed. I do run autovacuum, but since I made several
significant changes, I wanted to force a vacuum before I brought my
site back online.
He
13 matches
Mail list logo
