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 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
> 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
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 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
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
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;
-
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 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 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 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
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
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
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 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
"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
On 2013-09-11 12:07:25 +, b.rychtar...@teb-akademia.pl wrote:
> executed full dump of database without oids:
> pg_dump -v -a -E UTF8 --disable-dollar-quoting --disable-triggers
>
>
> after restoring database from dump in each table there are rows with
> duplicated oids
So, just to make sure
On Mon, Sep 9, 2013 at 12:55 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8440
> Logged by: Jitendra Sabat
> Email address: sabat.jitendr...@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: Window server 2012
> Descr
Applied.
---
On Mon, Sep 9, 2013 at 09:16:05PM -0400, Bruce Momjian wrote:
> On Sun, Jan 20, 2013 at 10:33:37AM +, emes...@redhat.com wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference:
On Fri, Feb 8, 2013 at 06:46:29AM +, jackie.qq.zh...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7858
> Logged by: Jackie Zhang
> Email address: jackie.qq.zh...@gmail.com
> PostgreSQL version: 9.1.4
> Operating system: Ubuntu
>
On Fri, Feb 1, 2013 at 12:02:41PM +, i...@fduerr.de wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7844
> Logged by: fduerr
> Email address: i...@fduerr.de
> PostgreSQL version: 9.2.2
> Operating system: Debian
> Description:
>
> Up
On 10-09-2013 07:53, rajaprave...@gmail.com wrote:
> Sometimes It gives below message and some times without any error, it will
> be killed. Appreciate your help for solving the issue and please share
> recommended configuration settings for embedded platform.
>
You don't provide sufficient inform
On Tue, Jan 29, 2013 at 05:52:16PM -0500, Tom Lane wrote:
> Jeff Janes writes:
> > I figured out the need for the parenthesis by reading the docs. The
> > need to also quote 'binary' really took me by surprise, especially as
> > the other two formats don't need to be quoted. I assume the reason
On Tue, Jan 22, 2013 at 08:40:30PM +, tim.rom...@yahoo.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7824
> Logged by: Tim Romano
> Email address: tim.rom...@yahoo.com
> PostgreSQL version: 9.2.2
> Operating system: Windows 7 x64
> Descr
On Sun, Jan 20, 2013 at 10:33:37AM +, emes...@redhat.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7817
> Logged by: Eli Mesika
> Email address: emes...@redhat.com
> PostgreSQL version: 9.1.7
> Operating system: Fedora 16
> Description:
tv...@davincigroep.nl writes:
> CREATE OR REPLACE FUNCTION longlevenshtein (string1 character varying
> (100), string2 character varying (100)) RETURNS integer AS $$
> BEGIN
> IF (length(coalesce($1, '')) = 0 AND length(coalesce($2, '')) = 0) THEN
> RETURN 0;
> EL
Hi,
On 2013-09-09 17:26:48 +0200, Pavel Stehule wrote:
> it works on 9.1.9
That's probably a question of the configured/detected max_stack_depth.
I have quite some doubts such a naive implementation implemented in
plgsql will work for strings > 255 chars in sensible manner though.
Greetings,
A
Hello
it works on 9.1.9
postgres=# SELECT longlevenshtein(null, 'foobar');
longlevenshtein
-
6
Regards
Pavel
P.S. unlimitted varchar is "text" type in Postgres
2013/9/9
> The following bug has been logged on the website:
>
> Bug reference: 8441
> Logge
Applied.
---
On Wed, Sep 4, 2013 at 03:01:50PM -0400, Bruce Momjian wrote:
> On Wed, Dec 5, 2012 at 12:44:39AM +, el...@varlena.com wrote:
> > The following bug has been logged on the website:
> >
> > Bug reference:
Thanks. This will appear in PG 9.4.
---
On Tue, Jan 8, 2013 at 07:24:57AM +, t...@cs.ucsd.edu wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7799
> Logged by: Tianyin Xu
>
On Sat, Dec 15, 2012 at 03:31:55AM +, pg-...@snkmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7754
> Logged by: Gavan Schneider
> Email address: pg-...@snkmail.com
> PostgreSQL version: 9.2.2
> Operating system: OSX
> Description:
qwe...@hi.is writes:
> Just a few days ago we started randomly getting:
> relation "th_thjoderni" does not exist
You haven't really provided any information about what changed around the
time this started happening. What I'd wonder about is concurrent DDL on
these tables --- perhaps you added som
On Wed, Dec 5, 2012 at 12:44:39AM +, el...@varlena.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7730
> Logged by: elein
> Email address: el...@varlena.com
> PostgreSQL version: 9.2.1
> Operating system: Linux
> Description:
>
marta.mih...@dal.ca writes:
> Using the backup option (right click on an object) and then selecting the
> Objects tab: Not all objects appears in the list. This is true for versions
> 1.14.3 and the most recent version 1.16.1 downloaded today. I have a
> database called otn with over 100 schema. I
On Tue, 2013-08-06 at 12:27 -0400, Tom Lane wrote:
> koizumi...@minos.ocn.ne.jp writes:
> > In 8.17.10 "Constraints on Ranges" of PostgreSQL 9.2.4 Documentation, a
> > constraint will prevent the overlapping values in an example.
> > But in the example, range [2010-01-01 11:30, 2010-01-01 13:00) a
On Fri, Aug 30, 2013 at 2:13 PM, wrote:
> However, I think error message should filter dropped column and strange null
> values (because if a table has a lot dropped column this error message
> quickly become completely unreadable).
Yes, this is not really user-friendly. This comes from
ExecBuild
Andres Freund writes:
> On second thought, it might not be so good looking - the queries results
> are independent of the data from merge-append. So we only check that we
> don't crash and not that the results make any sense. How about the
> attached patch?
Good point --- pushed.
On 2013-08-30 19:28:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> >> Not sure. It's pretty disturbing that this wasn't caught earlier;
> >> it seems to me that means there's no regression coverage that hits
> >> ExecReScanMergeAppend. Howev
Andres Freund writes:
> On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
>> Not sure. It's pretty disturbing that this wasn't caught earlier;
>> it seems to me that means there's no regression coverage that hits
>> ExecReScanMergeAppend. However, I don't much like this specific test case
>> because
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
> >> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> >> binaryheap. Thus no new elements fit.
>
> > Ok, patch for that attached.
>
> I think the comme
Andres Freund writes:
> On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
>> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
>> binaryheap. Thus no new elements fit.
> Ok, patch for that attached.
I think the comments need a bit of copy-editing, but looks good otherwise.
Will
On Aug 31, 2013, at 12:22 AM, Tom Lane wrote:
> Or even more to the point, can you apply the just-posted patch and see
> if the problem goes away for you?
Will do.
At our current organic load though, we likely wouldn't get any good
confirmation either way this week.
I'll see if I can set up so
Andres Freund writes:
> Terje, do you use read committed or repeatable read/serializable?
Or even more to the point, can you apply the just-posted patch and see
if the problem goes away for you?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
On Aug 30, 2013, at 11:49 PM, Andres Freund wrote:
> Even better explanation: The merge append is some steps below a LockRows
> node, so the number of rescans might depend on the concurrency because
> we'll do the EvalPlanQual dance on a concurrent row update.
>
> Terje, do you use read committed
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > No need, found the bug. And I think can build a testcase myself.
>
> > ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> > binaryheap. Thus no new elements fit.
>
> Sounds like a bug all right, but I'm n
On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
> On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
> > Hi,
> >
> >
> > On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> > > I'm getting "out of binary heap slots", which offcourse spoils the fun of
> > > the query.
> >
> > > Explain analy
On 30. aug. 2013, at 23:05, Andres Freund wrote:
> No need, found the bug. And I think can build a testcase myself.
Sounds good. :)
Please do let me know if there's anything I can do.
Terje
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscriptio
On Aug 30, 2013, at 10:46 PM, te...@elde.net wrote:
> The following bug has been logged on the website:
That didn't work out too well, rendering-wize.
Sending the explain analyze by email as well, hoping it'll be more readable:
Hi,
On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> I'm getting "out of binary heap slots", which offcourse spoils the fun of
> the query.
> Explain analyze gives this plan (again anonymized a bit, but can send proper
> off-list):
Since I reviewed the patch that introduced that message, I
On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
> Hi,
>
>
> On 2013-08-30 20:46:27 +, te...@elde.net wrote:
> > I'm getting "out of binary heap slots", which offcourse spoils the fun of
> > the query.
>
> > Explain analyze gives this plan (again anonymized a bit, but can send proper
> > o
1 - 100 of 13819 matches
Mail list logo
