The following bug has been logged online:
Bug reference: 4609
Logged by: Alex
Email address: alex...@hotmail.com
PostgreSQL version: 8.2+
Operating system: Windows 7
Description:Installer cannot start postgresql service succesfully
Details:
Hi, I tried to install
The following bug has been logged online:
Bug reference: 4783
Logged by: Alex
Email address: okto...@mail.ru
PostgreSQL version: 8.4
Operating system: WinXP
Description:new syntax in tablefunction - not output cells
Details:
CREATE TABLE tst (
"id"
The following bug has been logged online:
Bug reference: 4798
Logged by: Alex
Email address: a...@xdcom.org
PostgreSQL version: 8.3.6
Operating system: rhel5
Description:BitMapAnd never works with gin
Details:
CREATE TABLE foo
(
id serial NOT NULL,
name
The following bug has been logged online:
Bug reference: 4799
Logged by: Alex
Email address: a...@xdcom.org
PostgreSQL version: 8.3.6
Operating system: rhel5
Description:BitMapAnd never works with gin
Details:
CREATE TABLE foo
(
id serial NOT NULL,
name character
The following bug has been logged online:
Bug reference: 4800
Logged by: Alex
Email address: a...@xdcom.org
PostgreSQL version: 8.3.6
Operating system: rhel5
Description:constraint_exclusion could be smarter with bool
conversion
Details:
Table "public.foo1&qu
The following bug has been logged online:
Bug reference: 4828
Logged by: alex
Email address: alexafanas...@yandex.ru
PostgreSQL version: PostgreSQL8.3.7
Operating system: Windows XP 2002 SP2
Description:Fault a foreign key
Details:
Run in psql:
--DROP DATABASE
The following bug has been logged online:
Bug reference: 5362
Logged by: ALEX
Email address: bav...@mail.ru
PostgreSQL version: 8.3
Operating system: linux ubuntu 9.10 server
Description:WARNING could not determine encoding
Details:
# sudo pg_createcluster -e koi8
POSTGRESQL BUG REPORT TEMPLATE
Your name : Alex Verstraeten
Your email address : [EMAIL PROTECTED]
System
The following bug has been logged online:
Bug reference: 3467
Logged by: Alex
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.4
Operating system: FreeBSD 6.2-RELEASE-p4
Description:Sum strange behaviour
Details:
I have a database with some float numbers
My colleague Marc Schablewski reported this Bug (#3484) the first time
at the end of July.
The described problem occured twice at our database and now it happened
again.
Summary
==
Various errors like:
"invalid page header in block 8658 of relation",
"could not open segment 2 of relatio
or ( Intel(R) Xeon(TM) CPU 2.80GHz )
postgres-Version: 8.2.4
Original-Nachricht
Betreff: Missing pg_clog file / corrupt index / invalid page header
Datum: Wed, 05 Sep 2007 08:18:31 +0200
Von: alex <[EMAIL PROTECTED]>
Organisation: click:ware GmbH
An: pgsql-bugs@postgresql.org
The following bug has been logged online:
Bug reference: 4104
Logged by: alex
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: windows XP
Description:Uninstall/remove not working correctly
Details:
I recently uninstalled 8.3.1 and I
The following bug has been logged online:
Bug reference: 4151
Logged by: alex
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: windows XP
Description:Can't connect/start database after restart
Details:
Hi,
I have 8.3.1 pos
The following bug has been logged online:
Bug reference: 4172
Logged by: alex
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.1
Operating system: windows xp
Description:postgres stops working after restart
Details:
I installed 8.3.1 fine and the service
The following bug has been logged online:
Bug reference: 5950
Logged by: alex
Email address: perepelica.a...@gmail.com
PostgreSQL version: 9.0.3
Operating system: archlinux x86_64
Description:backend terminating after altering table
Details:
Such steps:
1. create
The following bug has been logged online:
Bug reference: 6010
Logged by: alex
Email address: alexandr.kas...@gmail.com
PostgreSQL version: 9.1 beta1
Operating system: snow leopard
Description:booting problem
Details:
after changing sysctl.conf values and rebooting
The following bug has been logged online:
Bug reference: 6054
Logged by: Alex
Email address: alexander.ochkal...@gmail.com
PostgreSQL version: 8.4.8
Operating system: CentOS
Description:Insert to table, which has fkey to table,which is
parenttable for another table
The following bug has been logged online:
Bug reference: 6159
Logged by: Alex
Email address: perepelica.a...@gmail.com
PostgreSQL version: 9.1beta3
Operating system: linux x86_64 archlinux
Description:Can't create unlogged table
Details:
Execute from pg
The following bug has been logged on the website:
Bug reference: 8354
Logged by: Alex Hill
Email address: a...@hill.net.au
PostgreSQL version: 9.2.4
Operating system: OS X 10.8.4 Mountain Lion
Description:
Hi all,
The docs for ts_rank_cd state:
"This fun
The following bug has been logged online:
Bug reference: 4278
Logged by: Alex Balan
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3 Windows
Operating system: Windows XP SP2
Description:pg_dump data outputs when run from command prompt in
unreliable
Details
On Tue, Sep 23, 2008 at 10:38 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dean Rasheed" <[EMAIL PROTECTED]> writes:
>> CREATE TABLE foo(a int, b int);
>> CREATE VIEW foo_v AS SELECT * FROM foo;
>> CREATE RULE foo_r AS ON INSERT TO foo_v DO INSTEAD INSERT INTO foo
>> VALUES(NEW.a, NEW.b);
>> INSERT I
On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> A likely bet is that this is caused by use of uninitialized memory,
> which happens to have garbage rather than zeroes in it the second
> time through.
Yep both DCH_MC and DCH_US were going past the end of the string
because t
On Thu, Sep 25, 2008 at 4:05 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> A likely bet is that this is caused by use of uninitialized memory,
>> which happens to have garbage rather than zero
On Tue, Nov 4, 2008 at 09:02, Jeff <[EMAIL PROTECTED]> wrote:
> I've ran into this interesting problem.
> It seems that while you can call sort() in a trusted plperl func you cannot
> access $a & $b which effectively makes it useless.
Hrm works for me if I take out the elog from sort()
create or
On Tue, Nov 4, 2008 at 12:39, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> Hrm works for me if I take out the elog from sort()
>
> Even more interesting, this variant *doesn't* work:
>
> regression=# create
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> It has something to do with anon subs not sure what...
It has to do with us returning the anonymous sub inside of the safe
and then calling the function outside of the safe (or at least in a
different namespac
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> We need to document that, and given that this exists I think we don't need
> to backpatch old versions.
Agreed.
> Beyond that, we need to be very careful with any "solution" that we don't
> upset the moderately fragile se
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> The other idea Ive been toying this is instead of calling reval we can
> just call Opcode::_safe_call_sv() something like the below:
Argh gmail probably ate the whitespace in the patch... see attached
plper
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But by all means if you can come up with a robust way of allowing
>> the more traditional way of calling sort routines, send it in.
On Tue, Nov 4, 2008 at 15:17, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Alex Hunsaker wrote:
>> Err no you're right its only builtins that use main:: sort being the
>> only one I know of off the top of my head... its a shame
>> PLContainer->
On Wed, Nov 5, 2008 at 10:54, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes:
>
> nathan> Completely untested speculation based on my knowledge of perl
> nathan> and a bit of reading:
>
> nathan> The reason you can't see $a and $b is that sor
On Wed, Nov 5, 2008 at 11:14, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Gierth <[EMAIL PROTECTED]> writes:
>> Nice theory, but completely wrong: sort creates $a and $b in the
>> current package, not in main::.
>
> Hmm ... so then why are we seeing a failure?
Because Safe runs in a different nam
On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>
> >> Hmm ... so then why are we seeing a failure?
>
> [...]
> Alex> This is not a Safe bug
On Thu, Nov 6, 2008 at 06:41, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>> Then explain why the problem goes away when you build perl
On Thu, Nov 6, 2008 at 09:03, Andrew Gierth <[EMAIL PROTECTED]> wrote:
>>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>
> Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374
>
> Feel free to add my explan
On Thu, Nov 6, 2008 at 09:00, Andrew Gierth <[EMAIL PROTECTED]> wrote:
> If it helps any, I've tracked down in the perl guts exactly why this
> happens:
Cool
> Notice, though, that without ithreads, the COP points directly to the
> stash, but with ithreads, it points instead to the _name_ of the
.
whats the problem?
Reggards,
Alex Rezende
Namely it does not disable the rule... Enabling inside of the
transaction seems to work though
Tried both CVS and 8.3.5...
create table trule (a int);
insert into trule (a) values (1);
create rule trule_rule as on update to trule do instead nothing;
update trule set a = 2;
UPDATE 0
begin;
ALTER
On Mon, Dec 29, 2008 at 15:07, Alex Hunsaker wrote:
> Namely it does not disable the rule...
> Enabling inside of the transaction seems to work though
Hrm the above turned out to be false... must have gotten confused when
testing with triggers
If i turn on RELCACHE_FORCE_RELE
On Tue, Aug 18, 2009 at 06:00, hubert depesz
lubaczewski wrote:
> Hi,
> tried on latest 8.5, and some 8.3:
> # select '4817191.623 ms'::interval;
> interval
> --
> -00:35:47.483648
> (1 row)
>
> I am pretty sure the answer is wrong. But why?
It only happens if you have integer
On Tue, Aug 18, 2009 at 10:42, Tom Lane wrote:
> Alex Hunsaker writes:
>> It only happens if you have integer date times on... seems to have
>> gotten introduced by
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php
>
> Uh, no, fsec_t was int32 be
On Tue, Aug 18, 2009 at 12:07, Tom Lane wrote:
> Throwing overflow errors doesn't seem very nice either, especially not
> for values that worked just fine before 8.4.
I just checked both 8.3.7 and 8.2.13 give:
# select '4817191.623 ms'::interval;
interval
--
-00:35:47.483648
(
The following bug has been logged online:
Bug reference: 5089
Logged by: Yamashkin Alex
Email address: defa...@smart-soft.ru
PostgreSQL version: 8.4.0.1
Operating system: windows XP Embeded
Description:not supported plpsql
Details:
good day.
installing Postgresql
On Thu, Nov 6, 2008 at 08:37, Alex Hunsaker wrote:
> On Thu, Nov 6, 2008 at 06:41, Tom Lane wrote:
>> "Alex Hunsaker" writes:
>>> On Wed, Nov 5, 2008 at 18:03, Andrew Gierth
>>> wrote:
>>>> Then explain why the problem goes away when you buil
On Thu, Jan 14, 2010 at 04:06, louis wrote:
> Arguments can't be passed to a plperl function
Yeah, this is a bug with safe 2.20 :( see
-http://rt.perl.org/rt3/Ticket/Display.html?id=72068
I would either try out this fix:
http://github.com/timbunce/Safe/commits/master.
Or downgrade to 2.19 for
On Thu, Feb 18, 2010 at 02:20, wrote:
> $ psql -U foo -h 127.0.0.1 -f doesntwork.sql db
> Password for user foo:
> ERROR: invalid byte sequence for encoding "UTF8": 0xe46976
> HINT: This error can also happen if the byte sequence does not match the
> encoding expected by the server, which is co
On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> The key line is:
>
> *PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
Hrm... It seems to work for me in HEAD and AFAICS we dont have that
line. Did I just miss it? Or did you happen to fix it in another way
with your refactoring?
Another Idea tha
On Fri, Feb 19, 2010 at 02:30, Tim Bunce wrote:
> On Thu, Feb 18, 2010 at 11:32:38AM -0700, Alex Hunsaker wrote:
> > On Thu, Feb 18, 2010 at 11:09, Tim Bunce wrote:
> >*PLPerl::utf8::SWASHNEW = \&utf8::SWASHNEW;
> >
> > Hrm... It seems to work for me in HE
On Fri, Feb 19, 2010 at 06:06, Tim Bunce wrote:
> I've got the patch to Safe ready but the more I think about it the more
> I think the right fix is for Safe to automatically fully load utf8.pm
> (and utf8_heavy.pl) and to always share SWASHNEW itself.
It seems cleaner if we could just share say
On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
> It seems to me a more correct fix would be to require utf8; inside of
> the safe like we do strict.
>
> Id favor this approach as if you have utf8 strings the likely hood
> that you want ::upgrade, ::downgrade, ::enc
On Fri, Feb 19, 2010 at 14:00, Tim Bunce wrote:
> On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote:
>> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker wrote:
>> > It seems to me a more correct fix would be to require utf8; inside of
>> > the safe like we d
On Mon, Feb 22, 2010 at 10:57, Jonathan wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5339
> Logged by: Jonathan "Duke" Leto
> Email address: jonat...@leto.net
> PostgreSQL version: master 0f50d482
> Operating system: CentOS 5.4 (Linux kernel 2.6.18)
On Mon, Feb 22, 2010 at 12:44, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 10:57, Jonathan wrote:
>> configure: using perl
>> configure: WARNING:
>> *** The installed version of Perl, /home/leto/bin/perl, is too old to use
>> with PostgreSQL.
>> *** Perl vers
On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
>
> This is not a path towards an acceptable solution, as it effectively
> assumes what we are setting out to prove, namely that
On Mon, Feb 22, 2010 at 14:17, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 13:07, Tom Lane wrote:
>> Alex Hunsaker writes:
>>> ! perl_version_error=`$PERL -e 'use 5.00801;' 2>&1`
...
> How about something like the below?
Find attached on
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
> Alex Hunsaker writes:
>> How about something like the below?
>
> I still think that this is optimizing the wrong thing. We care about
> the clarity of the message the user sees, not about how short or clean
> the Perl code
On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
> I'm inclined to stay with the same basic
> implementation and just hack up the regexp some more to cope with 5.11's
> more verbose -v output.
And here is a stab at that:
$ echo "This is perl, version 4.0" | sed -n 's/This is perl.*v[a-z
]*\([0-9]\.
On Tue, Feb 23, 2010 at 00:50, Alex Hunsaker wrote:
> On Mon, Feb 22, 2010 at 14:31, Tom Lane wrote:
>> I'm inclined to stay with the same basic
>> implementation and just hack up the regexp some more to cope with 5.11's
>> more verbose -v output.
>
> And h
On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
> I believe (but haven't yet confirmed) that the problem here is recursion.
> This affects all versions of PostgreSQL.
Hrm... This seems to work for me in HEAD. It certainly breaks in 8.3.
Am I missing something?
$ bin/psql postgres
psql (9
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
>
>> I believe (but haven't yet confirmed) that the problem here is recursion.
>> This affects all versions of PostgreSQL.
> Ill keep digging.
Ok I understand now, ba
On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>What you're saying, IIUC, is
> that if function A calls function B via a SPI command, and B wasn't
> executed previously in the current session, it would fail? Seems
> entirely unacceptable.
Yep, thats right :(. Thanks, thats exactly the kind of f
On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>> Seems entirely unacceptable.
> I think we will see if we can get this fixed on the Safe/perl side then.
BTW the trade off here is we revert back to sort { $a <=> $b } not
On Tue, Feb 23, 2010 at 15:54, Tim Bunce wrote:
> Doesn't seem too icky. Basically plperl would need to save the values of
> PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
> initialized. And then local()'ly restore them in the plperl entry points.
> Should only be a few lines o
On Wed, Feb 24, 2010 at 22:01, Alex Hunsaker wrote:
> Ok I can get behind this. I did some testing and we could probably
> even store less than than that if we could do the equivalent of:
> Safe->share('::mksafefunc');
> pl_perl_createsub()
> Safe->unshare('
On Thu, Feb 25, 2010 at 12:20, Tom Lane wrote:
> Alex Hunsaker writes:
>> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
>> [ fixes both issues ]
>
> How exactly would you propose doing that?
Well that's the thing, probably by what I d
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
wrote:
> There seem to be no good answers here.
Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work. Maybe Tim sees a way? We can
work around it in 9.0 with plperl.on_init. But breaking the ba
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
> Just don't break anything in 9.0 that relies on plperl please. :) To that
> end, let me know when HEAD has something somewhat stable, and I'll
> run some tests against it (e.g. Bucardo, which uses lots of plperl)
Defiantly, the goal is t
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker wrote:
> On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
>> Just don't break anything in 9.0 that relies on plperl please. :) To that
>> end, let me know when HEAD has something somewhat stable, and I'll
>>
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a pl
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler
wrote:
> On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> There is one fairly good answer:
>>
>> Use a perl that's compiled to support multiplicity but not threads.
> That solves the problem with recursion or with $a and $b or both?
Yes ATM becaus
On Mon, Mar 1, 2010 at 02:22, Oleg wrote:
> CREATE OR REPLACE FUNCTION "bug" () RETURNS pg_catalog.void AS
> $body$
> DECLARE
> row_test1 test1%rowtype;
> row_test2 test2%rowtype;
> BEGIN
> SELECT test1, chunk_id
> FROM test1 JOIN test2 ON(chunk.id = test2.chunk_id)
> LIMIT 1
>
On Tue, May 11, 2010 at 12:42, Robert Haas wrote:
> I guess the question that comes to mind for me is how many other
> things fall into this category. We define a lot of symbols like int4
> and int32 that other people could also have defined, and I don't
> really want to s/^/pg/ all of them. If
Is this a bug, am I missing something? If you need any other
system info, please let me know. I did an RPM install on a pretty plain
Redhat 6.2 system.
Please reply to [EMAIL PROTECTED] with any ideas.
Thanks!
Alex
---- Gossamer Threads Inc. --
Alex Krohn
Hi,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> >> Beware of changing the postmaster's locale on the fly, however,
> >> since that will leave you with corrupted (out-of-order) indexes.
> >> Safest to dump/initdb in new locale/reload.
>
> > Ho
n `initdb /var/lib/pgsql`. I then ran
/etc/rc.d/init.d/postgres start as root, and then as user postgres ran
`createdb mytest`.
After this, my create test and select still produced the same error. Ugh.
Cheers,
Alex
Hi Tom,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> > links=# select * from foo where a like 'Test/%'
> > links-# ;
> > a
> > ---
> > (0 rows)
>
> This looks like an artifact of the known probl
's try a direct test.
> What do you get from
>
> select 'a_b'::text < 'ac'::text;
>
> select 'A_B'::text < 'ac'::text;
>
> On my machine, these produce 't' in C locale, but 'f' in en_US locale.
master's locale on the fly, however,
> since that will leave you with corrupted (out-of-order) indexes.
> Safest to dump/initdb in new locale/reload.
How would I go about changing that? Setting LANG and LC_ALL in the pgsql
users home directory .bashrc? Or do I need to edit the startup file?
Cheers,
Alex
[ 9 0 0 0 84 101 115 116 47 ] :constbyval false })}
{ EXPR :typeOid 16 :opType op :oper { OPER :opno 1058 :opid 1049 :opresulttype 16 }
:args ({ VAR :varno 1 :varattno 1 :vartype 1042 :vartypmod 29 :varlevelsup 0
:varnoold 1 :varoattno 1} { CONST :consttype 1042 :constlen -1 :constisnull false :con!
stvalue 9 [ 9 0 0 0 84 101 115 116 48 ] :constbyval false })})) :ind
NOTICE: QUERY PLAN:
Index Scan using foodx on foo (cost=0.00..8.14 rows=10 width=12)
EXPLAIN
links=#
Cheers,
Alex
Hi Tom,
> Alex Krohn <[EMAIL PROTECTED]> writes:
> >> On my machine, these produce 't' in C locale, but 'f' in en_US locale.
>
> > Seem to be in C locale:
>
> So it does. Okay, what was the complete test case again?
> I'm afraid I
0'::bpchar;
a
---
(0 rows)
links=#
Are you saying the second test should have returned true under C locale?
Is this a version dependant bug? Will downgrading to 6.x get me going?
Cheers,
Alex
s in PQexec, or is there any other reason
for it?
The query is attached.
Thanks in advance,
Alex
P.S. The query is:
SELECT s1.GivingCode FROM Scored s1, Scored s2
WHERE s1.Score >= 8 AND s2.Score >= 8 AND s1.Year = s2.Year AND
s1.GivingCode = s2.ReceivingCode AND s1.ReceivingCod
Please, ignore my question. The problem was that I did PQclear(res) before
calling to PQgetvalue(res,...)
Anyway, it should not crush (IMHO).
Alex
"Alex Glikson" <[EMAIL PROTECTED]> wrote in message
a1jjj5$tas$[EMAIL PROTECTED]">news:a1jjj5$tas$[EMAIL PROTECTED]..
The following bug has been logged online:
Bug reference: 2451
Logged by: Alex Weslowski
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1
Operating system: Windows XP
Description:Short column names return no values within function
Details:
Below is code for
The following bug has been logged online:
Bug reference: 2510
Logged by: alex tsai
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: FreeBSD 6.1 stable
Description:ERROR: out of memory DETAIL: Failed on request of size
825242672.
Details
The following bug has been logged online:
Bug reference: 2580
Logged by: Alex Zhang
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4-1
Operating system: Windows XP sp2 and Windows 2003 Server
Description:Analyze table cause invalid memory alloc error in
The following bug has been logged online:
Bug reference: 2778
Logged by: Alex Deiter
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Solaris 9 sparc
Description:make check failed
Details:
System detail:
Solaris 9 sparc, gcc 4.0.2
The following bug has been logged online:
Bug reference: 2812
Logged by: Alex Piyevsky
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux Kernel-2.4.21-glibc-2.3.2 x86 32bit
Description:Transaction is aborted after error
Details:
We
The following bug has been logged online:
Bug reference: 3973
Logged by: Alex Hunsaker
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Linux
Description:pg_dump using inherited tables do not always restore
Details:
create table junk
On Wed, Feb 20, 2008 at 3:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > create table junk (val integer not null, val2 integer);
> > create table junk_child () inherits (junk_1);
> > alter table junk_child
> It seems much more restrictive than necessary, plus it does nothing
> for the check-constraint case. My recollection of the previous
> discussion about how to fix this was that we needed to add an inhcount
> column to pg_constraint, and add entries for not-null constraints (at
> least inh
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfault
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > Problem: Apparently random segfaults apparently query agnostic, seem
> > to be more frequent when a pg_dump is running
>
> Hmm, se
FYI right now Im trying:
Author: tgl
Date: Sat Feb 2 22:26:17 2008 +
Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait. We can use a PG_TRY block for this, but
add a comment
explaining why it'd be a bad idea to use it for any ot
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to
my understanding should be roughly equivalent to (because of
Apache::DBI):
prepare query ;
begin;
execute query;
commit;
(next page load)
begin;
execute query;
commit;
I can turn that off and only use DBI->prepare() as a t
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now personally, I am much more interested in *reproducing* the problem
> than merely dodging it. I can understand if you just need a workaround
> yesterday, but please see if you can get a reproducible test case ...
>
>
On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > the mean time here is a new backtrace I just got (lord knows how... it
> > seems to be as soon as I stop trying to make it cras
On Wed, Mar 12, 2008 at 9:22 AM, Greg Sabino Mullane <[EMAIL PROTECTED]> wrote:
ommits.
>
> Are you sure you are calling DBI->connect *after* the Apache children
> are created?
Yes.
Major problems like this can happen if not. The use of
> prepare_cached() may be adding to the problem as well,
On Wed, Mar 12, 2008 at 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > On Wed, Mar 12, 2008 at 12:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> >> If you say "none of my stuff is changing any sc
On Wed, Mar 12, 2008 at 10:31 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
>
> > Here is what im trying right now with no success:
>
>
> > my $sth = $db->prepare_cached('select * from jun
1 - 100 of 193 matches
Mail list logo
