Not sure this is a bug, but I'm seeing the following message:
pg_ctl: another postmaster may be running; trying to start
postmaster anyway
FATAL: pre-existing shared memory block (key 9812001, ID 655374)
is still in use
HINT: If you're sure there are no old server processes still
running, rem
Not sure if this is a bug or by design in 8.1.2. Using the
following:
log_connections = on
log_disconnections = on
log_duration = on
log_statement = 'all'
log_line_prefix = '%m [%p] %u %r %d %x '
...the transaction is not printed with the duration (it prints 0
instead).
Ed
--
On Thursday September 8 2005 4:08 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I see sys/ipc.h already #includes sys/types.h, though.
>
> Possibly there's some magic #define needed to expose the cid_t
> definition?
>
> We ha
On Thursday September 8 2005 3:48 pm, Ed L. wrote:
> On Thursday September 8 2005 2:18 pm, Tom Lane wrote:
> > "Ed L." <[EMAIL PROTECTED]> writes:
> > > In file included from pg_sema.c:22:
> > > /usr/include/sys/ipc.h:51: error: parse error before
>
On Thursday September 8 2005 2:18 pm, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > In file included from pg_sema.c:22:
> > /usr/include/sys/ipc.h:51: error: parse error before "cid_t"
> > /usr/include/sys/ipc.h:56: error: parse error bef
On Thursday September 8 2005 12:20 pm, Ed L. wrote:
> checking build system type... ia64-hp-hpux11.23
> checking host system type... ia64-hp-hpux11.23
> ...
> checking sys/ipc.h presence... yes
> configure: WARNING: sys/ipc.h: present but cannot be compiled
> configure:
checking build system type... ia64-hp-hpux11.23
checking host system type... ia64-hp-hpux11.23
...
checking sys/ipc.h presence... yes
configure: WARNING: sys/ipc.h: present but cannot be compiled
configure: WARNING: sys/ipc.h: check for missing prerequisite headers?
configure: WARNING: sys/ipc.
On Tuesday June 21 2005 11:22 am, Ed L. wrote:
> Fyi, I got this regression diff on my IBM T41 laptop running
> new install of Fedora Core 4... no idea why...
>
> PostgreSQL 7.4.8 on i686-pc-linux-gnu, compiled by GCC gcc
> (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>
>
>
Fyi, I got this regression diff on my IBM T41 laptop running new
install of Fedora Core 4... no idea why...
PostgreSQL 7.4.8 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
4.0.0 20050519 (Red Hat 4.0.0-8)
/pgsql/builds/postgresql-7.4.8/src/test/regress
% cat ./regression.diffs
*** ./expected/
PostgreSQL 7.4.8 on ia64-hp-hpux11.23, compiled by
GCC gcc (GCC) 3.4.2
$cat ./regression.diffs***
./expected/float8.out Thu Sep 25 02:58:06
2003--- ./results/float8.out Tue
Jun 14 18:55:08 2005** 249,255 SELECT ''
AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
This is not a regression test failure, but looks like one...
Version: PostgreSQL 7.4.6 on ia64-hp-hpux11.23, compiled by GCC gcc (GCC) 3.4.2
$ file postgres
postgres: ELF-64 executable object file - IA64
$ cat regression.diffs
*** ./expected/float8.out Thu Sep 25 02:58:06 2003
--- .
Note the queries below generate the same result regardless of the timezone
input:
% env | grep TZ
PGTZ=CST6CDT
TZ=CST6CDT
% psql -t -c "select version()"
PostgreSQL 8.0.0beta3 on i686-pc-linux-gnu, compiled by GCC 2.96
% psql -t -c "select '1970-01-01 00:00:00+09'::timestamp + '1089352800
sec
On Monday December 6 2004 11:50, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > I can see the point of *not* dropping the sequence unless the
> > owning column is dropped. I just don't see the point of disabling the
> > useful ability to dec
On Monday December 6 2004 9:45, Ed L. wrote:
> On Sun, 05 Dec 2004 14:54:38, Tom Lane wrote:
> > On Sunday December 5 2004 12:34, Ed L. wrote:
> > > The following queries result in a dropped sequence, but IMO should
> > > not:
> > >
> > > create ta
On Sun, 05 Dec 2004 14:54:38, Tom Lane wrote:
> On Sunday December 5 2004 12:34, Ed L. wrote:
> > The following queries result in a dropped sequence, but IMO should not:
> >
> > create table foo(id serial);
> > create table bar(id integer not null nextval('foo_id_s
On Sunday December 5 2004 12:54, Ed L. wrote:
> There appears to be a race condition in which dropping a view and
> replacing it with an identically-named table inside one transaction while
> other transactions are concurrently updating the view/table causes the
> following error:
The following queries result in a dropped sequence, but IMO should not:
create table foo(id serial);
create table bar(id integer not null nextval('foo_id_seq'::text));
alter table foo alter column id drop default;
drop table foo;
Once dependence between foo and foo_id_seq has been removed, a dro
This is for PostgreSQL 7.4.6...
On Tuesday October 26 2004 7:31, Ed L. wrote:
> $uname
> HP-UX ... B.11.23 U ia64 1562128462 unlimited-user license
>
> $more ./regression.diffs
> *** ./expected/float8.out Thu Sep 25 01:58:06 2003
> --- ./results/float8.outTue Oc
$uname
HP-UX ... B.11.23 U ia64 1562128462 unlimited-user license
$more ./regression.diffs
*** ./expected/float8.out Thu Sep 25 01:58:06 2003
--- ./results/float8.outTue Oct 26 20:28:09 2004
***
*** 249,255
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
ERRO
Clean build of pgsql 7.4.5 on HPUX B.11.23 on ia64 with
--enable-thread-safety fails ... :(
$uname -a
HP-UX ... B.11.23 U ia64 0144848471 unlimited-user license
$cd postgresql-7.4.5
$./configure --enable-thread-safety --without-readline --without-zlib
...
checking pthread.h usability... yes
ch
Noticed this when I had a typo on the configure command line. The configure
script does not catch the following bogus option:
--enable-bogosity
That might seem like no biggie, but it also doesn't seem to notice this
error:
--enable-thread-safeyt (notice the mispelling)
Makes
21 matches
Mail list logo
