Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane kirjutas E, 30.06.2003 kell 01:21:
>> Who's still using 1.5, I guess is the question? And are they likely
>> to be updating their PG installation when they're not updating Python?
> I guess that anyone who needs safe Restricted Execution will b
On Saturday 28 June 2003 23:31, Robert L Mathews wrote:
> The problem was that the postgresql-libs-7.3.3-1 RPM package advertises
> itself as providing libpq.so.2, when in fact it does not do so: it
> provides only libpq.so.3.
You're right; they're different. Recompile the client; 'rpmbuild --reb
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> LOG: server process (pid 2004) was terminated by signal 11
> Is there any way to see what really happened?
I would like to see a stack backtrace (get a core dump, use gdb
on it. See the archives for descriptions of the standard procedure...)
Hannu Krosing <[EMAIL PROTECTED]> writes:
> The version with patch which removes RExec (as Python 2.x is not
> supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
> no reason to remove safe execution when using python 1.5.x.
Who's still using 1.5, I guess is the question? And a
Hannu Krosing <[EMAIL PROTECTED]> writes:
> could we not just make sure that plpython uses python ver < 2.x and use
> plpythonu for python versions >= 2.x until a secure regex solution comes
> from Guido and folks ?
We'd still have to mark it untrusted, so what's the point?
Is there any way to see what really happened?
I mean more exhausted debug info.
It seems like other server running same PG 7.3 and more or less
identical hardware is not affected by that.
Info starts here:
--main table
CREATE TABLE prod.t_documents (
documentid int4 NOT NULL,
docid char(16)
On Thu, Jun 26, 2003 at 01:19:09PM +0530, Shridhar Daithankar wrote:
> On 26 Jun 2003 at 3:44, [EMAIL PROTECTED] wrote:
> > > On Thu, Jun 26, 2003 at 03:17:12AM -0400, [EMAIL PROTECTED]
> > > wrote:
> > >> > I have a table with 13 fields. Is that
> > >> > too many fields for one table.
> > >> > Mar
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> I have consistent PG crash on some query,
> so I was able to isolate a simple query that crash postgres...
> SELECT p.docid FROM prod.t_documents AS p
> INNER JOIN t_tempdocs AS t
> ON p.docid = t.docid
> LEFT OUTER JOIN prod.t_
elein wrote:
Re: attribute ordering
The column presentation issue maybe should be
cross referenced with the problem with rowtypes
where the referenced table has dropped columns.
This is the one where in plpgsql you do a select *
into a rowtype of a table with dropped columns
you get a mismatch on
On Sunday 29 June 2003 15:10, Bruno BAGUETTE wrote:
> The database structure, the datas and the sequences where OK without any
> problems. He had to do a little work to add all the constraints but he's
> stucked on inserting PL/SQL packages... (Because there isn't the
> possibility to do PL/PgSQL p
On Sun, Jun 29, 2003 at 11:40:41AM +0200, Bruno BAGUETTE wrote:
> stucked on inserting PL/SQL packages... (Because there isn't the
> possibility to do PL/PgSQL packages currently).
Sorry, I don't really understand this. PL/pgSQL is the PostgreSQL
version of PL/SQL.
> He explains me that they hav
Hello,
I've a friend of mine that would like to move an Oracle8i Database
(running on a Tru64 Unix server) to PostgreSQL (because the organization
where he works have to cut down their costs). So, he tried to do a dump
from the Oracle database, makes a few search/replaces in the dump files
and fin
On Wednesday 25 June 2003 21:21, Jonathan Bartlett wrote:
> My solution did not involve tablespaces, but was more of a quick solution
> to make it easier for admins to do _some_ sort of physical configuration.
>
> The idea is that the developer could do something like
>
> 'create alternate location
Hi,
I have consistent PG crash on some query,
so I was able to isolate a simple query that crash postgres...
SELECT p.docid FROM prod.t_documents AS p
INNER JOIN t_tempdocs AS t
ON p.docid = t.docid
LEFT OUTER JOIN prod.t_refs AS ct
ON ct.docid = p
14 matches
Mail list logo