On 10/14/13 2:31 PM, Benjamin Wassermann wrote:
but the PG_dump.exe cant free memory which is allocated by libpq.dll.
To fix this problem the "libpq.dll" need a new function named
"deletePQCharPointer()"
libpq already provides that functionality in PQfreemem():
http://www.postgresql.org/docs/
We finally find out why this problem occurs.
PG_dump use some Functions like
initPQExpBuffer(..)
from the libpq.dll.
In this function "initPQExpBuffer(...)" are some memory allocated with
malloc(...).
(File: "pg_dump.c", line 9366)
After the function is successfully dumped to backup file, there
Try
SHOW search_path;
On both the good and bad connection. Is it possible you have some code
setting it and leaving it set incorrectly?
--
greg
On 12 Oct 2013 23:17, "John R Pierce" wrote:
> On 10/9/2013 10:35 AM, nbudu...@gmail.com wrote:
>
>> Basically, at some point a query, update or inser
On 10/9/2013 10:35 AM, nbudu...@gmail.com wrote:
Basically, at some point a query, update or insert will not work and
complain about a table not existing, but that table was used without any
issue previously. Closing the running connection to the database and
reconnecting make that error disappea
On 9.10.2013 19:35, nbudu...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8515
> Logged by: Nicolas Buduroi
> Email address: nbudu...@gmail.com
> PostgreSQL version: 9.2.4
> Operating system: ArchLinux
> Description:
>
> We'v
On 10/12/2013 2:49 PM, Tomas Vondra wrote:
I'm not sure what "54450 platform" is
Presumably, the OP is referring to Freescale ColdFire MCF54450, one of
an embedded family of 68000 like CPUs (not binary compatible, just
assembler source compatible, and missing some parts of the 68000
architec
On 11.10.2013 08:14, Michael Paquier wrote:
> On Thu, Oct 10, 2013 at 1:24 AM, wrote:
>> my postgresql running file . but sometime i found cache lookup
>> failed for relation 421062806 error in postgresql log. can anyone
>> tell me significant of this error.
>
> A relation has disappeared even
On 12.10.2013 11:15, Zhang, Hongwei wrote:
> Dear sir,
>
> We are trying to port the PostGreSQL on the m68K platform, we’ve
> compiled it well, but failed to run it on the 54450 platform. I am
> wondering who we could refer to for help? Is there any commercial
> service that we could use for that
> According to the documentation, f() should be marked VOLATILE also, since
> calling f() produces side effects. PostgreSQL does not give a warning (or
> better yet, an error); I think it should.
I think the answer is that function authors are required to prevent
functions they mark as STABLE from
Terje Elde writes:
> Would it be possible (and make sense) to solve this in a completely different
> way, not walking the function tree or doing static analysis, but simply
> setting and checking a bit during execution?
While it's possible that we could do something like that, I think it's
fair
Gabriel Ciubotaru writes:
> There's a problem with expanding Bit String data types, it make
> right padding with 0 instead of left padding , making the bit mask
> almost useless.
You need to show an example of the problem; this report has no details
that would let us fix anything.
On Oct 11, 2013, at 9:21 AM, Dimitri Fontaine wrote:
> Inter function dependencies is a hard topic indeed. I still would like
> to see some kind of progress being made someday. The general case is
> turing complete tho, because you can use EXECUTE against programatically
> generated SQL.
>
> You
'Bruce Momjian' writes:
> Well, we can't walk the function tree to know all called functions, and
> those they call, so we don't even try.
Inter function dependencies is a hard topic indeed. I still would like
to see some kind of progress being made someday. The general case is
turing complete th
On Thu, Oct 10, 2013 at 1:24 AM, wrote:
> my postgresql running file . but sometime i found cache lookup failed for
> relation 421062806 error in postgresql log. can anyone tell me significant
> of this error.
A relation has disappeared even if the session hold a sufficient lock
on it, ensuring t
On Thu, Oct 10, 2013 at 08:32:32PM -0400, Bruce Momjian wrote:
> > > How can the later entry not be MD5 hash?
> >
> > Because what you pass to the functions is 'md5', not 'md5 hash', which
> > is what the new text appears to indicate.
>
> So if we revert, will it still be clear what is MD5 and w
On Thu, Oct 10, 2013 at 08:22:30PM -0400, Peter Eisentraut wrote:
> On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote:
> > > The changes shown below are incorrect, I think.
> > >
> > >
> > > On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > > > *** gen_salt(type text [, iter_count in
On Thu, 2013-10-10 at 19:14 -0400, Bruce Momjian wrote:
> > The changes shown below are incorrect, I think.
> >
> >
> > On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > > *** gen_salt(type text [, iter_count integer
> > > *** 353,359
> > > 12 years
> > >
> > >
On Thu, Oct 10, 2013 at 04:10:35PM -0700, Dwayne Towell wrote:
> > According to the documentation, f() should be marked VOLATILE also, since
> > calling f() produces side effects. PostgreSQL does not give a warning (or
> > better yet, an error); I think it should.
>
> I think the answer is that fu
On Thu, Oct 10, 2013 at 04:05:50PM -0400, Peter Eisentraut wrote:
> The changes shown below are incorrect, I think.
>
>
> On 10/2/13 12:00 PM, Bruce Momjian wrote:
> > *** gen_salt(type text [, iter_count integer
> > *** 353,359
> > 12 years
> >
> >
> >
On Wed, Oct 9, 2013 at 08:58:46PM +, dwa...@docketnavigator.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8516
> Logged by: Dwayne Towell
> Email address: dwa...@docketnavigator.com
> PostgreSQL version: 9.2.4
> Operating system: CentOS
On Thu, Oct 10, 2013 at 2:48 PM, Alvaro Herrera
wrote:
>> Could you please give me a hint of how to check if this patch was
>> included in 9.2.5 or not?
>
> Yes, this was committed in June:
>
> commit 99ee15b315c187045a95db7b27fd9d866aea93e0
> Author: Simon Riggs
> Date: Sun Jun 23 11:05:02 201
Sergey Konoplev escribió:
> On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane wrote:
> > Sergey Konoplev writes:
> >> Just curious, what is the planned date for the next minor release, and
> >> BTW where is it possible to see the roadmap for minor releases?
> >
> > There is no planned date, and certainly
On Tue, Jun 11, 2013 at 6:50 AM, Tom Lane wrote:
> Sergey Konoplev writes:
>> Just curious, what is the planned date for the next minor release, and
>> BTW where is it possible to see the roadmap for minor releases?
>
> There is no planned date, and certainly no "roadmap". We make minor
> releas
On 10/10/2013 7:18 AM, Andrius Di wrote:
Hello, how to solve this error (please see attachment)?
what exactly were you doing when you got this error, what Windows
version was this on, etc etc?
the error is pretty explicit, I would inspect the value of your COMSPEC
environment variable. fo
On 10/10/2013 6:27 AM, s.mech...@gmail.com wrote:
I'm trying since yesterday to install a software which needs to install
postgreSQL 8.4 aswell. When the installation is finished, a message appears
a few times which says
"The 3873 ordinal can't be find in the LIBEAY32.dll dynamic library" (in
fre
The changes shown below are incorrect, I think.
On 10/2/13 12:00 PM, Bruce Momjian wrote:
> *** gen_salt(type text [, iter_count integer
> *** 353,359
> 12 years
>
>
> !md5
> 2345086
> 1 day
> 3 years
> --- 358,364 ---
Hi,
I *think* I fixed this problem. We will release updated packages
tomorrow, along with the PostgreSQL minor release updates. Please let me
know if they still don't work. :)
Regards, Devrim
On Fri, 2013-10-04 at 13:26 +, kyri...@alumni.princeton.edu wrote:
> The following bug has been log
* k...@roeckx.be (k...@roeckx.be) wrote:
> Allows SELECT from any column, or the specific columns listed, of the
> specified table, view, or sequence. Also allows the use of COPY TO. This
> privilege is also needed to reference existing column values in UPDATE or
> DELETE.
>
>
> I read that a
On Wed, Oct 2, 2013 at 12:00:44PM -0400, Bruce Momjian wrote:
> Based on your report, I have developed the attached doc patch which
> clarifies when MD5 hash is being referenced, and when MD5 crypt is. I
> have also added your other suggestions.
Patch applied, and backpatched to 9.3.X. Thanks f
We shouldn't have a problem with using pg_upgrade with the hard link option to upgrade from postgreSQL 9.1.6 after I get the spatial component upgraded to postgis 2.1, then straight to postgreSQL 9.3, Right? thanks
Original Message
Subject: Re: [BUGS] Installing/Upgr
On Mon, Oct 7, 2013 at 08:07:42AM -0700, fburg...@radiantblue.com wrote:
> Bruce, Proposed Steps. Do they look feasible?
>
> 1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/
> testdb.backup" testdb
> 2.) CREATE DATABASE newdb TEMPLATE=template_postgis;
> 3.) perl ../postgis-p
On Tue, Oct 8, 2013 at 1:32 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8511
> Logged by: Tejas
> Email address: shahtejas2...@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: Linux
> Description:
>
> cache lookup f
On 10/8/2013 1:02 AM, shahtejas2...@gmail.com wrote:
The following bug has been logged on the website:
Bug reference: 8511
Logged by: Tejas
Email address: shahtejas2...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system: Linux
Description:
cache lookup faile
Hi
Installer does not change the permissions on all files.. it just changes
the permissions on the folders mentioned in the data directory path (except
C:\ and C:\Program Files).. It may be because of the inheritance that
icacls just scans through all the files..
Anyways, in 9.3.1, by default the
can we just use pg_upgrade with the hard links option, instead of copying files to the new cluster option to upgrade to PostgreSQL 9.3?
Original Message ----
Subject: Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known
bugs?
From: Bruce Momjian <br...@momjian.us>
Date:
Alvaro Herrera wrote:
> AFAICS the problem here is that this test doesn't use MultiXactIds at
> all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
> me to put in an optimization which would have avoided this issue; I will
> give that a thought. I don't think I will be able to
Oskari Saarenmaa wrote:
> 05.10.2013 01:31, Alvaro Herrera kirjoitti:
> > AFAICS the problem here is that this test doesn't use MultiXactIds at
> > all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
> > me to put in an optimization which would have avoided this issue; I will
>
Oskari Saarenmaa wrote:
> 05.10.2013 01:31, Alvaro Herrera kirjoitti:
> > AFAICS the problem here is that this test doesn't use MultiXactIds at
> > all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
> > me to put in an optimization which would have avoided this issue; I will
>
On Sat, Oct 5, 2013 at 9:38 PM, Dave Page wrote:
>
>
>> On 5 Oct 2013, at 13:21, Michael Paquier wrote:
>>
>>> On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation wrote:
>>> Disregard my bug complaint. Stupid user error.
>> Btw, the next time you find an error with this installer, you should
>
On Fri, Oct 4, 2013 at 10:20:46PM +0200, Stefan Kaltenbrunner wrote:
> >> http://www.postgresql.org/message-id/201106291934.23089.rsmog...@softperience.eu
> >
> > There are two other similar bug reports on this from February and March
> > of this year:
> >
> >
> > http://www.postgresql.org/
> On 5 Oct 2013, at 13:21, Michael Paquier wrote:
>
>> On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation wrote:
>> Disregard my bug complaint. Stupid user error.
> Btw, the next time you find an error with this installer, you should
> not use this mailing list for this purpose but contact
On Fri, Oct 4, 2013 at 11:36 AM, Paragon Corporation wrote:
> Disregard my bug complaint. Stupid user error.
Btw, the next time you find an error with this installer, you should
not use this mailing list for this purpose but contact directly EDB as
this installer is maintained by them and not by
05.10.2013 01:31, Alvaro Herrera kirjoitti:
> AFAICS the problem here is that this test doesn't use MultiXactIds at
> all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
> me to put in an optimization which would have avoided this issue; I will
> give that a thought. I don't t
AFAICS the problem here is that this test doesn't use MultiXactIds at
all in 9.2, but it does in 9.3. I vaguely recall Noah tried to convince
me to put in an optimization which would have avoided this issue; I will
give that a thought. I don't think I will be able to get it done for
9.3.1 though.
On 10/02/2013 06:19 PM, Bruce Momjian wrote:
> On Tue, Sep 24, 2013 at 06:43:19PM +, dennis.noord...@helsinki.fi wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 8469
>> Logged by: Dennis
>> Email address: dennis.noord...@helsinki.fi
>> Postgre
I spent a lot of time looking at this issue. Your problem scenario can
be reduced to the following test case:
CREATE TABLE t (a INT);
INSERT INTO t VALUES (1);
The three sessions need to execute the following commands, in this
sequence:
-- Session 1
/* 1 */ BEGIN;
SELECT * FROM t FOR UPDATE;
-
Re: Bruce Momjian 2013-10-02 <20131002170628.gc5...@momjian.us>
> That is very interesting, and it certainly should not be failing.
>
> I am surprised it got an oid that was one less than the desired one,
> 18803. Is there any mention of 18803 in the SQL file?
18803 wasn't mentioned anywhere, ju
2013/10/4 Heikki Linnakangas
> On 02.10.2013 14:57,
> manindra.sarkar@brightnorth.**co.ukwrote:
>
>> Excel does not seem to respond with any data - but does give an idea that
>> it
>> has made some sort of a connection with the database. SQL commands fail
>> from
>> being executed.
>>
>
It is st
On 02.10.2013 14:57, manindra.sar...@brightnorth.co.uk wrote:
Excel does not seem to respond with any data - but does give an idea that it
has made some sort of a connection with the database. SQL commands fail from
being executed.
I'm afraid you'll have to provide a lot more details for anyone
Disregard my bug complaint. Stupid user error.
Thanks,
Regina
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 2013-10-03 19:07:37 +0200, Tom Lane wrote:
> Andres Freund writes:
> > Starting postgres with a CWD that's not readable will trigger an Assert
> > and if those are disabled it presumably will segfault.
>
> Yeah, we've discussed that before. I'm not sure it's worth fixing,
> or that it could b
Andres Freund writes:
> Starting postgres with a CWD that's not readable will trigger an Assert
> and if those are disabled it presumably will segfault.
Yeah, we've discussed that before. I'm not sure it's worth fixing,
or that it could be counted on to stay fixed even if we removed the
current
On Thu, Sep 26, 2013 at 02:59:30PM +0200, Christoph Berg wrote:
> On upgrading a 9.0 database to 9.2 using pg_upgrade, I got this:
>
> # pg_upgradecluster -m upgrade 9.0 main /psql/data-9.2
> [...]
> Performing Upgrade
> --
> [...]
> Restoring database schema to new cluster
On Tue, Sep 24, 2013 at 06:43:19PM +, dennis.noord...@helsinki.fi wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8469
> Logged by: Dennis
> Email address: dennis.noord...@helsinki.fi
> PostgreSQL version: 9.3.0
> Operating system: FreeBSD 9.2
On Tue, Sep 24, 2013 at 11:20:55PM +0100, Richard Neill wrote:
> I'm sorry about that: I think I need to correct my proposed
> correction! I think I've been writing too much C recently, and so I
> foolishly mis-read that as returning pswhash, rather than returning
> the truth of the comparison.
>
On Fri, Sep 20, 2013 at 02:00:05PM -0700, John R Pierce wrote:
> On 9/20/2013 1:51 PM, fburg...@radiantblue.com wrote:
>
> 1.) During our prior upgrade process we used pg_upgrade to move from pg
> 8.4.3 to 9.1.6 using the hard links install option, we also have our data
> spread across
On Fri, Sep 20, 2013 at 11:15:01AM +0200, Alexey Klyukin wrote:
> Hi,
>
> We've discovered a surprising behavior of psql \i command. What we sometimes
> to
> add new tables to the database is:
>
> begin;
> \i /path/to/table/definitions/table1.sql
> \i /path/to/table/definitions/table2.sql
> ...
On 01/10/13 15:17, h...@canwrx.com wrote:
a) My version is Postgres Enterprise Manager version 3.0.0, copyright
2002-2012, the pgAdmin Development Team; and Postgres Plus Advanced Server
9.2
Hi - your product is supported by Enterprisedb
(http://www.enterprisedb.com/). I think you would
Hello
2013/10/1
> The following bug has been logged on the website:
>
> Bug reference: 8495
> Logged by: Miguel A. Manso Callejo
> Email address: m.ma...@upm.es
> PostgreSQL version: 9.1.9
> Operating system: Ubuntu 12.04LTS
> Description:
>
> I'm trying to random access to
Hi,
Sorry I hadn't noticed this thread.
Tomonari Katsumata escribió:
> It seems to be related to some changes in
> the [Improve concurrency of foreign key locking] commit(*).
> (*) commitid : 0ac5ad5134f2769ccbaefec73844f8504c4d6182
> Because I could not reproduce "dead lock" before the commit.
Hi,
Thanks to your info, otsuka-san.
It seems to be related to some changes in
the [Improve concurrency of foreign key locking] commit(*).
(*) commitid : 0ac5ad5134f2769ccbaefec73844f8504c4d6182
Because I could not reproduce "dead lock" before the commit.
And I'm thinking that also this commit is
On Thu, 2013-09-26 at 21:18 -0400, Bruce Momjian wrote:
> On Mon, Sep 16, 2013 at 08:40:57AM +, j.rom...@salsa.es wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference: 8455
> > Logged by: Jesus Romero
> > Email address: j.rom...@salsa.es
> > Pos
On Mon, Sep 16, 2013 at 08:40:57AM +, j.rom...@salsa.es wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8455
> Logged by: Jesus Romero
> Email address: j.rom...@salsa.es
> PostgreSQL version: 9.1.9
> Operating system: Ubuntu server 12.04
> Des
On Thu, Sep 26, 2013 at 4:19 PM, David Rennalls wrote:
> On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate wrote:
>> I have seen this issue on a slave although it was in version 9.2. I ran
>
> oh ok. Looks like the issue was fixed in 8.2.23 according to these
> release notes http://www.postgresql.o
On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate wrote:
> I have seen this issue on a slave although it was in version 9.2. I ran
oh ok. Looks like the issue was fixed in 8.2.23 according to these
release notes http://www.postgresql.org/docs/8.2/static/release-8-2-23.html
...
o Fix race condition
I have seen this issue on a slave although it was in version 9.2. I ran
this
select 2619::regclass;
regclass
--
pg_statistic
(1 row)
I was able to fix my select issue by running analyze on the database
On Thu, Sep 26, 2013 at 11:47 AM, David Rennalls wrote:
> David Fetter
David Fetter fetter.org> writes:
>
> Upgrade to 9.1.3 and let us know whether that fixes the problem.
I've run into this issue as well on postgres 8.4.14. Aside from upgrading to a
newer release is there any manual fixup that can be done ?
Thanks,
David
--
Sent via pgsql-bugs mailing
On Mon, Sep 23, 2013 at 3:33 PM, Heikki Linnakangas
> I can see why you'd want that, but it seems equally problematic to let
> pg_basebackup return, when the WAL files haven't been archived yet and you
> therefore don't in fact have valid, restorable backup yet. Have you
> considered using the --x
o...@ohmu.fi wrote:
> The following code performs a lot slower on PostgreSQL 9.3.0 than on
> PostgreSQL 9.2.4:
>
> DROP TABLE IF EXISTS tmp;
> CREATE TABLE tmp (id BIGSERIAL, vals BIGINT[]);
> DO $$
> DECLARE
> r_id BIGINT;
> n BIGINT;
> BEGIN
> FOR n IN 1..1000 LOOP
> BEGIN
On 24.09.2013 14:42, marian.kruc...@gmail.com wrote:
CREATE INDEX ON tstzrange fail on 9.3.0 and 9.2.4 - default postgres
configuration.
It ate whole memory and was killed by oom.
Example:
postgres=# CREATE TABLE range_test AS SELECT tstzrange(t, t+'1min') tr FROM
generate_series('2000-1-1'::TI
Hi
Please send the installation log (install-postgresql.log) from the temp.
That will help us to know what went wrong.
On Wed, Sep 25, 2013 at 2:44 AM, Volberg, Ovsei <
ovsei.volb...@scientificgames.com> wrote:
> The error message is attached. The computer was Windows 7, 32-bit
> machine. Ple
Dear Magnus,
Thanks for your reply.
On 24/09/13 18:31, Magnus Hagander wrote:
The following bug has been logged on the website:
Bug reference: 8467
The documentation for pgcrypto:
http://www.postgresql.org/docs/current/static/pgcrypto.html
(and indeed all versions from 8.3-9.3)
contains
On Tue, Sep 24, 2013 at 1:11 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8467
> Logged by: Richard Neill
> Email address: postgre...@richardneill.org
> PostgreSQL version: 9.3.0
> Operating system: Documentation bug
> Description:
>
> The
Hi,
Updated packages will be in the repo in the next hour or so. Apologies
for the inconvenience.
Regards, Devrim
On Wed, 2013-09-18 at 13:56 +, kyri...@alumni.princeton.edu wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8463
> Logged by: Kriton
Hi Keikki,
it is clear what causes this problem, but pg_upgradecluster is an operation
which simply MUST work (if you have several hundred of user databases, it is
not an option to check all of them for this kind of error before the cluster
upgrade).
Database upgrade is performed by the server
On 13.09.2013 15:13, stu...@stuartbishop.net wrote:
pg_basebackup blocks until all necessary WAL files have been archived by
archive_command. This can take a few minutes under normal circumstances, and
indefinitely if archive_command is failing.
I would like to be able to disable this check, as
On 21.09.2013 20:16, jan.m...@inf-it.com wrote:
today I tried to upgrade from 9.2 to 9.3 (pg_upgradecluster 9.2 main) and
the upgrade of one of my databases failed with the following error: "ERROR:
new row for relation ... violates check constraint ...".
I created an example to reproduce this bu
On 16.09.2013 22:59, Andrew Gierth wrote:
"Heikki" == Heikki Linnakangas writes:
Heikki> Attached is a patch to fix both of these issues. I'm too
Heikki> tired right now to thoroughly test it and commit, so I'll get
Heikki> back to this tomorrow. Meanwhile, please take a look and let
Hi
It seems the data directory was not created. Please send the installation
logs from the %TEMP%.
On Sat, Sep 21, 2013 at 3:39 PM, Ludvík Adamec wrote:
> Hello, I have tried to install postgresql many times, but every time i
> have in instalation error: Problem running post-install step. Insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/2013 04:17 PM, Joe Conway wrote:
> If you still have a problem please provide SQL that can be cut and
> pasted which: 1) create your table 2) insert sample rows Then show
> us what out put you are trying to acheive as output from that
> data.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/19/2013 12:24 PM, Carl Clemens wrote:
> The following query appears to be correct but fails to execute.
Your example is incorrect, however it is not clear (to me at least)
from your example what you are expecting as output -- please see the
docu
On 9/20/2013 1:51 PM, fburg...@radiantblue.com wrote:
1.) During our prior upgrade process we used pg_upgrade to move from
pg 8.4.3 to 9.1.6 using the hard links install option, we also have
our data spread across disk storage mediums; fiber, nas. Are there any
known issues, bugs with using pg_
On 9/20/2013 10:05 AM, Thomas Kellerer wrote:
Dashputre, Anurag (GE Healthcare) wrote on 20.09.2013 08:39:
Thanks for your reply. We can't upgrade to newer version as of now.
We just want to know list of known issues on 8.1.19.
We will just note them down and do some impact analysis.
You will
Dashputre, Anurag (GE Healthcare) wrote on 20.09.2013 08:39:
Thanks for your reply. We can't upgrade to newer version as of now. We just
want to know list of known issues on 8.1.19.
We will just note them down and do some impact analysis.
You will need to go through the release notes for every
t.com]
Sent: Wednesday, September 18, 2013 8:28 PM
To: Dashputre, Anurag (GE Healthcare)
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] Known issues for PostgreSQL server 8.1.19
Hi,
On 2013-09-18 11:56:36 +, Dashputre, Anurag (GE Healthcare) wrote:
> We are using PostgreSQL server 8.1.1
Hi Michael & Team,
No anti-virus is running on that machine. I started the DB using Windows
service. Its working fine. I am trying to start the DB with different user
credentials using command prompt, the DB is not started. I provided full
permission for everyone to postgres folder and its sub fol
On Thu, Sep 12, 2013 at 10:21 AM, wrote:
> Bug reference: 8449
> I'm not able to link in Access to the table "map". I get an ODBC error and
> in the table fields are no data, it returns "#Name?".
>
> Any idea what is wrong ?
You should be more precise here:
- What is the version of ODBC driv
On Sat, Sep 14, 2013 at 4:15 PM, wrote:
> in short, for pgadmin...
This feature request is related to PGAdmin and not Postgres core. You
should send such requests to the PGAdmin mailing lists which are
listed here:
http://www.pgadmin.org/support/list.php
Regards,
--
Michael
--
Sent via pgsql
On Tue, Sep 17, 2013 at 4:48 PM, Marcelo Bacha wrote:
> I have an OpenBSD 5.3 server, with PostgreSQL 9.3.0, which seems to work
> fine. I´m trying to install on it, which always worked fine.
Postgres is working fine as you mention, and only PostGIS development
failed. Based on the information ab
On Tue, Sep 17, 2013 at 1:52 AM, Saravanan Nagarajan
wrote:
> In pglog_txt,
>
> LOG: could not bind IPv6 socket: No error
> HINT: Is another postmaster already running on port 33307? If not, wait a
> few seconds and retry.
> LOG: could not bind IPv4 socket: No error
> HINT: Is another postmast
Hi,
Thanks for the report. I created
http://wiki.pgrpms.org/ticket/141
to track this bug. There is another critical ticket pending for RHEL 6
packages, so expect the new package pretty soon.
Regards, Devrim
On Wed, 2013-09-18 at 13:56 +, kyri...@alumni.princeton.edu wrote:
> The followin
Hi,
On 2013-09-18 11:56:36 +, Dashputre, Anurag (GE Healthcare) wrote:
> We are using PostgreSQL server 8.1.19 in our product and as part of SDLC
> activities, we would like to know about the Known Issues present in this
> version.
The primary issue - especially regarding lifecycle - is tha
In pglog_txt,
LOG: could not bind IPv6 socket: No error
HINT: Is another postmaster already running on port 33307? If not, wait a
few seconds and retry.
LOG: could not bind IPv4 socket: No error
HINT: Is another postmaster already running on port 33307? If not, wait a
few seconds and retry.
WA
Hi,
On Mon, 2013-09-16 at 16:51 +, l...@cert.org wrote:
>
> The 9.3 non-RC1 RPMs are missing for Fedora 17 and 18 for i386.
My bad, uploaded.
>
> If those will not be made available, I'd be happy to rebuild from source
> once you release the SRPM for 9.3
There are some build issues in F
> "Heikki" == Heikki Linnakangas writes:
>> Also, receivexlog is ignoring .partial and .history files when
>> determining which timeline to start streaming from, which means
>> that if there are two timeline changes that are not separated by a
>> WAL segment switch, it will fail to operat
On 15.09.2013 15:02, and...@tao11.riddles.org.uk wrote:
The following bug has been logged on the website:
Bug reference: 8453
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.3.0
Operating system: any
Description:
The first snprintf
On 14.9.2013 14:12, Tomas Vondra wrote:
> On 13.9.2013 18:07, stephane.wust...@lip6.fr wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 8451
>> Logged by: strexxx
>> Email address: stephane.wust...@lip6.fr
>> PostgreSQL version: 9.1.9
>> Operating
On 13.9.2013 18:07, stephane.wust...@lip6.fr wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8451
> Logged by: strexxx
> Email address: stephane.wust...@lip6.fr
> PostgreSQL version: 9.1.9
> Operating system: Linux 3.8.0-27-generic #40-Ubuntu SMP
David Johnston writes:
>> Here is a minimal query that demonstrates the problem. In 9.1 it works:
>>
>> chris=# select * FROM current_user u join (current_user u cross join
>> current_user v) x on true;
>>
>> On 9.3 it fails:
>> ERROR: table name "u" specified more than once
This is an intent
"stormb...@gmail.com" wrote:
> [ Seq Scan is used on empty relation, rather than Index Scan ]
> This is not the expected result. [ ... ] it is still using
> sequential scan rather than what would be expected: Index Scan
This is not a bug.
If statistics indicate that all rows can be accessed w
1 - 100 of 25016 matches
Mail list logo
