|
|
Up |
|
|
  |
Author: Tom LaneTom Lane
Date: Jan 26, 2007 12:28
"Michael Eschweiler" writes:
> After having migrated my database with some PL/Python-functions, which
> worked fine under opensuse 10.1/Postgresql 8.1.3/Python 2.4, to oss
> 10.2/Postgresql 8.1.5/Python 2.5 the functions don't work any more.
I won't promise that PG 8.2 works 100%% with python 2.5, because it hasn't
been tested much, but it certainly has a better chance than 8.1.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
|
| |
|
| |
no comments
|
|
  |
Author: Tom LaneTom Lane
Date: Jan 26, 2007 12:24
Chris Dunlop onthe.net.au> writes:
> Trying to start the postmaster again failed, with what looks
> like the relevent message being:
> PANIC: btree_delete_page_redo: lost target page
This is a known possibility if the VACUUM FULL got as far as shortening
the index before crashing --- xlog replay gets unhappy if told to fix
a page that's not there anymore. There's a fix in 8.2, which IIRC
seemed too complex to risk back-porting.
regards, tom lane
|
| |
|
| |
no comments
|
|
  |
Author: Maciej BabinskiMaciej Babinski
Date: Jan 26, 2007 12:12
Tom Lane wrote:
> Maciej Babinski apathy.killer-robot.net> writes:
>> Tom Lane wrote:
>>> I see no bug here. AFAICT your "much faster" query gets that way by
>>> having eliminated all the candidate join rows on the B side.
>
>> The additional clause eliminates no rows beyond what the existing
>> clause would. Any row eliminated by "b.join_id IS NOT NULL" could not
>> possibly have satisfied "a.join_id = b.join_id".
>
> Hmm. You assume that the = operator is strict, which is probably true,
> but the hash join code isn't assuming that.
>
Yes, both queries return identical results.
|
| Show full article (2.96Kb) |
|
no comments
|
|
  |
Author: Maciej BabinskiMaciej Babinski
Date: Jan 26, 2007 12:11
Tom Lane wrote:
> "Maciej Babinski" apathy.killer-robot.net> writes:
>> Hash join of columns with many null fields is very slow unless the null
>> fields are commented out.
>
> I see no bug here. AFAICT your "much faster" query gets that way by
> having eliminated all the candidate join rows on the B side.
>
> regards, tom lane
The additional clause eliminates no rows beyond what the existing clause
would.
Any row eliminated by "b.join_id IS NOT NULL" could not possibly have
satisfied
"a.join_id = b.join_id".
Please note that if the join columns are not null, but still produce no
matches
for the join, the results are fast without the need for an extra clause
in the join:
|
| Show full article (1.76Kb) |
|
no comments
|
|
  |
Author: inifinityinifinity
Date: Jan 26, 2007 12:11
The following bug has been logged online:
Bug reference: 2934
Logged by: inifinity
Email address: priyatam@ gmail.com
PostgreSQL version: 8.2
Operating system: Windows XP
Description: INSTALL FAILURE - failed to set permissions on the
installed files
Details:
I've been trying to install this from past two days and all I can see is a
an error message towards the end of installation and a log file which I
cannot acccess in my default C:\program files\postrgresql\8.2
the error says to check a log file perm.log but I cannot browse or delete
the *\8.2 folder. says access denied.
I have a admin user account and Im 100%% sure I have given the right
username/pwd in the first page of the installation with 'postgresql' as a
superuser (and a diff pwd).
Tried searching all forums but no result.
|
| Show full article (2.12Kb) |
|
no comments
|
|
  |
