"Euler Taveira de Oliveira" <[EMAIL PROTECTED]> writes:
> I just execute the same transaction in 2 different backends and I got the
> message: 'attempted to update invisible tuple'.
If you want this investigated then you'll need to provide a
self-contained example. We have other things to do than
The following bug has been logged online:
Bug reference: 2166
Logged by: Euler Taveira de Oliveira
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1+
Operating system: Slackware 10.1
Description:attempted to update invisible tuple
Details:
I just execute the
"F. Laupretre" <[EMAIL PROTECTED]> writes:
> Or maybe, if it is really too smart (able to compute the result at
> compile time), we could have not to use a constant argument. Something
> like 'return finite((double)argv) ? 0 : 1'.
If the compiler is able to compute the result without using the ext
Bruce Momjian writes:
> Could any other configure tests fail in this way?
Good point. The isinf() test probably has the same failure mode.
There is also the sigsetjmp() test, but since that has side-effects,
it doesn't seem very much at risk of being aggressively optimized.
I don't see any othe
Tom Lane wrote:
> "F. Laupretre" <[EMAIL PROTECTED]> writes:
> > In order for the check to be done correctly, we have to provide a
> > program that the compiler cannot optimize, ie where it cannot detect
> > that the call is useless, even if it is very very smart. Here is a
> > patch with such a pr
"F. Laupretre" <[EMAIL PROTECTED]> writes:
> In order for the check to be done correctly, we have to provide a
> program that the compiler cannot optimize, ie where it cannot detect
> that the call is useless, even if it is very very smart. Here is a
> patch with such a program.
I haven't got a lo
"F. Laupretre" <[EMAIL PROTECTED]> writes:
> When configure checks to see if we have finite(), it attempts to
> compile a small program containing 'dummy=finite(1.0)'. On my system,
> where I am using gcc 4.0.2, this small program is tested with a '-O2'
> flag, and the gcc optimizer is too smart !
On Tue, Jan 10, 2006 at 10:14:42AM +0530, Jeevanandam, Kathirvel (IE10) wrote:
> We are getting error as "bus error" while running the createlang command
>
> createlang -d dbname plpgsql
Is the createlang program getting the bus error or is it the backend?
Does anything show up in the server logs
On Jan 10 01:38, Thomas Robak wrote:
> Querying tables encoded UTF8 containing german umlauts such aus
> Ã,ö,Ã,ä,Ã,ü with ILIKE will only return case-sensitive results.
> For example:
Please see these posts:
http://archives.postgresql.org/pgsql-bugs/2006-01/msg00063.php
http://archives.pos
