--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
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 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 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: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 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 -
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: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
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
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, 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,
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 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
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 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 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 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 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
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
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
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
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 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 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 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?
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
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
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
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
--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 `
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
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?
>
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
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,
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
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
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 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,
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
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 ons, 2011-06-15 at 18:19 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Is this a route we want to go down?
>
> > - GISTENTRY vector[1]; /* variable-length
> array */
> > + GISTENTRY vector[FLEXIBLE_ARRAY_MEMBER];
>
> Yes, I was thinking about the same
Florian Pflug writes:
> Well, I think there are basically three choices here, kludge or no
> kludge.
> (1) We either decree once and for all that binary operations ought to
> have commutators, modify CREATE TYPE to issue a warning if you
> create one without, add the missing ones, and add a check
Hello
2011/6/3 Heikki Linnakangas :
> On 31.05.2011 19:10, Heikki Linnakangas wrote:
>>
>> For index expressions, we could use a function similar to
>> ChangeVarNodes(), that shifts all the paramids in the already-planned
>> expression, preparing it for inclusion within the enclosing plan. I'm a
>
Excerpts from Greg Sabino Mullane's message of jue jun 16 15:33:35 UTC 2011:
>
> Hash: RIPEMD160
>
> >> Or perhaps pg_connections. Yes, +1 to making things fully backwards
> >> compatible by keeping pg_stat_activity around but making a better
> >> designed and better named table (view/SRF/whateve
Excerpts from Bernd Helmle's message of jue jun 16 14:30:48 -0400 2011:
>
> --On 16. Juni 2011 13:25:05 -0400 Tom Lane wrote:
>
> > Possible solution is to leave bootstrap's behavior alone, and have a
> > step during initdb's post-bootstrap stuff that creates a matching
> > pg_constraint row for
On 16.06.2011 20:22, A.M. wrote:
I don't believe any conclusions were reached because the debate concerned
whether or not fcntl locking was sufficient. I thought so while others pointed
out that the proposed interlock would not work with mutli-client NFSv3 despite
the fact that the current int
On Thu, Jun 16, 2011 at 2:22 PM, Florian Pflug wrote:
> On Jun16, 2011, at 19:54 , Robert Haas wrote:
>> On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote:
>>> We deprecated those names for the geometric operators largely because
>>> there wasn't any visual correlation between the commutator pairs
Oh, actually it's so easy. Thanks.
--
With best regards,
Alexander Korotkov.
On Thu, Jun 16, 2011 at 10:26 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 16.06.2011 21:13, Alexander Korotkov wrote:
>
>> My current idea is to measure number of IO accesses by pg_stat
--On 16. Juni 2011 13:25:05 -0400 Tom Lane wrote:
Possible solution is to leave bootstrap's behavior alone, and have a
step during initdb's post-bootstrap stuff that creates a matching
pg_constraint row for every pg_attribute entry that's marked attnotnull.
+1 for this idea. I never came to
On Wed, Jun 15, 2011 at 1:58 AM, Fujii Masao wrote:
> When the replication connection is terminated, the standby tries to read
> WAL files from the archive. In this case, there is no walreceiver process,
> so how does the standby calculate the clock difference?
Good question. Also, just because
On 16.06.2011 21:13, Alexander Korotkov wrote:
My current idea is to measure number of IO accesses by pg_stat_statements
and measure CPU usage by /proc/PID/stat. Any thoughts?
Actually, you get both of those very easily with:
set log_statement_stats=on
LOG: QUERY STATISTICS
DETAIL: ! system
On Jun16, 2011, at 19:54 , Robert Haas wrote:
> On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote:
>> We deprecated those names for the geometric operators largely because
>> there wasn't any visual correlation between the commutator pairs.
>> I can't see introducing the same pairing for regex oper
On Jun16, 2011, at 20:14 , Alexey Klyukin wrote:
> On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote:
>> On Jun16, 2011, at 18:46 , Alexey Klyukin wrote:
>>> I just recalled a reason for counting the total number of errors. There is
>>> a condition that
>>> checks that the total number of errors is
On Jun 16, 2011, at 8:01 PM, Florian Pflug wrote:
> On Jun16, 2011, at 18:46 , Alexey Klyukin wrote:
>> On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote:
>>> Hm, wouldn't a test for "context == PGC_POSTMASTER" be more appropriate?
>>
>> In such a case the errors caused by command-line arguments
Robert Haas writes:
> I'm having trouble avoiding the conclusion that we're trying to shove
> a round peg into a square hole. The idea that we have to have a
> commutator for every operator just because we don't handle left and
> right symmetrically sits poorly with me. I can't really argue with
My current idea is to measure number of IO accesses by pg_stat_statements
and measure CPU usage by /proc/PID/stat. Any thoughts?
--
With best regards,
Alexander Korotkov.
On Thu, Jun 16, 2011 at 1:33 PM, Alexander Korotkov wrote:
> Actually, I would like to measure CPU and IO load independe
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.
>
> http://www.pgxn.org/dist/planinstr/
>
> db1=# load '$libdir/pla
On 16.06.2011 20:33, Dan Ports wrote:
On Thu, Jun 16, 2011 at 04:39:09PM +0300, Heikki Linnakangas wrote:
There's no mention on what T1 is. I believe it's supposed to be Tin, in
the terminology used in the graph.
Yes, I changed the naming after I originally wrote it, and missed a
couple spots.
On Thu, Jun 16, 2011 at 12:50 AM, Tom Lane wrote:
> We deprecated those names for the geometric operators largely because
> there wasn't any visual correlation between the commutator pairs.
> I can't see introducing the same pairing for regex operators if we
> already decided the geometric case wa
On Thu, Jun 16, 2011 at 5:34 PM, Robert Haas wrote:
> On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs wrote:
>> On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
wrote:
> With regards to the naming, I think it woul
On Thu, Jun 16, 2011 at 1:25 PM, Tom Lane wrote:
> Possible solution is to leave bootstrap's behavior alone, and have a
> step during initdb's post-bootstrap stuff that creates a matching
> pg_constraint row for every pg_attribute entry that's marked attnotnull.
That seems like a pretty good solu
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?
1. Because it shouldn't be t
On Thu, Jun 16, 2011 at 04:39:09PM +0300, Heikki Linnakangas wrote:
> There's no mention on what T1 is. I believe it's supposed to be Tin, in
> the terminology used in the graph.
Yes, I changed the naming after I originally wrote it, and missed a
couple spots. T1 should be Tin.
> I don't see how
Alvaro Herrera writes:
> So, question: do we need pg_constraint rows to exist for all NOT NULL
> constraints, including those in system catalogs, and including those in
> bootstrap catalogs? If we're going to require that, we're going to need
> to add a few initial data lines to the pg_constraint
On Jun 16, 2011, at 11:51 AM, Heikki Linnakangas wrote:
> What's the current state of the POSIX shared memory patch? I grabbed the
> patch from
> http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com
> and it doesn't seem to apply cleanly any more
Excerpts from Bernd Helmle's message of jue jun 16 09:37:24 -0400 2011:
>
>
> --On 16. Juni 2011 14:30:27 +0200 Radosław Smogura
> wrote:
>
> > Hello,
> >
> > I'm sending following patch which disables optimization when
> > --enable-debug
> > is passed. It was nasty (for me, at least) that
Thanks, I am looking at the new version from Bernd's git repo. One
problem I noticed is that it doesn't really work correctly for all
callers of heap_create_with_catalog -- you're only passing the cooked
not null constraints in DefineRelation, but there are some other places
that call heap_creat
On Jun16, 2011, at 18:46 , Alexey Klyukin wrote:
> On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote:
>> Hm, wouldn't a test for "context == PGC_POSTMASTER" be more appropriate?
>
> In such a case the errors caused by command-line arguments won't stop the
> postmaster.
> PGC_S_FILE seems to handle
On Thu, Jun 16, 2011 at 9:48 AM, Robert Creager wrote:
> On Jun 15, 2011, at 7:51 PM, Tom Lane wrote:
>
>> ...
>> installation paths. About the only good thing to be said about it is
>> that these characters are so troublesome that Unix users are unlikely
>> to use them in directory names anyway
Tom Lane wrote:
> The point is that another backend's entry could be in a different
> *server* encoding, and what do you do if there's no equivalent
> character in your encoding?
My first thought was that it was just a matter of picking a
character to represent the "unprintable" characters. M
--On 16. Juni 2011 15:33:35 + Greg Sabino Mullane wrote:
No, this is clearly connections, not sessions. At least based on the items
in the postgresql.conf file, especially max_connections (probably one of the
items most closely associated with pg_stat_activity)
Well, but it doesn't show
On Thu, Jun 16, 2011 at 11:51 AM, Heikki Linnakangas
wrote:
> What's the current state of the POSIX shared memory patch? I grabbed the
> patch from
> http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com
> and it doesn't seem to apply cleanly any more
Robert Haas writes:
> That's a reasonable point, but I still don't really like the name
> "fastpath", because it's not faster, and it's not a path. It's just
> smaller. How about xl_xact_commit_simple or xl_xact_commit_compact or
> something like that?
xl_xact_commit_short ?
"_simple" would
On Jun 16, 2011, at 6:49 PM, Florian Pflug wrote:
> On Jun16, 2011, at 17:23 , Alexey Klyukin wrote:
>> On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote:
>>> The first problem I ran into when I tried to test this is that it *only*
>>> reports multiple errors during config file reload on SIHUP, no
Greg Smith writes:
> The only other item related to this view on the TODO was "Have
> pg_stat_activity display query strings in the correct client encoding".
> That might be worthwhile to bundle into this rework, but it doesn't seem
> something that impacts the UI such that it must be consider
On Thu, Jun 16, 2011 at 12:12 PM, Simon Riggs wrote:
> On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
>>> wrote:
With regards to the naming, I think it would be better if we kept
XLOG_XACT_COMMIT record exactly
On Jun14, 2011, at 17:47 , richhguard-monot...@yahoo.co.uk wrote:
> 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 pre
On Thu, Jun 16, 2011 at 3:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2011 at 7:25 AM, Simon Riggs
>> wrote:
>>> With regards to the naming, I think it would be better if we kept
>>> XLOG_XACT_COMMIT record exactly as it is now, and make the second
>>> record an entirely new
Excerpts from Leonardo Francalanci's message of jue jun 16 09:00:15 -0400 2011:
> Should I also change the struct name from xl_xact_commit to
> xl_xact_commit_fast_path?
Yes, please.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Deve
On Thu, Jun 16, 2011 at 04:53:41PM +0100, Simon Riggs wrote:
> On Thu, Jun 16, 2011 at 3:47 PM, Noah Misch wrote:
> > Thanks. ?We still hit a conflict when btpo.xact == RecentGlobalXmin and the
> > standby has a transaction older than any master transaction. ?This happens
> > because the tests at
Right, but I think he needs the "it's not easy, here's the whole
workflow" overview first.
Ross
--
Ross Reedstrom, Ph.D. reeds...@rice.edu
Systems Engineer & Admin, Research Scientistphone: 713-348-6166
Connexions http://cnx.org
On Thu, Jun 16, 2011 at 4:53 PM, Simon Riggs wrote:
> I agree with your suggested fix.
Please ignore the previous patch, which was sent in error. Here's the
fix. I'll apply this tomorrow morning if we all still agree.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL De
This is some attempt to make "streaming" protocol. Difference is that instead
of returning bytes it is intended to take stream, and self-stream.
I posted, one day, some requirements for streaming, I can't reference it now,
as I am away from computer.
Regards,
Radek
-Original Message-
Excerpts from Peter Geoghegan's message of jue jun 16 08:42:39 -0400 2011:
> On 16 June 2011 13:15, Heikki Linnakangas
> wrote:
>
> > Hmm, I'm not sure having the pid in that error message is too useful in the
> > first place. The process was just spawned, and it will die at that error.
> > When
Excerpts from Radosław Smogura's message of jue jun 16 08:30:27 -0400 2011:
> Hello,
>
> I'm sending following patch which disables optimization when
> --enable-debug is passed. It was nasty (for me, at least) that debug
> build required passing of CFLAGS with -O0 to get nice traceable code.
On Thu, Jun 16, 2011 at 3:47 PM, Noah Misch wrote:
> On Thu, Jun 16, 2011 at 12:02:47AM +0100, Simon Riggs wrote:
>> On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch wrote:
>> > On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
>> >> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas
>> >> wrot
What's the current state of the POSIX shared memory patch? I grabbed the
patch from
http://archives.postgresql.org/message-id/d9edacf7-53f1-4355-84f8-2e74cd19d...@themactionfaction.com
and it doesn't seem to apply cleanly any more. Are you planning to
continue working on it?
If I understood t
On Jun16, 2011, at 17:23 , Alexey Klyukin wrote:
> On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote:
>> The first problem I ran into when I tried to test this is that it *only*
>> reports multiple errors during config file reload on SIHUP, not during
>> postmaster startup. I guess it's been done th
Hello
2011/6/16 Radosław Smogura :
> Hello,
>
> Here I would like to expose changes to pg_type and type infrastructure about
> streaming. Changes are as follows:
> - added new column typstreamin typestremout
> - general contract for those is for streamin same as receive (receive use
> internal), f
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Or perhaps pg_connections. Yes, +1 to making things fully backwards
>> compatible by keeping pg_stat_activity around but making a better
>> designed and better named table (view/SRF/whatever).
> I thought about that too when reading the thre
This patch breaks silent_mode=on. In silent_mode, postmaster forks early
on, to detach from the controlling tty. It uses fork_process() for that,
which with patch closes the write end of the postmaster-alive pipe, but
that's wrong because the child becomes the postmaster process.
On a stylisti
Hello,
Here I would like to expose changes to pg_type and type infrastructure
about streaming. Changes are as follows:
- added new column typstreamin typestremout
- general contract for those is for streamin same as receive (receive
use internal), for streamout it is (internal, )
- changes to
On 06/15/2011 12:41 PM, Robert Haas wrote:
But I will note that we had better be darn sure to make all the changes we
want to make in one go, because I dowanna have to create pg_sessions2
(or pg_tessions?) in a year or three.
I just added a new section to the TODO to start collecting up som
Florian,
On Jun 16, 2011, at 2:34 PM, Florian Pflug wrote:
> Hi
>
> On May14, 2011, at 00:49 , Alexey Klyukin wrote:
>> The patch forces the parser to report all errors (max 100) from the
>> ProcessConfigFile/ParseConfigFp. Currently, only the first parse error or an
>> invalid directive is repo
On Thu, Jun 16, 2011 at 1:48 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> "Ross J. Reedstrom" writes:
>> > As an operations guy, the idea of an upgrade using a random,
>> > non-repeatable port selection gives me the hebejeebees.
>>
>> Yeah, I agree. The latest version of the patch doesn't appea
On 06/16/2011 10:10 AM, Tom Lane wrote:
I could see providing some other nonstandard configure switch that
changed the default -O level ... but realistically, would that do
anything that you couldn't already do by setting CFLAGS, ie
./configure CFLAGS="-O0 -g"
I think a small discu
On May26, 2011, at 11:25 , Peter Geoghegan wrote:
> I'm a bit disappointed that no one has commented on this yet. I would
> have appreciated some preliminary feedback.
I noticed to your patch doesn't seem to register a SIGIO handler, i.e.
it doesn't use async IO machinery (or rather a tiny part th
On 16 June 2011 15:27, Heikki Linnakangas
wrote:
> I don't understand that comment. Why can't e.g postmaster death happen at
> the same time as a latch is set? I think the code is fine as it is, we just
> need to document that if there are several events that would wake up
> WaitLatch(), we make
On Thu, Jun 16, 2011 at 12:02:47AM +0100, Simon Riggs wrote:
> On Tue, Jun 14, 2011 at 5:28 AM, Noah Misch wrote:
> > On Mon, Jun 13, 2011 at 04:16:06PM +0100, Simon Riggs wrote:
> >> On Mon, Jun 13, 2011 at 3:11 AM, Robert Haas wrote:
> >> > On Sun, Jun 12, 2011 at 3:01 PM, Noah Misch wrote:
>
On Jun16, 2011, at 16:10 , Tom Lane wrote:
> Florian Pflug writes:
>> I usually use -O1 for debug builds, these are usually still at least
>> somewhat debuggable with gdb.
>
> I tend to do that too, but I still think that folding it into
> --enable-debug would be a mistake.
+1.
I didn't mean to
1 - 100 of 140 matches
Mail list logo
