Hi,
It seems the timestamp.c patch to getg around the SCO optimizer bug did'nt
get in beta1
Is it normal?
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-8
AIUI, the issue is statements like:
# select numeric(6,3) '5.6';
Bison can't look far enough ahead to determine whether the numeric is a
type or a function. However, the desired grammer itself is not
ambgiuous, it's just that Bison is not smart enough to make it work. It
works now only because we
Hi!
During testing of 8.1 I found that using pg_dumpall (-g) against a live
8.0 install that has at least one GROUP defined results in the following
warning while it creates the CREATE ROLE statements in the dump:
row number 0 is out of range 0..-1
To reproduce the problem it is enough to init
[EMAIL PROTECTED] writes:
> Our friendly psql complains that pg_shadow is a view:
> psql::11: ERROR: cannot delete from a view
> HINT: You need an unconditional ON DELETE DO INSTEAD rule.
Yeah, this is on the open-items list; the DELETE FROM is broken (and
was always a pretty bogus appro
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> During testing of 8.1 I found that using pg_dumpall (-g) against a live
> 8.0 install that has at least one GROUP defined results in the following
> warning while it creates the CREATE ROLE statements in the dump:
> row number 0 is out of range 0.
I poked around this one. The SSL locking documentation is at:
http://www.die.net/doc/linux/man/man3/crypto_set_id_callback.3.html
The description isn't clear. When they talk about locking_function()
and id_function(void), they are talking about arguments to the SSL
functions listed above, no
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>
>>During testing of 8.1 I found that using pg_dumpall (-g) against a live
>>8.0 install that has at least one GROUP defined results in the following
>>warning while it creates the CREATE ROLE statements in the dump:
>>row number
Awhile back I wrote:
> Hmm, I don't see that symptom, but I do see some strange stuff building
> PG CVS tip on a fully-up-to-date (10.4.2) OS X machine.
> ...
> Second, at exit from an interactive psql session,
> regression=# \q
> could not save history to file "/Users/tgl/.psql_history": Invalid
> The basic issue with SSL is that it wants some unique
> identifier for threads. They really should have defined the
> function to take pthread_t rather than unsigned long because
> pthreads doesn't really give us a useful way to get an
They absolutely should not have done that. That would'v
Magnus Hagander wrote:
> > The basic issue with SSL is that it wants some unique
> > identifier for threads. They really should have defined the
> > function to take pthread_t rather than unsigned long because
> > pthreads doesn't really give us a useful way to get an
>
> They absolutely shou
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 18:19
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> I poked around this one. The SSL locking documentation is at:
>
> http://www.
Bruce Momjian writes:
> Magnus Hagander wrote:
>>> Also, there doesn't seem to be a good way for users to know
>>> if libpq or ecpg was compiled to be thread-safe.
>>
>> Right. A runtime function for this might be a good thing? Like "bool
>> PQisThreadSafe()" or such?
> Yes, and a flag to ecpg.
I'm currently testing pgAdmin support for slony, on pgsql CVS HEAD, and
encounter strange problems from time to time.
After dropping and recreating the slony schema, all changes committed
and all backends in state, I'm getting
"relation with OID xxx does not exist" when I'm trying to add a path.
Dave Page wrote:
> > So, we might be able to get away without this on Win32, or perhaps the
> > pthread_self().p is a valid unique identifier for Win32 threads and
> > pthreads.
>
> Right.
>
> > How is this pthread_self() call working on Win32 now? Is pthreads a
> > requirement for libpq threadi
Tom Lane wrote:
> Bruce Momjian writes:
> > Magnus Hagander wrote:
> >>> Also, there doesn't seem to be a good way for users to know
> >>> if libpq or ecpg was compiled to be thread-safe.
> >>
> >> Right. A runtime function for this might be a good thing? Like "bool
> >> PQisThreadSafe()" or suc
I have the following conferences scheduled:
Sept 7-10, Sri Lanka
Sept 17, New York City
October 17-20, Amsterdam
Information is on the PostgreSQL Events list and my home page. I also
have a possible Armenia trip for early October, and Mexico for
mid-November.
--
Bruce
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 28 August 2005 22:56
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Win32 Thread safetyness
>
>
> Well, actually I tried to run configure --enable-thread-safety on a
> MinGW platf
Patch applied. Autoconf run. Thanks.
---
Dave Page wrote:
>
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: 28 August 2005 22:56
> > To: Dave Page
> > Cc: pgsql-hackers@postgr
Yeah, I think it's a timing thing on when the fix was committed and when
Beta1 was pulled.
It will be in the next beta/release based on the commit I saw.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail
* optional interface which sends a row typeoid along with each row in a result
set
Oh, and 'select rowid, * from table' which returns special rowid column
that just incrementally numbers each row.
Chris
---(end of broadcast)---
TIP 6: explain
Folks,
I've noticed that \df doesn't do quite what it might when a function
is created with named input parameters. Please find enclosed a patch
against CVS TIP that does this better.
On a slightly related note, I've noticed that psql isn't backward
compatible. I know that it's *very* late to b
David Fetter <[EMAIL PROTECTED]> writes:
> On a slightly related note, I've noticed that psql isn't backward
> compatible.
We have never expected psql's \d commands to work against older server
versions, and two months after feature freeze isn't the time to start
making that happen.
Hi there,
I'm a bit surprised how bad could be plan for unused table.
I had to cancel second query :)
tp=# explain analyze select tp_rewrite_substitute(query,
'select p.name_tsquery, p.name_alias_tsquery from place p')
from to_tsquery('new&york&hotel') as query;
y;
On E, 2005-08-29 at 09:50 +0400, Oleg Bartunov wrote:
> Hi there,
>
> I'm a bit surprised how bad could be plan for unused table.
> I had to cancel second query :)
...
> tp=# explain analyze select tp_rewrite_substitute(query,
> 'select p.name_tsquery, p.name_alias_tsquery from place p')
> from
24 matches
Mail list logo
