2009/10/7 Itagaki Takahiro :
>
> Magnus Hagander wrote:
>> Per your own comments earlier, and in the code, what will happen if
>> pg_do_encoding_conversion() calls ereport()? Didn't you say we need a
>> non-throwing version of it?
>
> We are hard to use encoding conversion functions in logging rou
Marko Tiikkaja writes:
> Tom Lane wrote:
>> Could you pull out a patch that includes those changes, please?
> Sorry for the delay, my master was a bit behind :-( . I moved the
> trigger code to nodeDml.c with minor changes and removed unused
> resultRelation stuff from DML nodes completely. Thi
2009/10/10 Alvaro Herrera
> > > Our TODO has:
> > >
> > >Add idle_in_transaction_timeout GUC so locks are not held for
> > >long periods of time
> >
> > Awesome! Thanks for the info Bruce.
>
> This is quite a different thing though. You were talking about idle
> connections; the
On Fri, Oct 09, 2009 at 08:34:55PM +0200, Markus Schiltknecht wrote:
> Hi,
>
> David Fetter wrote:
>> 1. Test situations which require more than one connection, possibly
>> to different clusters, for example in the cases of Hot Standby and
>> Streaming Replication. This further divides into event
I am looking for funding for two Postgres community projects:
1) enhancements to full text search and GiST
2) proofreading of our documentation
I have people ready to work on these, and the items would be completed
for Postgres 8.5. If you or your company are interested in fund
Thom Brown escribió:
> 2009/10/9 Bruce Momjian
>
> > Thom Brown wrote:
> > > I saw a recent blog entry where someone came up with a solution
> > > for expiring idle connections (
> > >
> > http://dividebyzeroexception.blogspot.com/2009/10/implementing-waittimeout-in-postgresql.html
> > )
> > > an
2009/10/9 Bruce Momjian
> Thom Brown wrote:
> > I saw a recent blog entry where someone came up with a solution for
> expiring
> > idle connections (
> >
> http://dividebyzeroexception.blogspot.com/2009/10/implementing-waittimeout-in-postgresql.html
> )
> > and I was surprised there wasn't a conf
Thom Brown wrote:
> I saw a recent blog entry where someone came up with a solution for expiring
> idle connections (
> http://dividebyzeroexception.blogspot.com/2009/10/implementing-waittimeout-in-postgresql.html)
> and I was surprised there wasn't a config option for this already. Is this
> some
Dan Colish wrote:
> I'm going through a few files and trying to clean them up for style mostly
> and a
> bit of refactoring. I am curious about the preferred style for a one line
> comment. I see them in both of these forms and I would like to keep it
> consistent.
>
> /* a one line comment */
>
Peter Eisentraut wrote:
> I think the setting ought be called linestyle unicode (instead of
> utf8), since the same setting would presumably work in case we ever
> implement UTF-16 support on the client side.
Yeah, anytime one gets sloppy with the distinction between a character
set and a char
On Tue, 2009-10-06 at 19:35 +0100, Roger Leigh wrote:
> This patch included a bit of code not intended for inclusion
> (setting of client encoding based on locale), which the attached
> (and hopefully final!) revision of the patch excludes.
Well, the documentation still claims that this is depende
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> Itagaki Takahiro wrote:
>
> > Ok, the attached patch implements standard-compliant version of
> > column trigger.
>
> Here is an updated version of column-level trigger patch.
> I forgot to adjust pg_get_triggerdef() in the previous ve
Added to TODO:
Allow INSERT/UPDATE/DELETE ... RETURNING in common table expressions
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg00472.php
---
Marko Tiikkaja wrote:
> I've made progress in imp
Markus Wanner wrote:
Hi,
Dimitri Fontaine wrote:
I even started a DBT2 implementation as tsung modules, back when
returning from pgcon 2006:
http://tapoueh.org/misc.html#sec7
darcs get http://pgsql.tapoueh.org/dbt2-tsung/
Now *that* is very cool! I definitely need to have a look at it.
On Fri, 9 Oct 2009, Bruce Momjian wrote:
Oleg Bartunov wrote:
=# set enable_seqscan=off;
=# set plantuner.forbid_index='id_idx2';
The genius of this module is the line above -- a more fine-grained way
to control the optimizer, with specific index disabling.
.
Are you planni
Hi,
Dimitri Fontaine wrote:
I even started a DBT2 implementation as tsung modules, back when
returning from pgcon 2006:
http://tapoueh.org/misc.html#sec7
darcs get http://pgsql.tapoueh.org/dbt2-tsung/
Now *that* is very cool! I definitely need to have a look at it.
Have you tried Sun Faban
Hi,
David Fetter wrote:
1. Test situations which require more than one connection, possibly
to different clusters, for example in the cases of Hot Standby and
Streaming Replication. This further divides into event-based and
time-based tests. It's this situation I had in mind when I posted,
an
Andrew Dunstan wrote:
>
>
> Robert Haas wrote:
> > But at least for simple features I think that there would be a value
> > in separating the patch author's work from the committer's adjustments.
> >
> >
>
> That is just going to make life harder for committers.
>
> There are plenty of things
On Fri, 2009-10-09 at 14:05 -0400, Andrew Dunstan wrote:
>
> Robert Haas wrote:
> > But at least for simple features I think that there would be a value
> > in separating the patch author's work from the committer's adjustments.
> >
> >
>
> That is just going to make life harder for committers.
Robert Haas wrote:
But at least for simple features I think that there would be a value
in separating the patch author's work from the committer's adjustments.
That is just going to make life harder for committers.
There are plenty of things with my name on them that are not exactly
what
On Oct 9, 2009, at 1:21 PM, Bruce Momjian wrote:
Simon Riggs wrote:
You have posted patches that I have said I don't agree with. My
name is
going to be on this when it goes in, so I don't think it makes any
sense
to force that commit to include changes I don't agree with. I cannot
prevent
Simon Riggs wrote:
>> Tom Lane wrote:
>>> [ scratches head ... ] Why is hot standby messing with this sort of
>>> thing at all? It sounds like a performance optimization that should
>>> be considered separately, and *later*.
>> Yeah, I too considered just ripping it out. Simon is worried that
>>
While playing with conflict resolution, I bumped into this:
postgres=# begin ISOLATION LEVEL SERIALIZABLE;
BEGIN
postgres=# SELECT * FROM foo;
id | data
+--
12 |
(1 row)
postgres=# SELECT * FROM foo;
id | data
+--
12 |
(1 row)
postgres=# SELECT * FROM foo;
id | data
+---
Simon Riggs wrote:
> You have posted patches that I have said I don't agree with. My name is
> going to be on this when it goes in, so I don't think it makes any sense
> to force that commit to include changes I don't agree with. I cannot
> prevent you making changes afterwards, nor would I wish to
Oleg Bartunov wrote:
> =# set enable_seqscan=off;
> =# set plantuner.forbid_index='id_idx2';
The genius of this module is the line above -- a more fine-grained way
to control the optimizer, with specific index disabling.
> =# explain select id from test where id=1;
>
I saw a recent blog entry where someone came up with a solution for expiring
idle connections (
http://dividebyzeroexception.blogspot.com/2009/10/implementing-waittimeout-in-postgresql.html)
and I was surprised there wasn't a config option for this already. Is this
something that can be considered
On Fri, 9 Oct 2009, Tom Lane wrote:
what do we do with rows that fail encoding conversion? For logging to a
file we could/should just decree that we write out the original,
allegedly-in-the-client-encoding data. I'm not sure what we do about
logging to a table though. The idea of storing by
Hannu Krosing writes:
> On Thu, 2009-10-08 at 11:32 -0400, Robert Haas wrote:
>> Another possible approach, which isn't perfect either, is the idea of
>> allowing COPY to generate a single column of output of type text[].
>> That greatly reduces the number of possible error cases,
> maybe make i
Simon Riggs writes:
> Another thing that has occurred to me is that RI checks are currently
> resolved at end of statement and could end up rejecting any/all rows
> loaded. If we break down the load into subtransaction pieces we would
> really want the RI checks on the rows to be performed during
Simon Riggs writes:
> On Thu, 2009-10-08 at 12:21 -0400, Tom Lane wrote:
>> So really we have to find some way to only expend one XID per failure,
>> not one per row.
> I discovered a few days back that ~550 subtransactions is sufficient to
> blow max_stack_depth. 1 subtransaction per error doesn
Jeff Davis writes:
> On Fri, 2009-10-09 at 02:23 +0300, Peter Eisentraut wrote:
>> I think I'd want "writable subqueries" instead of only "writable CTEs".
> I think the original motivation was that it's more clear that a CTE is
> separated and can only be executed once (if it has side effects).
>
Following the discussions in
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
and
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
here are patches for
a) a hook in backend/commands/user.c that allows one to add
password checking functions
b) a contrib module
This whole discussion looked helpful to save, I put a summary of the issue
and the suggested solution at
https://wiki.postgresql.org/wiki/Working_with_Eclipse#Debugging_with_child_processes
so nobody has to reinvent this.
--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore,
On Thu, 2009-10-08 at 11:32 -0400, Robert Haas wrote:
> Another possible approach, which isn't perfect either, is the idea of
> allowing COPY to generate a single column of output of type text[].
> That greatly reduces the number of possible error cases,
maybe make it bytea[] to further reduce e
34 matches
Mail list logo
