Peter Eisentraut writes:
> That seems pretty useful, and it's more or less a one-line change, as in
> the attached patch.
That seems pretty nearly entirely bogus. What is the argument for
supposing that the word right after SELECT is a function name? I would
think it would be a column name (fro
Attached is a proposed patch to deal with the issue described here:
http://archives.postgresql.org/pgsql-bugs/2012-02/msg0.php
Even though we'd previously realized that comparing the text of
inherited CHECK expressions is an entirely unsafe way to detect
expression equivalence (cf comments for
On 08-02-2012 09:35, Fujii Masao wrote:
Fujii, new patch attached. Thanks for your tests.
> But another problem happened. When I changed pg_proc.h so that the unused
> OID was assigned to pg_xlog_location_diff(), and executed the above again,
> I encountered the segmentation fault:
>
I reproduce
Peter Eisentraut writes:
> Make tab-completion complete also function names – like: SELECT
> pg_get to see all functions that start with pg_get.
>
> Make tab-completion work for columns in SELECT. I know that when writing
> SELECT clause, psql doesn’t know which table it will deal with, but it
> c
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way to
get the row is going to be to fetch block 100 f
Hi!
I've always been a little wary of using the TRUNCATE command due to
the warning in the documentation about it not being "MVCC-safe":
queries may silently give wrong results and it's hard to tell when
they are affected.
That got me thinking, why can't we handle this like a standby server
does
In his blog entry http://www.depesz.com/2011/07/08/wish-list-for-psql/
depesz described a simple way to do tab completion for SELECT in psql:
"""
Make tab-completion complete also function names – like: SELECT
pg_get to see all functions that start with pg_get.
Make tab-completion work for column
Tom Lane wrote:
Jay Levitt writes:
[Posted at Andres's request]
TL;DR: Inserting and indexing cubes is slow and/or broken in various ways in
various builds.
1. In 9.1.2, inserting 10x rows takes 19x the time.
- 9.1-HEAD and 9.2 "fix" this; it now slows down linearly
- but: 10s> 8s
On Thu, Feb 9, 2012 at 1:33 PM, Jesper Krogh wrote:
> On 2012-02-09 18:02, Robert Haas wrote:
>>
>> I don't have any appetite for trying to do anything more with
>> index-only scans for 9.2, though maybe someone else will think
>> otherwise. But I would like very much to get KaiGai's leakproof st
On 02/09/2012 02:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, the one place that needs to be fixed to avoid the crash caused by
the json regression tests with the original patch is in
src/backend/parser/parse_expr.c:transformRowExpr().
Other candidates I have found that don't set co
Andrew Dunstan writes:
> OK, the one place that needs to be fixed to avoid the crash caused by
> the json regression tests with the original patch is in
> src/backend/parser/parse_expr.c:transformRowExpr().
> Other candidates I have found that don't set colnames and should
> probably use d
Excerpts from Andrew Dunstan's message of jue feb 09 16:38:27 -0300 2012:
> OK, the one place that needs to be fixed to avoid the crash caused by
> the json regression tests with the original patch is in
>
> src/backend/parser/parse_expr.c:transformRowExpr().
>
> Other candidates I have fo
On 02/07/2012 03:03 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 02/07/2012 12:47 PM, Tom Lane wrote:
In general I think we'd have to require that colnames be supplied in all
RowExprs if we go this way. Anyplace that's trying to slide by without
will have to be fixed. I don't recall how m
"Kevin Grittner" wrote:
> In continued digging through logs I found something to indicate
> the transaction on which COMMIT failed for 2528 of the failures.
> In all cases the transaction made a change which would have fired
> a NOTIFY at commit (in a deferred trigger).
Arg. Sorry, I got con
Tom Lane wrote:
> "Kevin Grittner" writes:
>> The application LISTENs on channel tcn and a trigger function is
>> attached to most permanent tables to NOTIFY for DML on that
>> channel.
>> ...
>> The report to us was that testers were unable to start the
>> application. I believe that the above
On 2012-02-09 18:02, Robert Haas wrote:
I don't have any appetite for trying to do anything more with
index-only scans for 9.2, though maybe someone else will think
otherwise. But I would like very much to get KaiGai's leakproof stuff
committed, and so it seems like a good idea to reconcile the
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>> If people are sufficiently worried about this, a better answer would be
>> to teach the makefiles to run check_keywords.pl during every build.
> FWIW that script is throwing a warning here:
> Use of as
Excerpts from Tom Lane's message of jue feb 09 12:17:59 -0300 2012:
>
> Alvaro Herrera writes:
> > Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300
> > 2012:
> >> src/tools/check_keywords.pl is your friend.
>
> > I wondered a couple of weeks ago if we could, instead, gene
"Kevin Grittner" writes:
> The application LISTENs on channel tcn and a trigger function is
> attached to most permanent tables to NOTIFY for DML on that channel.
> ...
> The report to us was that testers were unable to start the
> application. I believe that the above error on COMMIT kept the
>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> [2012-02-05 01:30:36.952 CST] 16383
>> ERROR: could not access status of transaction 0
>> [2012-02-05 01:30:36.952 CST] 16383
>> DETAIL: Could not read from file "pg_notify/03A5" at offset
>> 253952: Success.
> The substantive issue is that yo
"Kevin Grittner" writes:
> We got three errors in the log with exactly this DETAIL (file,
> offset and message):
> [2012-02-05 01:27:36.878 CST] 14892 ERROR:
> could not access status of transaction 0
> [2012-02-05 01:27:36.878 CST] 14892 DETAIL:
> Could not write to file "pg_notify/03A5" at
On 9 February 2012 17:16, Bruce Momjian wrote:
>> Yes, I am. The main reason that the loops exist in those functions
>> (which is the only way that they substantially differ) is because they
>> each have to get the other keys through various ways that characterise
>> the tuple class that they enca
On Thu, Feb 9, 2012 at 7:18 AM, Noah Misch wrote:
> The code has a thinko; a given interval typmod ultimately implies a single
> point from which we truncate rightward. The precision only matters if the
> range covers SECOND. Thanks; the attached patch improves this.
Thanks, committed.
--
Rob
On Thu, Feb 09, 2012 at 03:36:23PM +, Peter Geoghegan wrote:
> On 9 February 2012 14:51, Robert Haas wrote:
> > I'm not sure I entirely follow all this, but I'll look at the code
> > once you have it. Are you saying that all the comparetup_yadda
> > functions are redundant to each other in th
When Heikki worked up his original index-only scan patches (which
didn't end up looking much like what eventually got committed), he had
the notion of an index-only qual. That is, given a query like this:
select sum(1) from foo where substring(a,1,3) = 'abc';
We could evaluate the substring qual
On a development system which wasn't being monitored very closely
I think we've uncovered a bug in the listen/notify behavior. The
system was struggling with lack of disk space for about a week
before this surfaced, so it's probably not the most critical sort
of bug we could have, but it probably
On 9 February 2012 14:51, Robert Haas wrote:
> I'm not sure I entirely follow all this, but I'll look at the code
> once you have it. Are you saying that all the comparetup_yadda
> functions are redundant to each other in the single-key case?
Yes, I am. The main reason that the loops exist in th
Alvaro Herrera writes:
> Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300 2012:
>> src/tools/check_keywords.pl is your friend.
> I wondered a couple of weeks ago if we could, instead, generate the
> lists in gram.y from kwlist.h.
We've looked into that in the past. bison
On Wed, Feb 8, 2012 at 2:05 PM, Noah Misch wrote:
> On Wed, Feb 08, 2012 at 11:40:34AM +, Simon Riggs wrote:
>> On Wed, Feb 8, 2012 at 3:24 AM, Noah Misch wrote:
>> > On Tue, Feb 07, 2012 at 08:58:59PM +, Simon Riggs wrote:
>> >> On Thu, Jan 26, 2012 at 8:20 PM, Noah Misch wrote:
>> >> >
On Thu, Feb 09, 2012 at 07:24:49AM -0500, Noah Misch wrote:
> This patch has gotten more than its fair share of attention for bloat, and I
> think that's mostly because there's a dial-a-bloat-level knob sticking out and
> begging to be frobbed.
I already emailed Peter privately stating that he sho
On Thu, Feb 9, 2012 at 9:37 AM, Peter Geoghegan wrote:
> On 9 February 2012 13:50, Robert Haas wrote:
>> I'm also more than slightly concerned that we are losing sight of the
>> forest for the trees. I have heard reports that sorting large amounts
>> of data is many TIMES slower for us than for
On Wed, Feb 08, 2012 at 10:41:43PM -0500, Greg Smith wrote:
> Just trying to set the expectations bar realistically here. I don't
> consider the easier problem of checkpoint smoothing a solved one,
> either. Saying autovacuum needs to reach even that level of
> automation to be a useful improveme
On 9 February 2012 13:50, Robert Haas wrote:
> I'm also more than slightly concerned that we are losing sight of the
> forest for the trees. I have heard reports that sorting large amounts
> of data is many TIMES slower for us than for a certain other database
> product. I frankly wonder if this
On Thu, Feb 9, 2012 at 7:24 AM, Noah Misch wrote:
> On Tue, Feb 07, 2012 at 09:38:39PM -0500, Robert Haas wrote:
>> Second, there's a concern about binary bloat: duplicating lots of code
>> with different comparators inlined generates, well, a lot of machine
>> code. Of course, an 0.8% increase i
Excerpts from Heikki Linnakangas's message of jue feb 09 06:42:12 -0300 2012:
> Add new keywords SNAPSHOT and TYPES to the keyword list in gram.y
>
> These were added to kwlist.h as unreserved keywords in separate patches,
> but authors forgot to add them to the corresponding list in gram.y.
> Be
On Wed, Feb 8, 2012 at 19:39, Fujii Masao wrote:
> On Tue, Oct 25, 2011 at 7:37 PM, Magnus Hagander wrote:
>> On Mon, Oct 24, 2011 at 14:40, Magnus Hagander wrote:
>>> On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
>>> wrote:
How does this interact with synchronous replication? If a bas
On Tue, Feb 07, 2012 at 09:38:39PM -0500, Robert Haas wrote:
> Second, there's a concern about binary bloat: duplicating lots of code
> with different comparators inlined generates, well, a lot of machine
> code. Of course, an 0.8% increase in the size of the resulting binary
> is very unlikely to
On Wed, Feb 08, 2012 at 09:37:01AM -0500, Robert Haas wrote:
> On Tue, Feb 7, 2012 at 12:43 PM, Robert Haas wrote:
> > I've committed the numeric and varbit patches and will look at the
> > temporal one next.
>
> Committed, after changing the OIDs so they don't conflict.
>
> Here's one more case
On Thu, Feb 9, 2012 at 7:25 PM, Fujii Masao wrote:
> On Thu, Feb 9, 2012 at 3:32 AM, Jeff Janes wrote:
>> On Wed, Feb 1, 2012 at 11:46 PM, Heikki Linnakangas
>> wrote:
>>> On 31.01.2012 17:35, Fujii Masao wrote:
On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
wrote:
>
>
On Thu, Feb 9, 2012 at 3:32 AM, Jeff Janes wrote:
> On Wed, Feb 1, 2012 at 11:46 PM, Heikki Linnakangas
> wrote:
>> On 31.01.2012 17:35, Fujii Masao wrote:
>>>
>>> On Fri, Jan 20, 2012 at 11:11 PM, Heikki Linnakangas
>>> wrote:
On 20.01.2012 15:32, Robert Haas wrote:
>
>
>
Hi,
we have a database that is storing strings in various encodings (and
non-encodings, namely the arbitrary byte soup that you might see in
email headers from the internet). For this reason, the database uses
sql_ascii encoding. The columns are text, as most characters are
ascii, so bytea didn't
41 matches
Mail list logo
