The following bug has been logged on the website:
Bug reference: 6391
Logged by: John
Email address: john.ud...@zionsbancorp.com
PostgreSQL version: 8.4.1
Operating system: CentOS
Description:
I would expect that at the time/date of the of now() and clock_timestamp()
The following bug has been logged on the website:
Bug reference: 6392
Logged by: Vic
Email address: v...@nix.kh.ua
PostgreSQL version: 9.0.6
Operating system: FreeBSD/Linux
Description:
While trying load database dump, postgresql (server process) eat up all
memory, in
Hi,
I am using postgres database server 8.3 for my internal project
installed in windows machine.
Database size is crossed more than 22 GB and tried to take backup using
the postgres back up command. But, backup process takes more time and
process is unsuccessful.
Can you able to suggest a
Hello!
On Tuesday, January 10, 2012, 10:11:04 PM you wrote:
HL> That clearly looks like a bug in the SSI feature, introduced in
HL> PostgreSQL 9.1.
HL> This looks superficically similar to the bug that Dan Ports spotted on
HL> Friday:
HL> http://www.mail-archive.com/pgsql-hackers@postgresql.org
wrote:
> PostgreSQL version: 8.4.1
You are missing years of bug fixes. You should be staying more
up-to-date on minor releases.
http://www.postgresql.org/support/versioning/
To review what has been fixed between 8.4.1 and 8.4.10, please look
through the links from 8.4.2 and up on this pag
On 11.01.2012 02:24, v...@nix.kh.ua wrote:
The following bug has been logged on the website:
Bug reference: 6392
Logged by: Vic
Email address: v...@nix.kh.ua
PostgreSQL version: 9.0.6
Operating system: FreeBSD/Linux
Description:
While trying load database dump, postgresql (
john.ud...@zionsbancorp.com writes:
> I would expect that at the time/date of the of now() and clock_timestamp()
> to be equal; which they are.
Well, they are not in general, but that doesn't appear to be your
problem. You have not shown us a reproducible test case, but I wonder
whether your tabl
Excerpts from maxim.boguk's message of mar ene 10 23:00:59 -0300 2012:
> The following bug has been logged on the website:
>
> Bug reference: 6393
> Logged by: Maxim Boguk
> Email address: maxim.bo...@gmail.com
> PostgreSQL version: 9.0.6
> Operating system: Linux Ubuntu
> De
Andrew Alcheyev wrote:
> Well, it does good and the backend hasn't crashed yet, but the
> client is still experiencing query problems at some point (not
> far, I guess, from where its backend would segfault without the
> patch). This time it encounters the following error from the
> backend:
>
naveen wrote:
> backup process takes more time
How much?
> process is unsuccessful.
In what way? Is there an error message? If so, please paste it.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
John Udick wrote:
> We did notice that although now() failed, changing this to
> 'now()'::date works (using single quotes around now()).
That seem unrelated to the now() function. Casting a literal to a
date/time/timestamp supports parsing out certain keywords, like
'now', 'today', 'yesterday
"Kevin Grittner" writes:
> John Udick wrote:
>> "PostgreSQL 8.2.15 (Greenplum Database 4.1.1.5 build 1) on
>> x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled
>> on Sep 20 2011 11:09:08"
> Yeah, I don't know how much the community lists can help with that
> implementation. I
yes, you right about inet.
Thanks for reply!
On Wed, 11 Jan 2012, Heikki Linnakangas wrote:
On 11.01.2012 02:24, v...@nix.kh.ua wrote:
The following bug has been logged on the website:
Bug reference: 6392
Logged by: Vic
Email address: v...@nix.kh.ua
PostgreSQL version
Following the example provided, this still appears to be a bug. The results are
very different when we run the example. We did notice that although now()
failed, changing this to 'now()'::date works (using single quotes around
now()). I will be working with our administrators to review patches a
When I do this
CREATE TABLE "*T1*"
> (
> "T1_ID" bigint NOT NULL,
> CONSTRAINT "*T1*" PRIMARY KEY ("T1_ID" )
> );
I get the following message:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "T1" for
> table "T1"
> ERROR: relation "T1" already exists
> ** Error *
Hi all,
Monday RhodiumToad/Andrew Gierth and I tried to debug a plan of raptelan
(CCed) getting rather strange plans. After trawling through some unrelated
stuff we diagnosed that the problem were some rather strange estimates.
I managed to extract a reproducable, simple testcase. Our analysis
r d wrote:
> When I do this
>
> CREATE TABLE "*T1*"
> (
> "T1_ID" bigint NOT NULL,
> CONSTRAINT "*T1*" PRIMARY KEY ("T1_ID" )
> );
>
>
> I get the following message:
>
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "T1" for table "T1"
> ERROR: relation "T1" already e
The following bug has been logged on the website:
Bug reference: 6394
Logged by: wilson camargo
Email address: desarroll...@desysteconline.com
PostgreSQL version: 8.4.0
Operating system: Linux (Centos)
Description:
Tengo un incidente con barias transacciones, el caso
2012/1/11 :
> The following bug has been logged on the website:
>
This is not a bug.
and just for the record i redirected the mail with an explanation (and
a brief answer to his problem) to pgsql-es-ayuda where OP can found
more help in spanish
--
Jaime Casanova www.2ndQuadrant.com
Prof
r d writes:
> The SQLSTATE 42P07 is described in the manual as only as "table undefined",
> and it is not clear if the intent is to allow or
> disallow the creation of a constraint called the same as the table in
> Postgresql.
Where do you see that? In Appendix A that code is listed as
"duplicat
Andres Freund writes:
> Whats your opinion on this?
Looks pretty bogus to me. You're essentially assuming that the side of
the join without statistics is unique, which is a mighty dubious
assumption. (In cases where we *know* it's unique, something like this
could be reasonable, but I believe g
On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
> Andres Freund writes:
> Also, why the asymmetry in null handling? And why did you only touch
> one of the two code paths in eqjoinsel_semi? They have both got this
> issue of how to estimate with inadequate stats.
This patch was purely
On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
> (In cases where we know it's unique, something like this
> could be reasonable, but I believe get_variable_numdistinct already
> accounts for such cases.)
One of those case which looks relatively easy is that CTEs currently work as a
kin
Andres Freund writes:
> On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
>> Looks pretty bogus to me. You're essentially assuming that the side of
>> the join without statistics is unique, which is a mighty dubious
>> assumption.
> It sure is a bit dubious. But assuming that a semijoi
On Thursday, January 12, 2012 02:24:44 AM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, January 12, 2012 01:01:01 AM Tom Lane wrote:
> >> Looks pretty bogus to me. You're essentially assuming that the side of
> >> the join without statistics is unique, which is a mighty dubious
> >> as
Hi.
The test case:
The first stage - preparation:
CREATE TABLE test (id serial primary key, flag integer, value text);
cluster "test_pkey" on test;
insert into test select nextval('test_id_seq') as id, 0 as flag,(SELECT
array(select random() from generate_series(1,1000)))::text as value from
gen
26 matches
Mail list logo
