Ron Mayer <[EMAIL PROTECTED]> writes:
> logs2=# select pgstattuple('e_ip_full');
> NOTICE: physical length: 293.84MB live tuples: 1697755 (169.26MB, 57.60%)
> dead tuples: 0 (0.00MB, 0.00%) free/reusable space: 110.84MB (37.72%)
> overhead: 4.67%
> pgstattuple
> -
>0
> (1
Is there any way we can warn users when their fsm parameters are too
small?
---
Tom Lane wrote:
> Ron Mayer <[EMAIL PROTECTED]> writes:
> > logs2=# select pgstattuple('e_ip_full');
> > NOTICE: physical length: 293.84MB liv
Anders Hammarquist wrote:
>>[EMAIL PROTECTED] writes:
>>
>>>If a byte string that is not valid unicode is inserted into a bytea
>>>column, analyze will fail unless the data was tagged as bytea in the
>>>insert.
>>
>>Your example produces no failure for me. You'd better be more specific
>>about wh
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there any way we can warn users when their fsm parameters are too
> small?
Not until we understand what too small is :-( If anyone's undertaken
any experiments to figure out what an appropriate FSM size setting is,
I'm not aware of it.
The default
Joe Conway <[EMAIL PROTECTED]> writes:
> (gdb) bt
> #0 pg_verifymbstr (mbstr=0x837a698 "42", len=2) at wchar.c:541
> #1 0x08149c26 in textin (fcinfo=0xbfffeca0) at varlena.c:191
> #2 0x08160579 in DirectFunctionCall1 (func=0x8149c00 ,
> arg1=137864856) at fmgr.c:657
> #3 0x080bbffa in update_
Could we somehow track how many pages we _couldn't_ get into the free
space map, then when the map is empty _and_ we find we have found there
are some pages that we couldn't store during the last vacuum, we throw a
message to the server logs? (Just thinnking out loud.)
-
Tom Lane wrote:
> Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> in order to produce a textual representation of the most common value
> in the BYTEA column, and apparently textin feels that the string
> generated by byteaout is not legal text. While Joe says that the
> pro
Joe Conway wrote:
> Tom Lane wrote:
> > Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> > in order to produce a textual representation of the most common value
> > in the BYTEA column, and apparently textin feels that the string
> > generated by byteaout is not legal text. W
Bruce Momjian wrote:
> Does this mean we don't have to esacpe >0x7f when inputting bytea
> anymore?
I seem to remember that bytea data was run through the multibute code
for some reason, and I don't recall seeing that changed. ISTM that we
shouldn't force bytea thought multibyte functions at al
