Re: [BUGS] BUG #2236: extremely slow to get unescaped bytea data

On Sat, Feb 04, 2006 at 04:06:11PM -0800, Kalador Tech Support wrote: > I've since isolated the problem to the unescape_bytea function not the > SELECT. > > I inserted the same image to a bytea column using base64 encoding, and > extracted it from the table (using base64 decoding) and this worke

Re: [BUGS] vacuum segmentation fault

Alfranio Correia Junior <[EMAIL PROTECTED]> writes: > I've tried to run vacuum full analyze with postgresql 8.1.1 and 8.1.2 > and in both cases I've seen a segmentation fault. > #0 ArrayGetNItems (ndim=3342336, dims=0x901adf4) at arrayutils.c:62 This looks like a corrupt-data problem to me. If

[BUGS] vacuum segmentation fault

I've tried to run vacuum full analyze with postgresql 8.1.1 and 8.1.2 and in both cases I've seen a segmentation fault. I read the archives and found something related to 8.1.1 but it was supposed to be fixed in version 8.1.2. Is there any patch available ? --

Re: [BUGS] BUG #2239: "vacuumdb -a" remove freeze

Olleg Samoylov <[EMAIL PROTECTED]> writes: > IMHO "vacuumdb -a" must don't vacuum database with > datvacuumxid=datfrozenxid. That's not going to work because it will fail to detect whether the database has been modified since the VACUUM FREEZE command. In any case, what's the point? As long as

Re: [BUGS] BUG #2240: length() with geometric types

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, sorry to bug you with that. I figured that out, too, in the meantime. I wonder why the default behaviour of the path-constructor to end up in a closed path. I would intentionally expect an open path - since I understand a path as a connection of p

[BUGS] BUG #2244: silent installation to set password never expires

The following bug has been logged online: Bug reference: 2244 Logged by: KF Tai Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: windows XP Description:silent installation to set password never expires Details: Hi there: Can someone help t

[BUGS] BUG #2243: Postgresql fails to finish some queries

The following bug has been logged online: Bug reference: 2243 Logged by: Matej Rizman Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 and 8.1 Operating system: Linux Debian, kernel 2.6.12-1-k7 Description:Postgresql fails to finish some queries Details: Exe

Re: [BUGS] BUG #2242: Inconsistent casting in query with literal vs query with parameter

"Matthew Bellew" <[EMAIL PROTECTED]> writes: > In the script below, I'd expect all four queries to return 10 rows > (1,2,3,4,5,10,20,30,40,50). However, function bystr() returns two rows > (1,10). Clearly, in this one case the query processor is casting the column > to the parameter type, rather

Re: [BUGS] BUG #2245: pg_dump doesn't dump expressions with sequence in DEFAULT setting for some column in table

"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes: > I use some expression as DEFAULT setting for some column of some table. For > example, nextval('myseq') * 10. > Then, I pg_dump my database and restore it. I see 'nextval('myseq')' (w/o > '*10'). You mustn't fool with the default expression for a

[BUGS] BUG #2245: pg_dump doesn't dump expressions with sequence in DEFAULT setting for some column in table

The following bug has been logged online: Bug reference: 2245 Logged by: Nikolay Samokhvalov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: Linux Fedora Core 4 Description:pg_dump doesn't dump expressions with sequence in DEFAULT setting