Re: [BUGS] Bug #467: Can't insert a value of 0 (zero) into a Bytea
This is fixed in the current CVS tree.
> Billy G. Allie ([EMAIL PROTECTED]) reports a bug with a severity of 2
> The lower the number the more severe it is.
>
> Short Description
> Can't insert a value of 0 (zero) into a Bytea type.
>
> Long Description
> It does not zeem possible to insert a value of zero (0) into a bytea type. Also,
>using '\134' (the octal code for a backslash) causes byteain() to generate an error
>message.
>
> As a side issue, how can one tell a backslash followed by 3 digits (four bytes of
>data) from an encoded byte of data? It seems to me that byteaout() should always
>output an octal escape sequence per byte, even if the character is printable. That
>way the result is unambiguous in meaning (even if it is wasteful of bytes).
>
> Sample Code
> bga=# select version();
> version
> ---
> PostgreSQL 7.1.3 on i586-sco-sysv5uw7.1.1, compiled by cc
> (1 row)
> bga=# create table test6 (a bytea);
> CREATE
> bga=# insert into test6 values('\001\002\354ab\000de\004');
> INSERT 163734 1
> bga=# select * from test6;
>a
>
> \001\002\354ab
> (1 row)
>
> Note: It is possible to workaround (i.e. fake out postgresSQL) by inserting a
>backslash followsd by 3 zeros (a total of 4 bytes) into the bytea type. For example:
>
> bga=# insert into test6 values('\001\002\354ab\\000de\004');
> INSERT 163735 1
> bga=# select * from test6;
> a
> --
> \001\002\354ab
> \001\002\354ab\000de\004
> (2 rows)
>
> This also illustrates another problem with bytea types. How does one tell the
>difference between a backslash followed by 3 digits (four bytes of data) for an
>encoded (single) byte of data?
>
> The problem with using '\134' as input to a bytea field is illustrated here:
>
> bga=# insert into test6 values('\134');
> ERROR: Bad input string for type bytea
> bga=#
>
>
> No file was uploaded with this report
>
>
> ---(end of broadcast)---
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] Clustering error with present CVS
Justin Clift <[EMAIL PROTECTED]> writes: > Just testing a few things out with present pre-7.2 CVS (as of a few > hours ago). > Came across the following error when clustering an index : > ERROR: IndexBuildHeapScan: concurrent insert in progress Fixed --- stupid error in trying to apply VACUUM time qual checking to CREATE INDEX. Thanks for the report! regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] PostgreSQL / PHP Overrun Error
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and have been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random instances,
I get buffer overruns and either 0-rows or a crashed apache child. Turning
on PHP's --enable-debug, I receive the following:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x, expected=0x7312F8DC)
End: Unknown
---
Sometimes it will actually crash mid-way (probably overwrote some valuable
code):
---
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal Segmentation
fault (11)
This problem is of great concern to me and I have been working for days
trying to debug it myself and find other reports, with little success. The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
efree(PGG(last_notice));
}
PGG(last_notice) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems? The
PHP code works sometimes and not others, and it seems to be only that one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if needed. I
have tried recompiling pgsql, php and apache with different optimizations
[including none at all and debug mode on as i have now] with little change
in the result.
Thanks in advance;
--
Mike
cc: pgsql-hackers; pgsql-php; pgsql_bugs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