Author: Michael EschweilerMichael Eschweiler
Date: Jan 26, 2007 12:11
The following bug has been logged online:
Bug reference: 2933
Logged by: Michael Eschweiler
Email address: michael.eschweiler@t-online.de
PostgreSQL version: 8.1.5
Operating system: opensuse 10.2 / Python 2.5
Description: PL/Python-functions don't work any more
Details:
After having migrated my database with some PL/Python-functions, which
worked fine under opensuse 10.1/Postgresql 8.1.3/Python 2.4, to oss
10.2/Postgresql 8.1.5/Python 2.5 the functions don't work any more. When I
try to use even a very simple PL/Python-function the servers cuts the
connection inexpectedly. In the mailing-lists I found that there have been
problems with Python 2.5 - see bug report #2720 but I couldn't find a hint
if this problem is fixed. Therefore my question: Is this problem fixed in
Postgresql 8.2 or should I downgrade to Python 2.4.
Thanks
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
|
| |
|
no comments
|
|
  |
Author: Ilya KoganIlya Kogan
Date: Jan 26, 2007 12:10
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE7BB95F3457B0BB4D786E188
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Magnus Hagander wrote:
> To me this sounds like the theme is broken. Especially since we only us=
e it to look for terminal services stuff iirc. it'd be interesting to see=
if this can be=20
> reproduced...
|
| Show full article (2.46Kb) |
|
no comments
|
|
  |
Author: James BecerraJames Becerra
Date: Jan 26, 2007 12:10
Good Morning,
I suppose it was the problem, but to solve this, I have disabled the windows
firewall. I am worried because I have a server with windows 2003 server
running and sql server 2005 and IIS and PHP and Postgres 8.1, I tried to
connect locally but the problem is the same, I installed the same version of
Postgres in other computer and it works good, I made a copy of the folder on
my server and I replaced the new Postgres installation in the other
computer, and it the new computer still working good, but I couldn=92t see =
the
data bases. I know the Postgres data files folder but it is invisible to new
installation.=20
How I can solve this problem with this port. I stopped the Postgres service
in my server, and I started it again, I have restarted the server, I=92ve
configured the Postgres configuration files manually, and disable the
firewall and the problem persists.
|
| Show full article (3.80Kb) |
|
no comments
|
|
  |
Author: Maarten van der HeijdenMaarten van der Heijden
Date: Jan 26, 2007 12:10
Hi,
Still no luck initializing the Database Cluster. I'm wondering which comman=
ds/files InitDb uses...it says something is missing, I would like to know w=
hat, is there a way or does someone know which programs\commands InitDb use=
s?
Regards,
Maarten
-----Oorspronkelijk bericht-----
Van: Magnus Hagander [mailto:magnus@ hagander.net]=20
Verzonden: zondag 21 januari 2007 18:24
Aan: Maarten van der Heijden
CC: pgsql-bugs@ postgresql.org
Onderwerp: Re: [BUGS] Troubles in Initializing Postgres Database 8.2
Maarten van der Heijden wrote:
> I=92m having trouble initialzing the PostGres Database 8.2 on Windows Xp
> Embedded. Installation using the windows installer is going fine until
> the initialization process is started. See below for the log. Installing
> postgres without initializing the database cluster is also working fine.
Not sure anybody has ever managed to install/run pg on XP Embedded.
|
| Show full article (3.26Kb) |
|
no comments
|
|
  |
|
|
  |
Author: Chris DunlopChris Dunlop
Date: Jan 26, 2007 12:10
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
G'day all,
PG version: 7.4.7 (debian 7.4.7-6sarge2)
OS: Linux (debian sarge)
I started a 'vacuum full analyze' using pgsql, then, after
about 10 minutes, I issued a control-c in pgsql. This hadn't
returned my prompt after another 10 minutes or so. A glance at
the backend showed other processes running and some apparently
hanging around, possibly blocked by the vacuum.
Eventually I did a shutdown using the debian
/etc/init.d/postgresql script. This tried shutting the
postmaster down cleanly, but eventually 'kill -9'ed the
postmaster (much to my surpise, given the ever present "TIP 2:
Don't 'kill -9' the postmaster" - just goes to show, you
shouldn't trust *anyone*!).
Anyhow, given the 'kill -9' I guess you could stop reading right
here...
|
| Show full article (6.67Kb) |
|
no comments
|
|
|
|
|