Hi,
I amn't running two copies of pgAdmin at same time. The problem is
The postgres server is running on a separate Windows XP system. I cannot be
sure if pgAdmin is open or not on that system. I use the console way to create
a database on that system.
createdb mehultest -h pcdsk506 -U postgr
"" <[EMAIL PROTECTED]> writes:
> The following query should not raise an error ("ERROR: UNION types text and
> integer cannot be matched"):
> SELECT NULL AS Test
> UNION ALL SELECT NULL
> UNION ALL SELECT 0
Hmm ... it works if you do
SELECT NULL AS Test
UNION ALL (SELECT NULL
UNION ALL SELECT
Rolf Sponsel <[EMAIL PROTECTED]> writes:
> From my understanding, the preferred way
> for Solaris is to only set LD_RUN_PATH,
> and avoid setting LD_LIBRARY_PATH, at
> link-time. This is what I usually do.
No, the preferred thing is to set -rpath within the executable, which
we do already (see Ma
"phucle" wrote:
> I installed Postgres 8.0 sucessfully and ran Ok but when I restarted my
>computer, Postgres could not start. When I checked in windows service, I
>realized that Postgres service did not start. I tried to start manual but
>could not start
I encoutered a similar problem on an la
The following bug has been logged online:
Bug reference: 1453
Logged by:
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0
Operating system: Windows 2000
Description:NULLs in UNION query
Details:
The following query should not raise an error ("ERROR: UNIO
I'm confused, this looks fairly unrelated to the original message that I had
sent?
Bruce Momjian wrote:
>Alvaro Herrera wrote:
>> On Sat, Jan 22, 2005 at 10:28:16PM +, Brad Snobar wrote:
>>
>> > The column was a primary key bigint.
>> >
>> > ALTER TABLE "public"."CategoryBuildingRankSchem
I have a standard Redhat 9 installation with the
exception of upgrading bison to bison-1.875-7.1
I can build the postgres rpm files from the source
for version 7.4.5 no problems with the following command:
rpmbuild --rebuild --define 'build89 1' --define
'python 0' --define 'test 0' --defi
Good afternoon. I think I may have found a bad planner decision in
Postgres. In essence, I have a table that is well-sorted, and has an index
on the sort column. I wish to retrieve all rows from the table that have a
column value greater than X, or some other condition (which is also
indexed and w
The following bug has been logged online:
Bug reference: 1452
Logged by: Jonathan Chen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows Server 2003
Description:psql and other programs don't offer a password prompt,
so I can't login to
*
Seem like I have to re-post once more;
since my post including the log file seemed
to exceede the allowed length restriction
for posted messages, imposed by your mail
server.
This time I'll provide the "attachement"
as a link to wherefrom you can download
t
Tom Lane wrote:
"Olleg Samoylov" <[EMAIL PROTECTED]> writes:
create rule history_i as on insert to history do (update abonent set
money=money+new.money where abonent=new.abonent);
insert into history (abonent,money) select abonent,-(money.money+5) as pay
from
( select abonent,sum(money) as mone
The following bug has been logged online:
Bug reference: 1451
Logged by: Kim Hansen
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0 (MSI)
Operating system: MS Windows XP Pro
Description:FATAL: could not reattach to shared memory
Details:
postmaster.exe d
Donald Fraser wrote:
I have a standard Redhat 9 installation with the exception of
upgrading bison to bison-1.875-7.1
I can build the postgres rpm files from the source for version 7.4.5
no problems with the following command: rpmbuild --rebuild --define
'build89 1' --define 'python 0' --define 'te
Hi,
I've successfully built PostgreSQL 8.0.0
on SPARC/Solaris (7), with gcc-3.2.2.
Hardware is SPARCstation 5, 170 MHz.
Because it doesn't build optimally right
out of the box, I'd like to provide you
with some feed-back.
From my understanding, the preferred way
for Solaris is to only set LD_RUN_PA
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 31 January 2005 17:29
> To: Dave Page
> Cc: Mehul Doshi-A20614; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Template1 is locked when pgAdminIII is open
>
> Hmm. Would it be possible to teach pgAdmin to close
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Mon, Jan 31, 2005 at 12:29:12PM -0500, Tom Lane wrote:
>> Of course, sooner or later we should fix the underlying locking
>> mechanism so we don't have to have this constraint, but I'm not sure
>> when that will happen.
> What needs to be locked?
So
Tom Lane wrote:
"Dave Page" writes:
Tom Lane wrote:
I think the real answer is something more along the lines of
"don't run two copies of pgAdmin at once".
He might not be. pgAdmin uses a master connection (normally to
template1) and one connection to each database browsed (minus the master
conn
On Mon, Jan 31, 2005 at 12:29:12PM -0500, Tom Lane wrote:
> Of course, sooner or later we should fix the underlying locking
> mechanism so we don't have to have this constraint, but I'm not sure
> when that will happen.
Hm, can we use LockSharedObject? It's on my shared dependency patch.
What n
"Dave Page" writes:
> Tom Lane wrote:
>> I think the real answer is something more along the lines of
>> "don't run two copies of pgAdmin at once".
> He might not be. pgAdmin uses a master connection (normally to
> template1) and one connection to each database browsed (minus the master
> connec
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 31 January 2005 16:40
> To: Dave Page
> Cc: Mehul Doshi-A20614; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Template1 is locked when pgAdminIII is open
>
> "Dave Page" writes:
> > pgAdmin uses template1 by de
Tom Lane wrote:
"Dave Page" writes:
pgAdmin uses template1 by default as it is the only accessible database
that we can be sure will exist. There are 2 solutions to your problem:
1) Change your pgAdmin connection to use a different default database.
2) Select a different database to use as the t
"Dave Page" writes:
> pgAdmin uses template1 by default as it is the only accessible database
> that we can be sure will exist. There are 2 solutions to your problem:
> 1) Change your pgAdmin connection to use a different default database.
> 2) Select a different database to use as the template
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Tue, Jan 25, 2005 at 12:18:38PM -0500, Tom Lane wrote:
>> Yes, it should definitely go into 8.0 branch, and probably also 7.4
>> branch if you are sure that the patch applies there. Keep in mind
>> there will be releases pretty soon because of the LO
On Tue, Jan 25, 2005 at 12:18:38PM -0500, Tom Lane wrote:
> > Where all did you commit the fix? Just HEAD? Shouldn't it also
> > be committed to REL8_0_STABLE, etc., as well?
Yes, you are right of course. I was in a hurry to fix this before going
on a business trip without internet connectivity
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Mehul
> Doshi-A20614
> Sent: 31 January 2005 12:58
> To: 'pgsql-bugs@postgresql.org'
> Subject: [BUGS] Template1 is locked when pgAdminIII is open
>
> In the PostgreSQL RC-1, whenever we have the p
In the PostgreSQL RC-1, whenever we have the pgAdminIII open and try to create
a database, it says that template1 is locked up and hence the database cannot
be created. I believe it shouldn't lock it up and allow the database to be
created.
If this bug has already been raised and fixed in subse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
A workaround is symlinking /usr/lib/kerberos/* to /usr.
We are aware of that and 7.4.7 will ship with that change.
Regards,
On Mon, 31 Jan 2005, Donald Fraser wrote:
I have a standard Redhat 9 installation with the exception of upgrading bison
to b
27 matches
Mail list logo
