On Fri, Feb 25, 2011 at 8:40 AM, Greg Smith wrote:
> I didn't get the Streaming Rep + Hot Standby features I wanted in 9.0 either.
> But committing what was reasonable to include in that version let me march
> forward with very useful new code, doing another year of development on my
> own pro
On Sat, Feb 26, 2011 at 7:40 PM, fork wrote:
>> Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
>> in contrib/fuzzystrmatch still is.
>
> I am only looking at 9.0.3 for levenshtein, so I don't have any thoughts yet
> on
> multi-byteness so far. I will have to figure out t
On Fri, Feb 18, 2011 at 12:10 PM, Robert Haas wrote:
> IMHO, that's so broken as to be useless.
>
> I would really like to have a solution to this problem, though.
> Relying on TCP keepalives is weak.
Agreed.
I updated the replication timeout patch which I submitted before.
http://archives.postg
On 2/26/11 3:40 PM, Anton wrote:
> I've been playing with 'native XML' for a while and now wondering if
> further development of such a feature makes sense for Postgres.
> (By not having brought this up earlier I'm taking the chance that the
> effort will be wasted, but that's not something you sho
Robert Haas gmail.com> writes:
>
> On Sat, Feb 26, 2011 at 4:19 PM, Josh Berkus agliodbs.com> wrote:
> > Anyway, if it's ASCII-only, that's a guaranteed way to make sure it
> > isn't taken seriously.
>
> Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
> in contrib/fuzzys
Hi all,
I noticed an off by one error in psql's verbose-mode display for \dg
and \du. In verbose mode, \dg and \du will not display the
"Replication" attribute:
test=# \dg rep
List of roles
Role name | Attributes | Member of
---+-+---
rep | Replica
Hello,
I've been playing with 'native XML' for a while and now wondering if
further development of such a feature makes sense for Postgres.
(By not having brought this up earlier I'm taking the chance that the
effort will be wasted, but that's not something you should worry about.)
The code is ava
On Sat, Feb 26, 2011 at 12:52:40AM -0500, Robert Haas wrote:
> On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> Yay! I'm excited about this, particularly the possible "pipelining"
> >> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
> >> have i
On 2011-02-26 7:18 PM, Tom Lane wrote:
IMO the major disadvantage of a refactoring like this is the possibility
of sins of omission in third-party code, in particular somebody not
noticing the added requirement to call ExecutorFinish. We could help
them out by adding an Assert in ExecutorEnd to
On Sat, Feb 26, 2011 at 4:19 PM, Josh Berkus wrote:
> Anyway, if it's ASCII-only, that's a guaranteed way to make sure it
> isn't taken seriously.
Pre-9.1 levenshtein is ASCII-only, and I think some of the other stuff
in contrib/fuzzystrmatch still is. We had to work pretty hard to
avoid a massi
"Fork",
> 1. Does anybody else care? I would love to see this in contrib, but if the
> chances are slim, then I would like to know that too.
That really depends on how well it works, and how much code it is. It's
way too early for anyone to have a viewpoint on this. For example, a
few years ag
On 07.12.2010 05:51, Fujii Masao wrote:
On Tue, Dec 7, 2010 at 12:22 PM, Robert Haas wrote:
Fair enough. How about increasing the default to 10 seconds?
Since bgwriter has already using 10s as a nap time if there is no
configured activity, I think that 10s is non-nonsense default value.
What
Greg Stark wrote:
> Consider the oft-quoted example of a -- or
> for Americans.
I'm not sure everyone realizes just how complicated this particular
issue is. If we can do a good job with U.S. city, state, zip code we
will have something which will handle a lot of cases.
Consider:
(1) M
Hi hackers,
I am interested in extending Postgres with a "generalized edit function" like
SAS's "compged"[1], which is basically levenshtein distance with transposes (ab
<-> ba) and LOTS of different weights for certain ops (like insert a blank
versus delete from the end versus insert a regular ch
> Grzegorz Jaskiewicz wrote:
> I guess that the systems could behave much better, but no one is
> going to tweak settings for 50 different installations over 50
> different type of data and 50 different sets of hardware.
> If there was even a tiny amount of automation provided in the
> postgresq
> That would be nice; I'm basically abusing syncrep to this purpose. At
> the same time, someone may need to be notified of such a switchover
> occurring, and in event of failure, it'd be nice to bounce back to the
> primary. Tangentially relevent, Virtual IP is not always an option,
> such as on
On 26 Feb 2011, at 14:45, Robert Haas wrote:
> On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
>>
>
> I don't think *anyone* is avoiding that approach. There is almost
> universal consensus here that auto-tuning is better than manual
> tuning, even to the extent of being unwilling to add
On Sat, Feb 26, 2011 at 20:48, Yeb Havinga wrote:
> On 2011-02-26 18:19, Magnus Hagander wrote:
>>
>> Attached is an updated version of the patch that includes these
>> changes, as well as Windows support and an initial cut at a ref page
>> for pg_receivexlog (needs some more detail still).
>
> I'
On 2011-02-26 18:19, Magnus Hagander wrote:
Attached is an updated version of the patch that includes these
changes, as well as Windows support and an initial cut at a ref page
for pg_receivexlog (needs some more detail still).
I'm testing a bit more (with the previous version, sorry) and got the
On Sat, Feb 26, 2011 at 06:44:52PM +, Greg Stark wrote:
> 2011/2/26 PostgreSQL - Hans-Jürgen Schönig :
> > what we are trying to do is to explicitly store column correlations. so, a
> > histogram for (a, b) correlation and so on.
>
> The problem is that we haven't figured out how to usefully
2011/2/26 PostgreSQL - Hans-Jürgen Schönig :
> what we are trying to do is to explicitly store column correlations. so, a
> histogram for (a, b) correlation and so on.
>
The problem is that we haven't figured out how to usefully store a
histogram for . Consider the oft-quoted example of a
-- or
Hi,
I am writing some spatio-temporal function in postgis.
Like, ST_Enters( obj_geom, boundary_geom, time t1,time t2)
For example- Does vehicle enters in ABC between time t1 to t2?
Let us suppose, i take only one object geometry at a time and do compare
then i could not produce the output because
> > > On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański
> > > wrote:
> > > > On 15/02/11 20:39, Peter Eisentraut wrote:
> > > > > On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
> > > > > > [a bug that we don't know how to fix]
> >
> > > From this discussion I gather that we have a problem her
>>>
>>
>> Still, having more data a user can probe would be nice.
>>
>> I wonder why everyone avoids Microsoft's approach to the subject.
>> Apparently, they go in the 'auto-tune as much as possible' direction.
>> And tests we did a while ago, involving asking team from Microsoft and a
>> team
bruce wrote:
> Josh Berkus wrote:
> >
> > > Right now pg_options_to_table() is not documented. Should it be?
> >
> > Yes, I think so.
>
> Done, with the attached, applied patch.
Oh, here is an example usage:
test=> select pg_options_to_table(reloptions) from pg_class;
p
Heikki Linnakangas writes:
> On 26.02.2011 07:55, Tom Lane wrote:
>> So we really need some refactoring here. I dislike adding another
>> fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
>> but there may not be a better way.
> Could you keep the sequence unchanged for non-
On Sat, Feb 26, 2011 at 16:51, Magnus Hagander wrote:
> in spawn_restore:
>
>
> child = (HANDLE) _beginthreadex(NULL, 0, (void *) parallel_restore,
> args,
> 0, NULL);
> if (child == 0)
>
>
> But from my reading
On Sat, Feb 26, 2011 at 4:10 PM, Tom Lane wrote:
> Right at the moment we dodge that issue by disallowing wCTEs in cursors.
> If we did allow them, then I would say that the wCTEs have to be run to
> completion when the cursor is closed.
>
Does that really dodge anything? Isn't it just the same a
Greg Stark writes:
> On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane wrote:
>> So we really need some refactoring here. I dislike adding another
>> fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
>> but there may not be a better way. The only way I see to fix this
>> without c
in spawn_restore:
child = (HANDLE) _beginthreadex(NULL, 0, (void *) parallel_restore,
args,
0, NULL);
if (child == 0)
But from my reading of the docs, _beginthreadex() returns -1 on error, not 0.
Bug, or a
On Sun, Feb 20, 2011 at 21:37, Dimitri Fontaine wrote:
> Hi,
>
> Magnus Hagander writes:
>> Better late than never (or?), here's the final cleanup of
>> pg_streamrecv for moving into the main distribution, per discussion
>> back in late dec or early jan. It also includes the "stream logs in
>> pa
On lör, 2011-02-26 at 09:34 +0100, Jan Urbański wrote:
> - Original message -
> > On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański
> > wrote:
> > > On 24/02/11 14:10, Peter Eisentraut wrote:
> > > Hm, perhaps, I put it in the details, because it sounded like the place
> > > to put information
On lör, 2011-02-26 at 09:49 -0500, Robert Haas wrote:
> OK. Peter, are you planning to commit this?
Yes.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 16, 2011 at 7:06 AM, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 12:59 AM, Fujii Masao wrote:
>> On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote:
>>> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
You suggest that the shared variable Stream tracks the WAL write locati
Committed the last version.
I updated the documentation which previously claimed that what you
implemented wasn't supported.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/2/26 Jan Urbański :
> The docs are included in the latest patch, and it turned out that disabling
> implicit subxacts inside explicit subxacts is not a good idea, so it's been
> fixed in the last patch. There are no unresolved issues AFAICT.
OK. Peter, are you planning to commit this?
--
2011/2/26 Jan Urbański :
> - Original message -
>> On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański
>> wrote:
>> > On 15/02/11 20:39, Peter Eisentraut wrote:
>> > > On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
>> > > > [a bug that we don't know how to fix]
>
>> From this discussion
On Sat, Feb 26, 2011 at 1:57 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > Actually, we *do* have some idea which tables are hot. ?Or at least, we
>> > could. ? Currently, pg_stats for tables are "timeless"; they just
>> > accumulate from the last reset, which has always been a problem in
>>
On Sat, Feb 26, 2011 at 4:33 AM, Grzegorz Jaskiewicz
wrote:
>
> On 25 Feb 2011, at 13:18, Robert Haas wrote:
>
>> People coming from Oracle are not favorably
>> impressed either by the amount of monitoring data PostgreSQL can
>> gather or by the number of knobs that are available to fix problems
On 26 February 2011 05:55, Tom Lane wrote:
> Further experimentation has reminded me of why I didn't want to put such
> processing in ExecutorEnd :-(. There are some nasty interactions with
> EXPLAIN:
>
> 1. EXPLAIN ANALYZE fails to include the execution cycles associated with
> running the Modif
On Fri, Feb 25, 2011 at 14:26, Alvaro Herrera wrote:
> Excerpts from Rod Taylor's message of vie feb 25 14:03:58 -0300 2011:
>
> > How practical would it be for analyze to keep a record of response times
> for
> > given sections of a table as it randomly accesses them and generate some
> > kind of
On Sat, Feb 26, 2011 at 5:55 AM, Tom Lane wrote:
> So we really need some refactoring here. I dislike adding another
> fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
> but there may not be a better way. The only way I see to fix this
> without changing that API is to hav
On Sat, Feb 26, 2011 at 10:57, Brendan Jurd wrote:
> On 26 February 2011 18:06, Bruce Momjian wrote:
>>
>> Any progress on this?
>>
>
> I ended up doing most of the work, but never got around to finishing
> it off. Thanks for the reminder, though. I'll get that one ready and
> drop it onto the
On 2011-02-26 4:41 AM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in WITH?
That test was in your patch, no? I moved the code to another place
but it's still enforcing the same th
On 25 Feb 2011, at 13:18, Robert Haas wrote:
> People coming from Oracle are not favorably
> impressed either by the amount of monitoring data PostgreSQL can
> gather or by the number of knobs that are available to fix problems
> when they occur. We don't need to have as many knobs as Oracle an
On 26 February 2011 18:06, Bruce Momjian wrote:
>
> Any progress on this?
>
I ended up doing most of the work, but never got around to finishing
it off. Thanks for the reminder, though. I'll get that one ready and
drop it onto the next CF.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (p
- Original message -
> On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański
> wrote:
> > On 15/02/11 20:39, Peter Eisentraut wrote:
> > > On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
> > > > [a bug that we don't know how to fix]
> From this discussion I gather that we have a problem he
- Original message -
> On Wed, Feb 9, 2011 at 5:22 PM, Peter Eisentraut wrote:
> > On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
> > > The documentation could probably still use more word-smithing but
> > > that can happen later. I'm marking this as ready for a committer.
> >
>
- Original message -
> On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański
> wrote:
> > On 24/02/11 14:10, Peter Eisentraut wrote:
> > Hm, perhaps, I put it in the details, because it sounded like the place
> > to put information that is not that important, but still helpful. It's
> > kind of na
On 26.02.2011 07:55, Tom Lane wrote:
So we really need some refactoring here. I dislike adding another
fundamental step to the ExecutorStart/ExecutorRun/ExecutorEnd sequence,
but there may not be a better way.
Could you keep the sequence unchanged for non-EXPLAIN callers with some
refactoring
50 matches
Mail list logo
