Alvaro Herrera writes:
> I disagree with this change. Debug builds are very useful to have in
> production, and you don't want to be running -O0 there. I have found
> that you can use a src/Makefile.custom like this for those times when you
> want to debug stuff in a particular set of files:
>
On tor, 2011-06-16 at 00:50 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On tis, 2011-06-14 at 15:38 +0200, Florian Pflug wrote:
> >> BTW, there's actually precedent for a commutator of "~", namely
> >> "@". Some of the geometric types (polygon, box, circle, point,
> >> path) use "~" as a
On 16.06.2011 22:46, Pavel Stehule wrote:
I have a query - should be ExpressionParam used for removing a
multiple function call when composite result is expanded?
With some similar optimization a SELECT (fce(x)).* FROM tab will be optimal
Hmm, I don't think it will work as is for that purpose,
Hi,
On Jun 16, 2011, at 9:18 PM, Florian Pflug wrote:
> On Jun16, 2011, at 20:14 , Alexey Klyukin wrote:
>>
>> Well, while thinking about this I decided to leave the counter for the
>> ParseConfigFp, but
>> drop it in ProcessConfigFile. The case we are protecting against is a single
>> file f
On ons, 2011-06-15 at 19:28 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > I couldn't see a way good way of programming around this (perhaps in the
> > second case, but it would get uselessly ugly), so perhaps just marking
> > the variables as potentially unused would be appropriate? See p
Heikki Linnakangas writes:
> The complicated part is to ensure that levelsup is always set correctly.
> At parse time, levelsup is always set to 0, as the syntax doesn't allow
> referencing upper levels directly. When an SQL function is inlined, any
> ExpressionParams in the expressions that ar
richhguard-monot...@yahoo.co.uk writes:
> This patch makes the intent of each initialization clear by using the
> constants directly instead of in a comment, and has the effect of being able
> to verify each line on it's own. The original requires verification of the
> preceding i++'s.
Applied,
On Thu, 16 Jun 2011 16:00:21 -0400, Tom Lane wrote:
Alvaro Herrera writes:
I disagree with this change. Debug builds are very useful to have
in
production, and you don't want to be running -O0 there. I have
found
that you can use a src/Makefile.custom like this for those times
when you
wan
Robert Haas wrote:
> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian wrote:
> > I now believe we are overthinking all this. ?pg_upgrade has always
> > supported specification of a port number. ?Why not just tell users to
> > specify an unused port number > 1023, and not to use the default value?
>
Greg Smith wrote:
> -It is still useful to set current_query to descriptive text in the
> cases where the transaction is etc. That text is not ambiguous
> with a real query, it is useful for a human-readable view, and it
> improves the potential for pg_stat_sessions to fully replace a
> depre
--On 29. März 2011 21:15:11 -0400 Joseph Adams
wrote:
Thanks. I applied a minor variation of this trick to the JSON module,
so now it builds/installs/tests cleanly on both REL8_4_0 and HEAD
(though it won't work if you copy contrib/json into a pre-9.1
PostgreSQL source directory and type `
Peter Eisentraut writes:
> I don't really agree that visual correlation needs to trump everything.
> If say
> foo =~ bar
> and
> foo ~= bar
> were to produce completely different results, this would introduce bugs
> all over the place.
Huh? That's about like arguing that standard mathema
Bernd Helmle writes:
> After reading Joseph's comment upthread, I don't see any consensus
> wether the existing pre-9.1 support is required or even desired. Maybe
> i missed it, but do we really expect an extension (or contrib module)
> to be backwards compatible to earlier major releases, when sh
2011/6/15 Mark Kirkwood :
> On 15/06/11 02:52, Cédric Villemain wrote:
>>
>> 2011/6/3 Mark Kirkwood:
>>>
>>> Corrected v4 patch with the test files, for completeness. Note that
>>> discussion has moved on and there will be a v5 :-)
>>>
>> Mark, can you submit your updated patch ?
>>
>
> Thanks for
If you set up a pgbench test case that hits the database with a lot of
concurrent selects and non-exclusive-locking ALTER TABLEs, 9.1 soon
falls over. For example:
$ cat foo.script
alter table pgbench_accounts set (fillfactor = 100);
SELECT abalance FROM pgbench_accounts WHERE aid = 525212;
$ cr
On Jun16, 2011, at 21:49 , Tom Lane wrote:
> All three of these are massive overkill. What we need is a general
> policy that providing commutators is a good idea. We do not need to try
> to make it 100.00% with an enforcement mechanism.
What parts of (1) do you think are overkill exactly, then?
On Thu, 16 Jun 2011 22:49:45 +0300, Peter Eisentraut
wrote:
This macro is provided by Autoconf and it appears to be using the
standard's terminology.
commit dbbba5279f66f95805c1e084e6f646d174931e56 refs/heads/master
Author: Peter Eisentraut
Date: Thu Jun 16 22:39:09 2011 +0300
Periodically
On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
> In typical cases where both versions of the row are on the same page,
> the window for the concurrent commit to happen is very narrow --- that's
> why you need so many clients to make it happen easily. With enough
> clients there's a good chanc
On Tue, Jun 14, 2011 at 05:56:05PM +0900, Shigeru Hanada wrote:
> Hi,
>
> I would like to propose support for per-column generic option, which
> is defined in the SQL/MED standard. In 9.0 release, support for
> foreign tables and per-table generic option have been added, but
> support for per-col
On 17/06/11 09:49, Cédric Villemain wrote:
I have issues applying it.
Please can you remove trailing space?
Also, you can generate a cool patch like this :
get git-external-diff from postgres/src/tools to /usr/lib/git-core/
chmod +x it
export GIT_EXTERNAL_DIFF=git-external-diff
git format-patch
2011/6/17 Robert Haas :
> On Tue, Jun 14, 2011 at 11:18 PM, Hitoshi Harada wrote:
>> Yesterday on PGXN I just released the first version of planinstr, a
>> plugin module to append planner time to EXPLAIN. I post this here
>> since it is mostly for developers.
>
> Wow, that is awesome. I sorta wis
Excerpts from Tom Lane's message of jue jun 16 17:33:17 -0400 2011:
> Peter Eisentraut writes:
> > I don't really agree that visual correlation needs to trump everything.
> > If say
> > foo =~ bar
> > and
> > foo ~= bar
> > were to produce completely different results, this would introduce
On 17/06/11 13:08, Mark Kirkwood wrote:
On 17/06/11 09:49, Cédric Villemain wrote:
I have issues applying it.
Please can you remove trailing space?
Also, you can generate a cool patch like this :
get git-external-diff from postgres/src/tools to /usr/lib/git-core/
chmod +x it
export GIT_EXTERNA
On Thu, Jun 16, 2011 at 9:10 PM, Hitoshi Harada wrote:
> 2011/6/17 Robert Haas :
>> On Tue, Jun 14, 2011 at 11:18 PM, Hitoshi Harada
>> wrote:
>>> Yesterday on PGXN I just released the first version of planinstr, a
>>> plugin module to append planner time to EXPLAIN. I post this here
>>> since i
On Fri, Jun 17, 2011 at 3:29 AM, Robert Haas wrote:
> Even if that were not an issue, I'm still more or less of the opinion
> that trying to solve the time synchronization problem is a rathole
> anyway. To really solve this problem well, you're going to need the
> standby to send a message contai
On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
> I believe that this is fundamentally unavoidable so long as we use
> SnapshotNow to read catalogs --- which is something we've talked about
> changing, but it will require a pretty major R&D effort to make it
> happen. In the meantime, we have to
On Thu, Jun 16, 2011 at 10:10 PM, Fujii Masao wrote:
>>> According to the above page, one purpose of time-delayed replication is to
>>> protect against user mistakes on master. But, when an user notices his wrong
>>> operation on master, what should he do next? The WAL records of his wrong
>>> ope
On Thu, Jun 16, 2011 at 5:16 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian wrote:
>> > I now believe we are overthinking all this. ?pg_upgrade has always
>> > supported specification of a port number. ?Why not just tell users to
>> > specify an un
Robert,
I took a look at this patch. To summarize its purpose as I understand it, it
does two independent but synergistic things:
1. Move the INSERT/UPDATE/DELETE clearing of visibility map bits from after
the main operation to before it. This has no affect on crash recovery. It
closes a race
On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown wrote:
> On 9 February 2011 02:11, Robert Haas wrote:
>> On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan wrote:
>>> Quite right, but the commitfest manager isn't meant to be a substitute for
>>> one. Bug fixes aren't subject to the same restrictions of f
Robert Haas wrote:
> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> > probably only #1 is appropriate.)
>
> I don't like any of these options as well as what I already proposed.
> I proposed a complicated approach that actually fixes the problem for
> real; you're proposing
On Wed, Jun 15, 2011 at 5:10 AM, Heikki Linnakangas
wrote:
> On 14.06.2011 17:57, Kevin Grittner wrote:
>>
>> Heikki Linnakangas wrote:
>>
>>> I did some further changes, refactoring SkipSerialization so that
>>> it's hopefully more readable, and added a comment about the
>>> side-effects. See at
On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
>> > probably only #1 is appropriate.)
>>
>> I don't like any of these options as well as what I already proposed.
>> I proposed a complicated approach
Robert Haas wrote:
> On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> >> > probably only #1 is appropriate.)
> >>
> >> I don't like any of these options as well as what I already proposed.
> >>
On Thu, Jun 16, 2011 at 11:49:48PM -0400, Robert Haas wrote:
> Does this mean that the open item "more SSI loose ends" can now be
> marked resolved?
I was just looking at it and contemplating moving it to the non-blockers
list. Of the five items:
- (1) and (4) are resolved
- (2) isn't an issue -
On Fri, Jun 17, 2011 at 12:30 AM, Dan Ports wrote:
> On Thu, Jun 16, 2011 at 11:49:48PM -0400, Robert Haas wrote:
>> Does this mean that the open item "more SSI loose ends" can now be
>> marked resolved?
>
> I was just looking at it and contemplating moving it to the non-blockers
> list. Of the fi
On 06/16/2011 05:27 PM, Bruce Momjian wrote:
Greg Smith wrote:
-It is still useful to set current_query to descriptive text in the
cases where the transaction is etc.
Uh, if we are going to do that, why not just add the boolean columns to
the existing view? Clearly renaming procpid
On Fri, Jun 17, 2011 at 12:32:46AM -0400, Robert Haas wrote:
> Perhaps it would be best to remove the general item and replace it
> with a list of more specific things that need doing - which might just
> mean #5.
Done.
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
-
On Fri, Jun 17, 2011 at 06:39, Greg Smith wrote:
> On 06/16/2011 05:27 PM, Bruce Momjian wrote:
>>
>> Greg Smith wrote:
>>
>>>
>>> -It is still useful to set current_query to descriptive text in the
>>> cases where the transaction is etc.
>>>
>>
>> Uh, if we are going to do that, why not just add
--On 16. Juni 2011 17:38:07 -0400 Tom Lane wrote:
After reading Joseph's comment upthread, I don't see any consensus
wether the existing pre-9.1 support is required or even desired. Maybe
i missed it, but do we really expect an extension (or contrib module)
to be backwards compatible to earli
101 - 140 of 140 matches
Mail list logo
