On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
On top of 4 listed reviewers I know Dan Farina is poking at the last update,
so we may see one more larger report on top of what's
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch has allowed some
On top of 4 listed reviewers I know Dan Farina is poking at
On Fri, Feb 25, 2011 at 1:33 AM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
On 2/23/11 7:10 AM, Robert Haas wrote:
IME, most bad query plans are caused by either incorrect
estimates of selectivity, or wrongheaded notions about what's likely
to be cached. If we could find a
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina dan...@heroku.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
- start A`
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing in parallel. The current implementation takes no
advantage of that
On Fri, Feb 25, 2011 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing
Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've decided to run the modifying sub-queries all with
the same command counter ID, they are logically executing in
parallel.
Just run the main plan and let it pull tuples from the CTEs as
needed.
On the face of it, that sounds like it has
On 2011-02-22 20:43, Jaime Casanova wrote:
you can make this happen more easily, i just run pgbench -n -c10 -j10
test and qot that warning and sometimes a segmentation fault and
sometimes a failed assertion
and the problematic code starts at
src/backend/replication/syncrep.c:277, here my
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Given that we've decided to run the modifying sub-queries all with
the same command counter ID, they are logically executing in
parallel.
Just run the main plan and let it pull tuples from the CTEs as
On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to
InitPlan and ExecutePlan that find all the modifying sub-queries and
force them to be cycled to completion before the main plan runs.
Just run the main plan and let it pull tuples from the
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 1:36 AM, Tom Lane wrote:
Why is it necessary to hack the portal logic at all? The patch seems to
work for me without that. (I've fixed quite a few bugs though, so maybe
what this is really doing is masking a problem
On 2011-02-25 6:12 PM, Tom Lane wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi writes:
Without hacking it broke when PQdescribePrepared was called on a
prepared query like:
WITH t AS (DELETE FROM foo)
SELECT 1;
Not sure if that's an actual problem, but it seemed like something worht
Daniel Farina wrote:
Server A syncreps to Server B
Now I want to provision server A-prime, which will eventually take the
place of A.
Server A syncreps to Server B
Server A syncreps to Server A-prime
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced
2011/2/25 Robert Haas robertmh...@gmail.com:
On Fri, Feb 25, 2011 at 1:33 AM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
On 2/23/11 7:10 AM, Robert Haas wrote:
IME, most bad query plans are caused by either incorrect
estimates of selectivity, or wrongheaded notions about
4. Even if we could accurately estimate the percentage of the table
that is cached, what then? For example, suppose that a user issues a
query which retrieves 1% of a table, and we know that 1% of that table
is cached. How much of the data that the user asked for is cache?
Hard to say,
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 6:12 PM, Tom Lane wrote:
The current implementation with everything in one plantree
really ought to look just like a SELECT so far as the portal code
is concerned.
The problem was that the old code was using
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are interleaved not sequential. We're never going to be
able to do any
On Fri, Feb 25, 2011 at 11:31 AM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are
2011/2/25 Cédric Villemain cedric.villemain.deb...@gmail.com:
All that having been said, I think that while Josh is thinking fuzzily
about the mathematics of his proposal, the basic idea is pretty
sensible. It is not easy - likely not possible - for the system to
have a good idea which things
Greg Stark gsst...@mit.edu writes:
On Fri, Feb 25, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, the real reason for doing it isn't any of those, but rather
to establish the principle that the executions of the modifying
sub-queries are interleaved not sequential.
Does the
On Fri, Feb 25, 2011 at 5:25 AM, marcin mank marcin.m...@gmail.com wrote:
On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina dan...@heroku.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
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 a map for expected response times for the pieces of data it is
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
2. Synchronous replication. Splitting up this patch
On Fri, Feb 25, 2011 at 10:41 AM, Yeb Havinga yebhavi...@gmail.com wrote:
I also did some initial testing on this patch and got the queue related
errors with 1 clients. With the code change from Jaime above I still got a
lot of 'not on queue warnings'.
I tried to understand how the queue
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The starting point
would be to define HAVE_LOCALE_T and then make it build. Microsoft has
all the relevant functions and types with
On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The starting point
would be to define HAVE_LOCALE_T and then make it build.
On Fri, Feb 25, 2011 at 9:54 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
According to the online documentation, the APIs are there:
http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
Now we'd need someone brave try to make it work. The
On Fri, Feb 25, 2011 at 22:58, Dave Page dp...@pgadmin.org wrote:
On Fri, Feb 25, 2011 at 9:54 PM, Andrew Dunstan and...@dunslane.net wrote:
On 02/25/2011 02:32 PM, Peter Eisentraut wrote:
According to the online documentation, the APIs are there:
Excerpts from Tom Lane's message of mar feb 15 12:42:00 -0300 2011:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
pageinspect is just a debugging aid, so I think we should change it from
smallint to int4 in 9.1, and not bother backporting.
I don't see any reason that the
On Fri, Feb 25, 2011 at 2:33 PM, Daniel Farina dan...@heroku.com wrote:
I know I got hit by a backend synchronization (in the sense of locks,
etc) bugs; do you think it is possible yours (sending SIGSTOP) could
be the same root cause? I haven't followed all the other bugs cleared
up by
2011/2/25 Robert Haas robertmh...@gmail.com:
2011/2/25 Cédric Villemain cedric.villemain.deb...@gmail.com:
All that having been said, I think that while Josh is thinking fuzzily
about the mathematics of his proposal, the basic idea is pretty
sensible. It is not easy - likely not possible -
4. Even if we could accurately estimate the percentage of the table
that is cached, what then? For example, suppose that a user issues a
query which retrieves 1% of a table, and we know that 1% of that table
is cached. How much of the data that the user asked for is cache?
FWIW, for a
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
Yeah, I think that's something we said months ago is going to be a 9.2
feature, no
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
OK, I will make those adjustments. Are you going to do more work on the
documentation part of the patch? I can stick to working on the code
part meanwhile, if you are.
I am planning on working
On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus j...@agliodbs.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
Yeah, I
Daniel,
Ah, okay, I had missed that discussion, I also did not know it got so
specific as to address this case (are you sure?) rather than something
more general, say quorum or N-safe durability.
The way we address that case is through n-safe durability.
The user may have their own level of
On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus j...@agliodbs.com wrote:
Daniel,
Ah, okay, I had missed that discussion, I also did not know it got so
specific as to address this case (are you sure?) rather than something
more general, say quorum or N-safe durability.
The way we address that
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence of their
transaction post-failover, why should the DBA care?
I think that's the difference between failover
On Wed, 2011-02-23 at 22:42 -0800, Daniel Farina wrote:
Oh, yes, this reproduces past shutdowns/startups, and there's quite a
few txids before I catch up. I'm also comfortable poking around with
gdb (I have already recompiled with debugging symbols and
optimizations off and was poking around,
On 2/25/11 4:57 PM, Jeff Davis wrote:
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence of their
transaction post-failover, why should the DBA care?
I
On Fri, Feb 25, 2011 at 4:52 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2011-02-23 at 22:42 -0800, Daniel Farina wrote:
Oh, yes, this reproduces past shutdowns/startups, and there's quite a
few txids before I catch up. I'm also comfortable poking around with
gdb (I have already recompiled
On Fri, Feb 25, 2011 at 5:21 PM, Josh Berkus j...@agliodbs.com wrote:
On 2/25/11 4:57 PM, Jeff Davis wrote:
On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
Hmmm, I don't follow this. The user can only disable syncrep for their
own transactions. If they don't care about the persistence
On 2011-02-26 2:00 AM, Tom Lane wrote:
I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.
Thanks a lot!
One thing bothers me though: what was the reason for requiring a
RETURNING clause for data-modifying statements in
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-26 2:00 AM, Tom Lane wrote:
I've gone ahead and applied the code portion of the patch, with
modifications as per discussion, and other editorialization.
Thanks a lot!
One thing bothers me though: what was the reason for
On Fri, Feb 25, 2011 at 09:58:36AM -0500, Tom Lane wrote:
I had what seems to me a remarkably good idea, though maybe someone else
can spot a problem with it. Given that we've decided to run the
modifying sub-queries all with the same command counter ID, they are
logically executing in
On Thu, Feb 24, 2011 at 11:20:48AM -0500, Tom Lane wrote:
The wCTE patch refers to the feature it's adding as DML WITH. I'm
still pretty unhappy with that terminology. In my view of the world,
DML includes SELECT as well as INSERT/UPDATE/DELETE. The wikipedia
entry about the term
On Thu, Feb 24, 2011 at 11:35:30AM -0800, David Wheeler wrote:
On Feb 24, 2011, at 10:43 AM, Robert Haas wrote:
The best idea I have at the moment is to spell out data modifying
command (or statement) rather than relying on the acronym.
In the code, we could change hasDmlWith to
David Fetter da...@fetter.org writes:
What's the effect, if any, on CTEs that depend on each other
explicitly?
An error. That would require mutual recursion, which we don't
support for the SELECT case let alone data-modifying statements.
regards, tom lane
--
Sent via
On Fri, Feb 25, 2011 at 10:12:02PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
What's the effect, if any, on CTEs that depend on each other
explicitly?
An error. That would require mutual recursion, which we don't
support for the SELECT case let alone data-modifying
David Fetter da...@fetter.org writes:
Sorry that was unclear. Let's imagine there's a DELETE ... RETURNING
in one WITH, and an UPDATE in another that depends on that one. Is
that still allowed?
Yeah it is, although I just noticed that there's a bug in the new
implementation:
with t1 as
I wrote:
The first solution that comes to mind is to pay attention to the
interdependencies of the CTEs, and perform the cleanup in an appropriate
order (here, the ModifyTable for y needs to be cycled first).
Doh ... actually, we already *are* ordering the CTEs in dependency
order, so it's a
On Thu, Feb 24, 2011 at 9:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 24, 2011 at 8:13 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Wed, 23 Feb 2011 20:30:05 +0900
Shigeru HANADA han...@metrosystems.co.jp wrote:
On Tue, 22 Feb 2011 11:33:25 -0500
Robert Haas
On Thu, Feb 24, 2011 at 11:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 5:21 PM, Tom Lane wrote:
Oh, did we decide to do it that way? OK with me, but the submitted docs
are woefully inadequate on the point. This behavior is
On Thu, Feb 24, 2011 at 9:03 AM, Jan Urbański wulc...@wulczer.org wrote:
On 24/02/11 14:10, Peter Eisentraut wrote:
On tor, 2010-12-23 at 14:56 +0100, Jan Urbański wrote:
For errors originating from Python exceptions add the traceback as the
message detail. The patch tries to mimick Python's
On Wed, Feb 9, 2011 at 5:22 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-02-08 at 00:32 -0500, Steve Singer wrote:
On 11-02-06 11:40 AM, Jan Urbański wrote:
PFA an updated patch with documentation.
Yeah, changed them.
Those changes look fine. The tests now pass.
I've
Robert Haas robertmh...@gmail.com writes:
Tom/Alvaro, have the two of you hammered out who is going to finish
this one off? I *believe* Alvaro told me on IM that he was leaving
this one for Tom.
Last I heard, the ball was in my court. I'll try to get it done over
the weekend.
On Tue, Feb 15, 2011 at 6:04 PM, Jan Urbański wulc...@wulczer.org wrote:
On 15/02/11 20:39, Peter Eisentraut wrote:
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
Because the invocation that actually recurses sets up the scene for
failure.
That's what we're observing, but I can't
On Fri, Feb 25, 2011 at 7:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-24 6:37 PM +0200, Tom Lane wrote:
OK, I will make those adjustments. Are you going to do more work on the
documentation part of the patch? I can stick to
On Fri, Feb 25, 2011 at 2:26 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Fri, Feb 25, 2011 at 6:41 PM, Josh Berkus j...@agliodbs.com wrote:
One idea Tom and I kicked around previously is to set an assumed
caching percentage for each table based on its size relative to
effective_cache_size - in other words, assume that the smaller a table
is, the more of it will
Robert Haas robertmh...@gmail.com writes:
Yay! I'm excited about this, particularly the possible pipelining
stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
have it be like cool and fast and stuff.
Or at least I hope you can do that.
It's gonna need some work yet. As
On Sat, Feb 26, 2011 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yay! I'm excited about this, particularly the possible pipelining
stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
have it be like cool and fast and stuff.
Or
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi writes:
On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to
InitPlan and ExecutePlan that find all the modifying sub-queries and
force them to be cycled to completion before the main plan runs.
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.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's
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
general for monitoring. ?If we could make top-level table and index
Any progress on this?
---
Brendan Jurd wrote:
On 18 October 2010 01:19, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
On 17 October 2010 09:59, Tom Lane t...@sss.pgh.pa.us wrote:
Good
66 matches
Mail list logo
