The following bug has been logged on the website:
Bug reference: 7579
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
Hi,
After testing migration to 9.2.1, Segmentation fault query were found.
The following bug has been logged on the website:
Bug reference: 7580
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
create table t1 as select id from generate_series(1,10) as g(id);
crea
The following bug has been logged on the website:
Bug reference: 7581
Logged by: William Dauchy
Email address: wdau...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
I tried to compile pgsql9.2 with the following options: --with-blocksize=16
wdau...@gmail.com writes:
> I tried to compile pgsql9.2 with the following options: --with-blocksize=16
> and --with-wal-blocksize=16.
> Some tests failed. I didn't have the issue with pgsql9.1.
This is not a bug. There are any number of changes you could make that
would affect either plan select
Hello Tom,
Thank you for your reply,
On Wed, Oct 3, 2012 at 4:07 PM, Tom Lane wrote:
> This is not a bug. There are any number of changes you could make that
> would affect either plan selection or row ordering (which usually means
> the same thing) in the regression tests; block size is one, a
maxim.bo...@gmail.com writes:
> create table t1 as select id from generate_series(1,10) as g(id);
> create table t2 as select id from generate_series(1,10) as g(id);
> alter table t1 add primary key (id);
> alter table t2 add primary key (id);
> analyze t1;
> analyze t2;
> explain select *
Excerpts from wheelly's message of mar oct 02 05:49:27 -0300 2012:
> Where is a bug in PostgreSQL or in documentation?
I think it was a bug in the code. I have committed a patch that should
fix this problem.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
My Server has 4GB mem and OS is Windows 2008 R2.
I downloaded the latest version,and the cost of "not in" is much higher than
that of "not exist".Please see attachment for detail.
As the time of query is very long,I didn't get the explain analyze result.
I think the id columns of table a and b are
I downloaded the latest version,and the cost of "not in" is much higher than
that of "not exist". please see attachment for detail.
As the time of query is very long,I didn't get the explain analyze result.
I think the id columns of table a and b are not null, so the query of "not in"
and "not
The following bug has been logged on the website:
Bug reference: 7582
Logged by: Rain
Email address: sybr...@mail.ru
PostgreSQL version: 9.2.1
Operating system: Windows 7 x64
Description:
Service was started and then stopped. Some services automatically stop if
they a
l...@tom.com writes:
> I think the id columns of table a and b are not null, so the query of "not
> in" and "not exists" are equal,they should use similar plans.
NOT IN and NOT EXISTS are *not* equivalent. Per SQL standard, NOT IN
has different (and usually not very desirable) behavior with NUL
> > Test database have a bit unusual tablespace layout:
> > main tablespace partition was mounted inside data directory of the old
> > cluster...
> > E.g.:
> > data directory - /var/lib/postgresql/9.2/main
> > main tablespace (another partition mount point) -
> > /var/lib/postgresql/9.2/main/larged
I am seeing the situation where the reported flush location for the sync
standby (standby1 below) is *behind* the reported current xlog location
of the primary. This is Postgres 9.1.5 , and I was under the impression
that transactions initiated on the master do not commit until the
correspondin
On 4 October 2012 05:32, Mark Kirkwood wrote:
> I am seeing the situation where the reported flush location for the sync
> standby (standby1 below) is *behind* the reported current xlog location of
> the primary. This is Postgres 9.1.5 , and I was under the impression that
> transactions initiated
14 matches
Mail list logo
