Hi,
On Sat, Aug 6, 2011 at 12:18 AM, Noah Misch wrote:
> A PG_SYSLOG_LIMIT value that loses data to truncation on nearly every default
> GNU/Linux installation makes for a poor default.
On Sat, Aug 6, 2011 at 3:03 AM, Tom Lane wrote:
> OK, applied to HEAD and 9.1.
We hit this problem a few day
On Mon, Oct 31, 2011 at 1:50 PM, Robert Haas wrote:
> If you can't do that for some reason, there's always auto_explain, but
> that has some overhead and is a bit more work to set up.
If it's a massive load of data with a lot of queries, I think his best
bet is to log the queries with log_min_dur
On Wed, Sep 21, 2011 at 11:17 PM, Eric Vollnogel
wrote:
> The date_part('isoyear', some_column) function is not always returning the
> correct result. See below:
See http://www.postgresql.org/docs/8.4/static/functions-datetime.html :
"Each ISO year begins with the Monday of the week containing t
Hi Lampa,
On Thu, Sep 1, 2011 at 6:26 AM, Lampa wrote:
> With default value 100 have bad perfomance :-(
Don't set the default value higher: specify a higher value only where needed.
See ALTER TABLE ALTER [ COLUMN ] column SET STATISTICS integer (
http://www.postgresql.org/docs/9.0/interactive/s
Yann,
2011/6/16 Delorme, Yann :
> Thanks
>
> Do you think that it will be fix in future release 9.1 ?
Tom commited a fix in all the supported releases where the bug is
present including 9.0:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=669ac03af62328e4eb572dacb8ba319414ef1211
Henrik,
On Fri, Nov 27, 2009 at 4:15 AM, Henrik Pestano wrote:
> I have a problem with the parameter LC_MESSAGES, where its value is
> es_ES.UTF-8 (Spanish), the pgFouine 1.1 not work correctly, because csvlog
> generates a column "duración: 0138 ms sentencia: SELECT format_type (oid,
> 54) as ty
On Tue, Sep 1, 2009 at 8:47 AM, Bhushan Verma wrote:
> But my fedora 9 machine have as follows postgres version.
> rpm -qa|grep postgres
> postgresql-server-8.3.1-1.fc9.i386
> postgresql-devel-8.3.1-1.fc9.i386
> postgresql-python-8.3.1-1.fc9.i386
> postgresql-8.3.1-1.fc9.i386
> postgresql-libs-8.3.
On Wed, May 6, 2009 at 11:05 AM, Markus Meyer wrote:
> If i make an
>
> SELECT xmlconcat(('' || NULL || '')::xml);
>
> follows
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
It's fixed in
On Mon, Apr 6, 2009 at 1:37 PM, Andreas Pflug wrote:
> IMHO this should be mentioned in the docs explicitly (I find it quite
> surprising that data can be lost even if the system is shutdown
> correctly), or better when shutting down the postmaster should spit all
> log segments containing all cha
On Tue, Mar 24, 2009 at 10:11 PM, Tom Lane wrote:
> Sigh ... I could've sworn I tested that code path, but evidently not,
> 'cause it's broken as can be.
If it's a code path not exercised by any regression test, is it worth
it to add one or we don't have any chance to break this code again
later?
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut wrote:
> The question is how you want to implement this in a data type independent
> fashion. You can't assume that increasing the typmod is a noop for all data
> types.
Sure. See my previous answer on -hackers (I don't think this
discussion belo
On Tue, Mar 3, 2009 at 4:37 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I believe the command has been like that for a long time, and this is
>> the first time someone managed to shoot one's foot.
>
> True. Maybe it's not worth the trouble.
IMHO, the consequences are far from being negl
On Tue, Jan 27, 2009 at 4:20 PM, Hauke Runge wrote:
> this was working very well. Changing to postgreSql 8.3 we got the following
> error:
> ERROR: operator does not exist: bigint ~~ bigint
>
> we changed the jdbc driver to the latest jdbc3 driver - but the error was
> the same.
>
>
> I think, thi
On Tue, Dec 9, 2008 at 11:11 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alexander Gallardo Torres" <[EMAIL PROTECTED]> writes:
>> I need download PostgreSQL 8.0.2 but this link has problem.
>
> Surely you want something newer than that --- 8.0.2 was obsoleted over
> three years ago. Try 8.0.15, wh
Hi Taras,
On Sat, Sep 20, 2008 at 10:26 AM, Taras Kopets <[EMAIL PROTECTED]> wrote:
> INSERT INTO fkb VALUES(6,4);-- stange error (see below)
> -- ERROR: relation "public.fktest_a" does not exist
> -- SQL state: 42P01
> -- Context: SQL statement "SELECT 1 FROM ONLY "public"."fktest_a" x WHERE
On Fri, Apr 11, 2008 at 5:31 PM, jalvarez
<[EMAIL PROTECTED]> wrote:
> i have that error where execute page
>
> server closed the connection unexpectedly This probably means the server
> terminated abnormally before or while processing the request postgres linux
Please dig a bit further before co
On Sat, Apr 12, 2008 at 4:53 AM, philwalk <[EMAIL PROTECTED]> wrote:
> CREATE TABLE
> psql:pg83bug.sql:16: ERROR: operator does not exist: timestamp without
> time zone ~~ unknown
> LINE 3: where date like '2007-01-19%';
>^
> HINT: No operator matches the given na
On Jan 23, 2008 4:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> What do you find odd about it? Whatever scale you choose to think these
> values are in, they all have to be on the same scale.
So they are not defined in relation compared to the sequential page
fetch cost as they were before? I mean
Hi Harald,
On Jan 23, 2008 1:36 PM, Harald Armin Massa <[EMAIL PROTECTED]> wrote:
> that should be regarded more to be a feature then a bug:
That's not my point :). It's just that the comments are misleading or
at least a bit absurd.
--
Guillaume
---(end of broadcast)--
Hi -bugs,
I just noticed something odd in the Planner constants part of the 8.2
and 8.3 postgresql.conf:
# - Planner Cost Constants -
#seq_page_cost = 1.0# measured on an arbitrary scale
#random_page_cost = 4 # same scale as above
#cpu_tuple_cost = 0.01
On Jan 15, 2008 5:52 PM, Ruben Camargo Gomez
<[EMAIL PROTECTED]> wrote:
> I had this error from my log file:
> ERRORROR: missing FROM-clause entry for table "tbldishot"
> CONTEXT: SQL statement "update tblalohot set alohot_con =
> coalesce(alohot_con,0)+8 where tbldishot.dishot_cod = tblalohot.d
On 4/11/07, John R Pierce <[EMAIL PROTECTED]> wrote:
I think what -I- ran into was that there was no compat-3 in the public
repositories, just compat-4... this was about a month ago. devrim
indicated he was going to upload compat-3, and showed me where to find
it, but I'd already installed compa
On 4/11/07, Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-02 at 09:17 -0800, John R Pierce wrote:
> looks like the RPMs for libpq.so.4 and libpq.so.3 can't coexist.
Ok, I got lots of complaints about this. I will work on this today and
announce new sets.
It's not a real problem IMHO
Hi all,
I recently came accross a problem with the use of IN clause in a
partial index with a varchar(3) field. Int, char and text seems to be
OK (test case is provided below).
Version is 8.2.3 running on a Fedora Core 3 (RPM rebuilt from the PGDG ones).
test=# SELECT version();
John,
On 3/2/07, John R Pierce <[EMAIL PROTECTED]> wrote:
compat-postgresql-libs-4-2PGDG.rhel4.rpm supplies libpq.so.4 and .4.1,
but it does NOT include .so.3. I think it should provide a .so.3 which
can coexist with the rest of the 8.2.3 stack (or, there should be a
compat-postgresql-libs-3 ?
Roman,
On 2/7/07, Roman Grigorovich <[EMAIL PROTECTED]> wrote:
ERROR: attribute 1 has wrong type
DETAIL: Table has type character varying, but query expects character
varying.
What is it? On version 8.1.2 - ALL OK!
This is a known problem of 8.1.7. That's why 8.1.8 has been released.
So yo
> From: Martin Marques
> I encountered a rare BUG in the way PG is logging. Let me first enlight with
> some configuration I have and PG version:
Perhaps I'm missing something but I think it's not a bug but a
configuration problem.
> log_min_error_statement| panic
If you set this one to e
The following bug has been logged online:
Bug reference: 1991
Logged by: Guillaume Smet
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1b3
Operating system: RHEL 3
Description:UPPER problem on special characters
Details:
Hi,
I'm currently testing 8.1
28 matches
Mail list logo
