Re: [HACKERS] What would AggrefExprState nodes' args contain?
On Thu, Apr 28, 2011 at 4:21 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Thanks a lot. I was browsing the code and was thinking this would be the
most probable scenario.
But, the point is that even after removing the args initialization part in
the ExecInitExpr for AggrefState, the sum() function is working. I believe
that is also a aggregate function! If yes, then how is it working if I dd
not allow the args to be initialized. The debugger says that ExecEvalAggref
was called and the results returned are true.
Did you check the same thing with avg, or any statistical aggregates. Sum
does not need all the aggregate infrastructure in place, for example
finalisation function. May be after removing initialization part you want to
run regression (or at least aggregates.sql) to see what it breaks.
Regards,
Vaibhav
On Thu, Apr 28, 2011 at 2:38 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
The args in AggrefExprState, are used in the functions ExecAgg,
ExecInitAgg and their minions to evaluate the aggregates. The
ExecEvalAggref() merely retrieves the results of aggregation calculated
during ExecAgg.
On Tue, Apr 26, 2011 at 12:04 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Hello all,
While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args list
is a list of TargetEntry nodes. But the state node's args is initialized in
ExecInitExpr as:
astate-args = (List *) ExecInitExpr((Expr *) aggref-args,
parent);
This would mean that the args is actually a ExprState node list with one
single item (the ExprState node / tree). I believe it potentially contains
the execution tree to determine the state / value of the aggref
(sub)expression. But then in the ExecEvalAggref function I do not see the
args coming into picture at all! I am also unable to find a call to some
function for executing the state node created in the args list. Also, no
value is being extracted from that node! Why is it so?
For quick reference I am adding the function (may be you don't need it
but still... its a small one):
/*
*ExecEvalAggref
*
*Returns a Datum whose value is the value of the precomputed
*aggregate found in the given expression context.
*
*/
static Datum
ExecEvalAggref(AggrefExprState *aggref, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone)
{
if (isDone)
*isDone = ExprSingleResult;
if (econtext-ecxt_aggvalues == NULL)/* safety check */
elog(ERROR, no aggregates in this expression context);
*isNull = econtext-ecxt_aggnulls[aggref-aggno];
return econtext-ecxt_aggvalues[aggref-aggno];
}
What is the use of args in AggrefExprState node here? Is it there just
for some historical reason?
Regards,
Vaibhav
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
Re: [HACKERS] SSI non-serializable UPDATE performance
On Thu, Apr 28, 2011 at 06:45:54PM +0200, Robert Haas wrote: Yeah, I think Dan's notes about memory ordering would be good to include. I left it out initially because I didn't want to make things more confusing. As far as memory ordering is concerned, this is the same story as anything else that uses lwlocks: the spinlock memory barrier prevents memory accesses from being reordered before the lock is acquired. The only unusual thing here is that the lock in question isn't the one that protects the variable we're reading. But I'm OK with adding a comment if you think it helps. Patch attached. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c index fe0e458..694e87d 100644 --- a/src/backend/storage/lmgr/predicate.c +++ b/src/backend/storage/lmgr/predicate.c @@ -2298,6 +2298,9 @@ PredicateLockTupleRowVersionLink(const Relation relation, * locks. Even if a serializable transaction starts concurrently, * we know it can't take any SIREAD locks on the modified tuple * because the caller is holding the associated buffer page lock. + * Memory reordering isn't an issue; the memory barrier in the + * LWLock acquisition guarantees that this read occurs while the + * buffer page lock is held. */ if (!TransactionIdIsValid(PredXact-SxactGlobalXmin)) return; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unknown conversion %m
On Thu, Apr 28, 2011 at 02:49:07PM -0400, Andrew Dunstan wrote: I'll make that change if Michael's happy. Sure, go ahead. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SQLERRD and dump of variables
2011/4/28 Noah Misch n...@leadboat.com In the mean time, have you considered doing something like this instead? EXCEPTION WHEN deadlock_detected RAISE NOTICE '% var_foo % var_bar', var_foo, var_bar; RAISE; The information isn't as nicely aggregated, but you don't lose any details. Thank you, very useful! This solved my problem. I wrote a comment at http://www.postgresql.org/docs/9.0/interactive/plpgsql-errors-and-messages.html . Also keep in mind that you may have several PL/pgSQL functions in your call stack, and you'll want to capture the local variables at each level. Yes, the format of the string written to the log must support multi-level data strucutres, perhaps JSON would be a good choice. Consider the potential need to avoid logging very-large variable values. The GUC could perhaps be a size limit (0 disables the feature entirely), not a boolean. Yes, for very large values, it's okay if they are truncated or perhaps truncated+a simple MD5-hash of the value, so you can check if it is equal to the excepted value. You are usually not interested in these anyway, since what you are looking for are probably things like ID-numbers, usernames, etc.
Re: [HACKERS] What would AggrefExprState nodes' args contain?
I tried all aggregates - min,max,sum,count and avg. all are working. What do
you suggest now?
On Fri, Apr 29, 2011 at 11:30 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Apr 28, 2011 at 4:21 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Thanks a lot. I was browsing the code and was thinking this would be the
most probable scenario.
But, the point is that even after removing the args initialization part in
the ExecInitExpr for AggrefState, the sum() function is working. I believe
that is also a aggregate function! If yes, then how is it working if I dd
not allow the args to be initialized. The debugger says that ExecEvalAggref
was called and the results returned are true.
Did you check the same thing with avg, or any statistical aggregates. Sum
does not need all the aggregate infrastructure in place, for example
finalisation function. May be after removing initialization part you want to
run regression (or at least aggregates.sql) to see what it breaks.
Regards,
Vaibhav
On Thu, Apr 28, 2011 at 2:38 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
The args in AggrefExprState, are used in the functions ExecAgg,
ExecInitAgg and their minions to evaluate the aggregates. The
ExecEvalAggref() merely retrieves the results of aggregation calculated
during ExecAgg.
On Tue, Apr 26, 2011 at 12:04 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Hello all,
While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args list
is a list of TargetEntry nodes. But the state node's args is initialized in
ExecInitExpr as:
astate-args = (List *) ExecInitExpr((Expr *) aggref-args,
parent);
This would mean that the args is actually a ExprState node list with one
single item (the ExprState node / tree). I believe it potentially contains
the execution tree to determine the state / value of the aggref
(sub)expression. But then in the ExecEvalAggref function I do not see the
args coming into picture at all! I am also unable to find a call to some
function for executing the state node created in the args list. Also, no
value is being extracted from that node! Why is it so?
For quick reference I am adding the function (may be you don't need it
but still... its a small one):
/*
*ExecEvalAggref
*
*Returns a Datum whose value is the value of the precomputed
*aggregate found in the given expression context.
*
*/
static Datum
ExecEvalAggref(AggrefExprState *aggref, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone)
{
if (isDone)
*isDone = ExprSingleResult;
if (econtext-ecxt_aggvalues == NULL)/* safety check */
elog(ERROR, no aggregates in this expression context);
*isNull = econtext-ecxt_aggnulls[aggref-aggno];
return econtext-ecxt_aggvalues[aggref-aggno];
}
What is the use of args in AggrefExprState node here? Is it there just
for some historical reason?
Regards,
Vaibhav
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
Re: [HACKERS] What would AggrefExprState nodes' args contain?
Is regression clean?
Have you looked at how the member is used using some code browsing tool like
cscope by examining it's every occurrence? PG uses simulated run time
polymorphism a lot, so any Node should examined carefully from that angle
too. Even after all of that if you think that it's not being used, you can
submit a patch to community removing that member. Somebody from community
reviewers will review and commit the patch if they find it correct and
useful.
Read http://wiki.postgresql.org/wiki/Submitting_a_Patch before submitting
the patch.
On Fri, Apr 29, 2011 at 3:22 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
I tried all aggregates - min,max,sum,count and avg. all are working. What
do you suggest now?
On Fri, Apr 29, 2011 at 11:30 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Apr 28, 2011 at 4:21 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Thanks a lot. I was browsing the code and was thinking this would be the
most probable scenario.
But, the point is that even after removing the args initialization part
in the ExecInitExpr for AggrefState, the sum() function is working. I
believe that is also a aggregate function! If yes, then how is it working if
I dd not allow the args to be initialized. The debugger says that
ExecEvalAggref was called and the results returned are true.
Did you check the same thing with avg, or any statistical aggregates. Sum
does not need all the aggregate infrastructure in place, for example
finalisation function. May be after removing initialization part you want to
run regression (or at least aggregates.sql) to see what it breaks.
Regards,
Vaibhav
On Thu, Apr 28, 2011 at 2:38 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
The args in AggrefExprState, are used in the functions ExecAgg,
ExecInitAgg and their minions to evaluate the aggregates. The
ExecEvalAggref() merely retrieves the results of aggregation calculated
during ExecAgg.
On Tue, Apr 26, 2011 at 12:04 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Hello all,
While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args list
is a list of TargetEntry nodes. But the state node's args is initialized
in
ExecInitExpr as:
astate-args = (List *) ExecInitExpr((Expr *) aggref-args,
parent);
This would mean that the args is actually a ExprState node list with
one single item (the ExprState node / tree). I believe it potentially
contains the execution tree to determine the state / value of the aggref
(sub)expression. But then in the ExecEvalAggref function I do not see the
args coming into picture at all! I am also unable to find a call to some
function for executing the state node created in the args list. Also, no
value is being extracted from that node! Why is it so?
For quick reference I am adding the function (may be you don't need it
but still... its a small one):
/*
*ExecEvalAggref
*
*Returns a Datum whose value is the value of the precomputed
*aggregate found in the given expression context.
*
*/
static Datum
ExecEvalAggref(AggrefExprState *aggref, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone)
{
if (isDone)
*isDone = ExprSingleResult;
if (econtext-ecxt_aggvalues == NULL)/* safety check */
elog(ERROR, no aggregates in this expression context);
*isNull = econtext-ecxt_aggnulls[aggref-aggno];
return econtext-ecxt_aggvalues[aggref-aggno];
}
What is the use of args in AggrefExprState node here? Is it there just
for some historical reason?
Regards,
Vaibhav
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
Re: [HACKERS] What would AggrefExprState nodes' args contain?
I have a small db which I am using to test it. Moreover I am new to the
terms. What would you mean by 'regression'?
Also, I am using eclipse for browsing the code. It resolves all references
and function calls, declarations, definitions etc.
Regards,
Vaibhav
On Fri, Apr 29, 2011 at 3:31 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
Is regression clean?
Have you looked at how the member is used using some code browsing tool
like cscope by examining it's every occurrence? PG uses simulated run time
polymorphism a lot, so any Node should examined carefully from that angle
too. Even after all of that if you think that it's not being used, you can
submit a patch to community removing that member. Somebody from community
reviewers will review and commit the patch if they find it correct and
useful.
Read http://wiki.postgresql.org/wiki/Submitting_a_Patch before submitting
the patch.
On Fri, Apr 29, 2011 at 3:22 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
I tried all aggregates - min,max,sum,count and avg. all are working. What
do you suggest now?
On Fri, Apr 29, 2011 at 11:30 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
On Thu, Apr 28, 2011 at 4:21 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Thanks a lot. I was browsing the code and was thinking this would be the
most probable scenario.
But, the point is that even after removing the args initialization part
in the ExecInitExpr for AggrefState, the sum() function is working. I
believe that is also a aggregate function! If yes, then how is it working
if
I dd not allow the args to be initialized. The debugger says that
ExecEvalAggref was called and the results returned are true.
Did you check the same thing with avg, or any statistical aggregates. Sum
does not need all the aggregate infrastructure in place, for example
finalisation function. May be after removing initialization part you want to
run regression (or at least aggregates.sql) to see what it breaks.
Regards,
Vaibhav
On Thu, Apr 28, 2011 at 2:38 PM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
The args in AggrefExprState, are used in the functions ExecAgg,
ExecInitAgg and their minions to evaluate the aggregates. The
ExecEvalAggref() merely retrieves the results of aggregation calculated
during ExecAgg.
On Tue, Apr 26, 2011 at 12:04 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Hello all,
While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args
list
is a list of TargetEntry nodes. But the state node's args is initialized
in
ExecInitExpr as:
astate-args = (List *) ExecInitExpr((Expr *) aggref-args,
parent);
This would mean that the args is actually a ExprState node list with
one single item (the ExprState node / tree). I believe it potentially
contains the execution tree to determine the state / value of the aggref
(sub)expression. But then in the ExecEvalAggref function I do not see the
args coming into picture at all! I am also unable to find a call to some
function for executing the state node created in the args list. Also, no
value is being extracted from that node! Why is it so?
For quick reference I am adding the function (may be you don't need it
but still... its a small one):
/*
*ExecEvalAggref
*
*Returns a Datum whose value is the value of the precomputed
*aggregate found in the given expression context.
*
*/
static Datum
ExecEvalAggref(AggrefExprState *aggref, ExprContext *econtext,
bool *isNull, ExprDoneCond *isDone)
{
if (isDone)
*isDone = ExprSingleResult;
if (econtext-ecxt_aggvalues == NULL)/* safety check */
elog(ERROR, no aggregates in this expression context);
*isNull = econtext-ecxt_aggnulls[aggref-aggno];
return econtext-ecxt_aggvalues[aggref-aggno];
}
What is the use of args in AggrefExprState node here? Is it there just
for some historical reason?
Regards,
Vaibhav
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
Re: [HACKERS] What would AggrefExprState nodes' args contain?
On 29.04.2011 13:19, Vaibhav Kaushal wrote: I have a small db which I am using to test it. Moreover I am new to the terms. What would you mean by 'regression'? make check -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Predicate locking
Vlad Arkhipov wrote: But even if it would work it would not help me anyways. Because my constraint is much more complex and depends on other tables, I cannot express it in terms of exclusion constraints. Are you aware of the changes to the SERIALIZABLE transaction isolation level in the upcoming 9.1 release? http://wiki.postgresql.org/wiki/Serializable http://wiki.postgresql.org/wiki/SSI If you can wait for that, it might be just what you're looking for. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgresql on multi-core CPU's: is this old news?
On Apr 7, 2011, at 1:13 AM, Greg Smith wrote: On 04/05/2011 02:21 PM, Mischa Sandberg wrote: Came across the following in a paper from Oct 2010. Was wondering is this is old news I missed in this group. http://pdos.csail.mit.edu/papers/linux:osdi10.pdf about Linux optimization on multi-core CPU’s. Only a little old; http://postgresql.1045698.n5.nabble.com/MIT-benchmarks-pgsql-multicore-up-to-48-performance-td3173545.html shows most of the obvious comments to be made about it. There is more detail explaining why the hand-waving done in the paper about increasing NUM_LOCK_PARTITIONS is not a simple improvement at http://postgresql.1045698.n5.nabble.com/Lock-partitions-td1952557.html Given that when those tests were done 16 cores was a massive machine, it would probably be a good idea to run them again. If anyone is interested in doing that let me know; we have a 40 core machine that I could probably arrange access to. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Changing the continuation-line prompt in psql?
Over at http://archives.postgresql.org/pgsql-novice/2011-04/msg00102.php there's an interesting thread about a novice who forgot to put a semicolon at the end of his SQL commands, and what psql might do to be a little more friendly at the beginning of the learning curve. We see similar complaints every so often, so it seems like something that would be worth doing something about. Several ideas were mentioned, but the one that seemed to get the most approval was to make psql's PROMPT2 (the continuation line prompt) more visibly different from PROMPT1. I've got to agree that the difference between postgres= postgres- is on the subtle side. Two different possible changes were suggested: * Drop the database name from PROMPT2, so you see postgres= - * Change the continuation-line marker from - to +, so you see postgres= postgres+ We could do either or both of these. If we did both it'd look like postgres= + + seems like an obviously more mnemonic marker than - for additional lines, in addition to being more visually distinct. Dropping the DB name would change the length of the prompt, which even the most clueless noob ought to recognize as a cue about change of state, but maybe that would be too distracting for anyone past the noob stage. One possibly pleasant aspect of dropping the DB name is that it would only require a change in the default value of the PROMPT2 variable, so anyone who really hated it could undo it by setting a custom value for that. Changing the marker would require changing the behavior of the %R prompt escape sequence. (I suppose we could leave %R alone and invent a new escape that behaves just slightly differently, but that's probably carrying backwards compatibility too far.) Also, of course you can experiment with the effects of dropping the DB name by doing \set PROMPT2 '%R%# ' After doing a bit of experimentation myself, I think that changing the marker is a clear win but I'm less sure about dropping the DB name. I could probably get used to that after awhile, but it's a bit jarring for a longtime user. On the plus side, there's more screen space for the long command you're typing. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
On Fri, Apr 29, 2011 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote: Over at http://archives.postgresql.org/pgsql-novice/2011-04/msg00102.php there's an interesting thread about a novice who forgot to put a semicolon at the end of his SQL commands, and what psql might do to be a little more friendly at the beginning of the learning curve. We see similar complaints every so often, so it seems like something that would be worth doing something about. Several ideas were mentioned, but the one that seemed to get the most approval was to make psql's PROMPT2 (the continuation line prompt) more visibly different from PROMPT1. I've got to agree that the difference between postgres= postgres- is on the subtle side. Two different possible changes were suggested: * Drop the database name from PROMPT2, so you see postgres= - Definite -1 on that option - your query no longer lines up, and if you then for example open it in an editor, indentation changes. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] stored procedures - use cases?
On Apr 26, 2011, at 6:08 PM, Kevin Grittner wrote: Josh Berkus j...@agliodbs.com wrote: -- doing a backfill operation for 10GB of computed data, taking 8 hours, where I don't want to hold a transaction open for 8 hours since this is a high-volume OLTP database. Been there, done that. Definitely not a rare use case. We do that so often we've actually written a framework around it and are working on a daemon that will deal with any backfills that have been registered in the system. If we could control transactions that daemon could be entirely in the database... but since we can't, we have to write it in another language outside the database and switch back and forth between the two worlds. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] branching for 9.2devel
All, +1 from me for keeping it as-is as well. So it sounds like most committers want to keep the CFs on their existing schedule for another year. Also that we don't want to branch until RC1. While it would be nice to get some feedback from those who had bad experiences with the CF cycle, I don't know how to get it ... and the complaints I've received from submitters are NOT about the CF cycle. What it sounds like we do have consensus on, though, is: a) improving pg_indent so that it can be run portably, easily, and repeatably b) greatly improving the so you want to submit a patch documentation c) making CFs a little shorter (3 weeks instead of 4?) I'll also add one of my own: developing some kind of dependable mentoring system for first-time patch submitters. Beyond that, are we ready to set the schedule for 9.2 yet? I'd tend to say that: CF1: July 1-30 CF2: Sept 1-21 CF3: November 1-21 CF4: January 3-31 Realistically, given that we usually seem to still be hacking in March, we could have a 5th CF which would be exclusively for patches already reviewed in CF4 and tiny patches. *however*, we've historically been extremely poor in enforcing gatekeeping rules on what's accepted to a CF, so I'm not sure that's a good idea. Oh, and just so Robert will get off my back, I volunteer to run the 9.2CF1. Since I'm a better administrator than a reviewer. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
Magnus Hagander mag...@hagander.net writes: On Fri, Apr 29, 2011 at 17:09, Tom Lane t...@sss.pgh.pa.us wrote: ... Two different possible changes were suggested: * Drop the database name from PROMPT2, so you see postgres= - Definite -1 on that option - your query no longer lines up, and if you then for example open it in an editor, indentation changes. Yeah, there is that. I just went over to see what the competition does here, and it looks like this: mysql select 2 - +2 - + 'foo ' bar ' baz' - quoted identifier - /* /* comment */ - ; AFAICT the initial prompt is always mysql , so they don't have to think hard about how many spaces to insert to make it line up. But we could certainly invent a prompt escape that means as many spaces as there are characters in the current DB name. (Or maybe we should try to generalize that idea, so you could get similar behavior for custom prompts involving usernames etc?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
On Apr 29, 2011, at 8:22 AM, Tom Lane wrote: AFAICT the initial prompt is always mysql , so they don't have to think hard about how many spaces to insert to make it line up. But we could certainly invent a prompt escape that means as many spaces as there are characters in the current DB name. (Or maybe we should try to generalize that idea, so you could get similar behavior for custom prompts involving usernames etc?) +1 I like this idea, so the prompt might by default be postgres= + Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011: On Apr 29, 2011, at 8:22 AM, Tom Lane wrote: AFAICT the initial prompt is always mysql , so they don't have to think hard about how many spaces to insert to make it line up. But we could certainly invent a prompt escape that means as many spaces as there are characters in the current DB name. (Or maybe we should try to generalize that idea, so you could get similar behavior for custom prompts involving usernames etc?) +1 I like this idea, so the prompt might by default be postgres= + That was my immediate thought after seeing Magnus' response too. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
On Fri, Apr 29, 2011 at 12:17 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011: On Apr 29, 2011, at 8:22 AM, Tom Lane wrote: AFAICT the initial prompt is always mysql , so they don't have to think hard about how many spaces to insert to make it line up. But we could certainly invent a prompt escape that means as many spaces as there are characters in the current DB name. (Or maybe we should try to generalize that idea, so you could get similar behavior for custom prompts involving usernames etc?) +1 I like this idea, so the prompt might by default be postgres= + That's certainly a reasonable sort of start. It seems like pretty serious bikeshedding to try to come up with an operator to express do as many of character X as the length of variable $FOO. I know people have been hacking on zsh and Bash to do wacky things like that - I somewhat doubt that we really want to go too far down that road. (I'd be about equally excited about integrating an APL into psql. Of course, I'm watching https://github.com/kevinlawler/kona, which is an ASCII-ized APL clone, so that mightn't be the thing I'd MOST vigorously argue against ;-).) The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. I'm not totally appalled at the thought of subsequent lines not being perfectly aligned with the first one - frequently, the first line of a multiline query is differently indented or has different proper policy (e.g. - CREATE OR REPLACE FUNCTION *can* safely differ from the body of the function). I think I could readily live with PROMPT2= +, all in all. -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #5998: CLUSTER and ERROR: missing chunk number 0 for toast value
Mark Reid m...@markreid.org writes:
This morning I noticed that a normally small table (18 wide rows) was
bloated to 6GB in size. This has happened before using older postgres
versions in the past, where the main table got vacuumed, but the pg_toastXX
table did not. This is the first time I've seen a problem for this version
of postgres (8.3.5). So I decided to manually vacuum the table to find out
what was going on. I saw a lot of dead row versions cannot be removed
yet. (on the order of 60k in the main table, and 3.8M in the toast table).
There was a day-old idle in transaction query for that same user, so I
killed that and tried again. Same deal. So I tried a CLUSTER
properties_pkey ON properties; which gave the following error message:
ERROR: missing chunk number 0 for toast value 396950697 in
pg_toast_373928870
[ and closing an old open transaction made the error go away ]
Andres concluded The bug is that CLUSTER seems to use the wrong xid horizon
when determining visibility, Or autovacuum. Not sure
No, I don't think so. I've been able to replicate the failure with this
sequence, in the presence of an old open transaction:
regression=# create table foo (f1 serial primary key, f2 text);
NOTICE: CREATE TABLE will create implicit sequence foo_f1_seq for serial
column foo.f1
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index foo_pkey for
table foo
CREATE TABLE
regression=# insert into foo(f2) select repeat('xyzzyklflencxlkslnvlzsm;pemc',
1);
INSERT 0 1
regression=# begin;
BEGIN
regression=# update foo set f2 = f2 || 'z';
UPDATE 1
regression=# update foo set f2 = f2 || 'z';
UPDATE 1
regression=# update foo set f2 = f2 || 'z';
UPDATE 1
regression=# commit;
COMMIT
regression=# vacuum foo;
VACUUM
regression=# cluster foo using foo_pkey;
ERROR: missing chunk number 0 for toast value 41347 in pg_toast_41336
The problem is that CLUSTER is trying to copy a tuple that it believes
to be RECENTLY_DEAD, but that is in fact DEAD (ie, inaccessible to every
open transaction). The preceding VACUUM did not remove the tuple, but
it did remove the underlying TOAST data, which means that CLUSTER fails
when trying to copy the tuple's toast data to the new table. The error
goes away once OldestXmin advances enough to let the problem tuple be
seen as DEAD.
So, how is it that the vacuum removed the underlying toast data but not
the putatively-recently-dead tuple? The problem tuple is in the middle
of the update chain that I created with those updates, and the
difficulty arises from the following bit in HeapTupleSatisfiesVacuum:
/*
* Deleter committed, but check special cases.
*/
if (TransactionIdEquals(HeapTupleHeaderGetXmin(tuple),
HeapTupleHeaderGetXmax(tuple)))
{
/*
* Inserter also deleted it, so it was never visible to anyone else.
* However, we can only remove it early if it's not an updated tuple;
* else its parent tuple is linking to it via t_ctid, and this tuple
* mustn't go away before the parent does.
*/
if (!(tuple-t_infomask HEAP_UPDATED))
return HEAPTUPLE_DEAD;
}
if (!TransactionIdPrecedes(HeapTupleHeaderGetXmax(tuple), OldestXmin))
{
/* deleting xact is too recent, tuple could still be visible */
return HEAPTUPLE_RECENTLY_DEAD;
}
/* Otherwise, it's dead and removable */
return HEAPTUPLE_DEAD;
Those middle-of-the-chain tuples have xmin=xmax, and so do their
supporting toast tuples. Problem is the toast tuples aren't updated,
they are independent tuples so far as the toast table is concerned.
Therefore, the toast tuples are reported as DEAD regardless of
OldestXmin, but their parent tuples escape the first test and can be
reported RECENTLY_DEAD. This allows the toast tuples to be removed
ahead of their parent tuple, and then you've got trouble waiting to
happen.
This issue clearly is problematic for CLUSTER (as well as VACUUM FULL
in 9.0+). I wonder whether it might explain some of the heretofore
unexplainable reports of missing chunk number 0 errors in other
operations. You'd have to suppose that those other commands were
being run with stale snapshots, so it's not super credible, but ...
I'm inclined to think that the xmin=xmax test is just too cute and
should be dropped altogether, ie removing the first if-block quoted
above would fix the problem. Anyone see a better answer?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
* Christopher Browne (cbbro...@gmail.com) wrote: It seems like pretty serious bikeshedding to try to come up with an operator to express do as many of character X as the length of variable $FOO. How about pad with spaces to line up prompt, or such? In general, I like the idea of having spaces there instead of the db name. The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. Uhm.. With the above, perhaps --%Z+, which would generate: postgres= -- + etc. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Changing the continuation-line prompt in psql?
Christopher Browne cbbro...@gmail.com writes: Excerpts from David E. Wheeler's message of vie abr 29 13:04:35 -0300 2011: +1 I like this idea, so the prompt might by default be postgres= + That's certainly a reasonable sort of start. It seems like pretty serious bikeshedding to try to come up with an operator to express do as many of character X as the length of variable $FOO. The idea that I was considering was to define the prompt sequence % X to mean as many spaces as %X would produce characters, for any X. The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. Well, you can do that today, whenever you need it, by modifying the values of PROMPT1 and PROMPT2. The loss-of-screen-space issue makes me think it'd not be very reasonable to make it the default. I'm not totally appalled at the thought of subsequent lines not being perfectly aligned with the first one - frequently, the first line of a multiline query is differently indented or has different proper policy (e.g. - CREATE OR REPLACE FUNCTION *can* safely differ from the body of the function). It wasn't bothering me either initially, but the argument about the command looking different when you suck it into an editor with \e has some credibility. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne cbbro...@gmail.com wrote: The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. I would second this precise interest. It really annoys me more often than anything else that when I try to copy/paste an sql query I need to copy each line one by one. It would be different from MySql but I think it would be even clearer to the user: postgres= select 1, /*line 2:*/2, /*line 3:*/3; ?column? | ?column? | ?column? --+--+-- 1 |2 |3 (1 row) -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
* Stephen Frost (sfr...@snowman.net) wrote: Uhm.. With the above, perhaps --%Z+, which would generate: postgres= -- + yah, obviously not going to work. :) However, it wouldn't be impossible to have psql recognize and strip --spaces+ if/when it's seen starting a new line, if we set it up such that it's always the same.. Could be optional anyway, perhaps configurable as a regexp. Anyhow, just some thoughts. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Changing the continuation-line prompt in psql?
Greg Stark gsst...@mit.edu writes: On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne cbbro...@gmail.com wrote: The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. I would second this precise interest. It really annoys me more often than anything else that when I try to copy/paste an sql query I need to copy each line one by one. It would be different from MySql but I think it would be even clearer to the user: postgres= select 1, /*line 2:*/2, /*line 3:*/3; This looks promising until you stop to think about either string literals or /* comment blocks being continued across lines ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
2011/4/29 Greg Stark gsst...@mit.edu: On Fri, Apr 29, 2011 at 5:45 PM, Christopher Browne cbbro...@gmail.com wrote: The bike shedding that I'd rather have would involve enclosing prompts with /* comments */ so that cut'n'paste could be expected to generate output that could run, without further editing, in another psql session. Mind you, whenever I have configured such, I have been unhappy at how wide that makes the prompt and at the loss of screen space. I would second this precise interest. It really annoys me more often than anything else that when I try to copy/paste an sql query I need to copy each line one by one. It would be different from MySql but I think it would be even clearer to the user: postgres= select 1, /*line 2:*/ 2, /*line 3:*/ 3; ?column? | ?column? | ?column? --+--+-- 1 | 2 | 3 (1 row) +1 Pavel -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
On Fri, Apr 29, 2011 at 02:10:19PM -0400, Stephen Frost wrote: * Stephen Frost (sfr...@snowman.net) wrote: Uhm.. With the above, perhaps --%Z+, which would generate: postgres= -- + yah, obviously not going to work. :) However, it wouldn't be impossible to have psql recognize and strip --spaces+ if/when it's seen starting a new line, if we set it up such that it's always the same.. Could be optional anyway, perhaps configurable as a regexp. Anyhow, just some thoughts. Thanks, Stephen +1 to have psql strip a configurable beginning of line sequence. Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Extreme bloating of intarray GiST indexes
Tom Lane t...@sss.pgh.pa.us writes: Uh, no, the picksplit bugs we fixed were in cube and seg --- there's no reason to think that updating will help this. But 8.4's pgstattuple does appear to support gist indexes, so please run that and see what you get. There's also gevel that I used to inspect in development GiST index, and I found it pretty useful. Don't know yet how it compares to pgstattuple. http://www.sai.msu.su/~megera/wiki/Gevel Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] EXPLAIN Node Docs?
Hackers, Is there any place where the contents of EXPLAIN nodes are documented? I'm making a lot of use of the XML format right now to figure out what queries sort on what tables and with what columns, but I've had to do a lot of experimentation to figure out what each type of node contains. For example, today I wanted to know what columns were being used in GROUP BY expressions. I poked around our client's sample queries till I found one with a GROUP BY expression and EXPLAINed it. It turns out that the Group node doesn't talk about columns, but has a Sort subplan node that does. On reflection, this makes sense, and so I just collected data for all Sort nodes (it wasn't just GROUP BY sorting I needed) got get my results. But it would have been a lot easier if the schema for various nodes was documented. I'd like to be able to just look up the documentation for various nodes to see what elements they contain and what subnodes they might have. Would make it a lot easier. Does such a thing exist? On a related note, how difficult would it be to add a list of column names to nodes with Filter elements? Right now I'm extracting column names by calling regexp_matches() against the filter element, which is kind of brute force. As an exmple, right now I have Plan + Node-TypeIndex Scan/Node-Type + Parent-RelationshipOuter/Parent-Relationship + Scan-DirectionForward/Scan-Direction + Index-Nameidx_stuff/Index-Name+ Relation-Nameactivities/Relation-Name + Aliasa/Alias + Startup-Cost0.00/Startup-Cost + Total-Cost27.97/Total-Cost + Plan-Rows1/Plan-Rows + Plan-Width36/Plan-Width + Index-Cond(person_id = 78323)/Index-Cond + Filter(((SubPlan 1) gt; 0) OR (category_id lt;gt; 15))/Filter + Would be nice if there was an additional element with something like Columnscategory_id/Columns Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] stored procedures
On Fri, Apr 22, 2011 at 1:28 PM, Peter Eisentraut pete...@gmx.net wrote: On fre, 2011-04-22 at 08:37 -0500, Merlin Moncure wrote: It wouldn't bother me in the lest that if in plpgsql procedures if you had to set up and tear down a transaction on every line. It would probably be more reasonable and feasible to have a setup where you can end a transaction in plpgsql but a new one would start right away. I've been poking around to see how this might be done, and yes there are a lot of issue. The good news is that at least, from what I can tell so far, that there are relatively few problems inside plpgsql itself in terms of making it span transactions (there is a small assumption with the simple eval code but that can probably easily fixed). The problems are further up in that plpgsql relies on various structures that are tucked into the transaction memory context. The very first thing that I think has to be figured out to implement supertransactional behaviors is under which memory context the various structures plpgsql depends on will live, especially the execution state. I'm thinking it should rely in the message context, with some participation at the portal level, possibly via a new routine (PortalRunProcedure) that is special in that it has to communicate to plpgsql that it is a procedure and what to do when doing transactional management. For example, it is currently managing the ExecutorQueryDesc and should probably continue doing so. One way to do this is to inject a callback somewhere (in the queryDesc?) which could be accessible at the lower levels (ideally even in SPI if we want to be able to get to this from other PLs). The callback implementation would kill the snapshot, reset the transaction etc. Most other transaction management is not happening here, but in postgres.c, so I'm not sure if this is the right place. I'd also like to defer the snapshot creation as long as possible after flushing the current transaction so that it's possible to sneak a lock into the procedure body to deal with serialization problems. If that can't be worked out, maybe a textual implementation or something based on autonomous approach is better. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
Tom Lane t...@sss.pgh.pa.us writes: It wasn't bothering me either initially, but the argument about the command looking different when you suck it into an editor with \e has some credibility. It still do not bother me the least, I much prefer PROMPT2 to be +. With emacs you use M-d then a rectangular cut (C-x r k runs the command kill-rectangle), as any user of it might know. I don't suppose it's that more a problem with other people editors of choice, or certainly they would switch. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Changing the continuation-line prompt in psql?
Excerpts from Dimitri Fontaine's message of vie abr 29 16:37:37 -0300 2011: Tom Lane t...@sss.pgh.pa.us writes: It wasn't bothering me either initially, but the argument about the command looking different when you suck it into an editor with \e has some credibility. It still do not bother me the least, I much prefer PROMPT2 to be +. With emacs you use M-d then a rectangular cut (C-x r k runs the command kill-rectangle), as any user of it might know. I don't suppose it's that more a problem with other people editors of choice, or certainly they would switch. Not a problem in Vim either, just use a visual block (Ctrl-V). With the leading spaces to line up, a rectangular region works great; if there's no lineup, you have to cut the first line separately which is a bit annoying. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] What would AggrefExprState nodes' args contain?
Thanks heikki. @ashu: i am in final year undergrad at bangalore under vtu. I know the term regression. Just did not know how to do that. Heikki reminded me skmething i tried out while compiling binutils...make check. Will look into that. Thanks for the help so far both of you. :) On 29 Apr 2011 16:24, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 29.04.2011 13:19, Vaibhav Kaushal wrote: I have a small db which I am using to test it. Moreover I am new to the terms. What would you mean by 'regression'? make check -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] EXPLAIN Node Docs?
David E. Wheeler da...@kineticode.com writes: Is there any place where the contents of EXPLAIN nodes are documented? Use the source, Luke ... In particular, src/include/nodes/plannodes.h is pretty well commented. If it's not immediately obvious how that maps to what's shown by EXPLAIN, look into commands/explain.c. (There are things that aren't mentioned by EXPLAIN even in verbose mode, such as which columns Group is going to group by; usually that's because it's redundant with info available elsewhere, such as the sort columns of a lower sort node.) Keep in mind also that we reserve the right to whack these things around in arbitrary ways from one release to the next. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] branching for 9.2devel
On Apr 29, 2011, at 5:19 PM, Joshua Berkus j...@agliodbs.com wrote: Beyond that, are we ready to set the schedule for 9.2 yet? I'd tend to say that: CF1: July 1-30 CF2: Sept 1-21 CF3: November 1-21 CF4: January 3-31 Tom and I were talking about starting maybe June 1, rather than July 1. You seem opposed but I'm not sure why. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] SIREAD lock versus ACCESS EXCLUSIVE lock
Kevin Grittner kevin.gritt...@wicourts.gov wrote: This'll take some study. I've gone through the list of commands in the development docs with an eye toward exposing anything else we might have missed in dealing with the SSI predicate locking. Some of this needs further research, but I'm posting what I have so far so that people have a chance to argue about what I think needs doing or to point out anything else they can think of which I'm still missing. And, of course, so people know where we are with it. I tested file_fdw at the serializable isolation level and found that no predicate locks were taken and no problems showed up. I think that's all correct -- I don't see how we can expect to include FDW data in serializability. I haven't dug into ALTER INDEX enough to know whether it can ever cause an index to be rebuilt. If so, we need to treat it like DROP INDEX and REINDEX -- which should change all predicate locks of any granularity on the index into relation locks on the associated table. CLUSTER or an ALTER TABLE which causes a rewrite should change all predicate locks on the table and all indexes into relation locks on the associated table. (Obviously, an existing relation lock on the table doesn't require any action.) TRUNCATE TABLE and DROP TABLE should generate a rw-conflict *in* to the enclosing transaction (if it is serializable) from all transactions holding predicate locks on the table or its indexes. Note that this could cause a transactions which is running one of these statements to roll back with a serialization error. This seems correct to me, since these operations essentially delete all rows. If you don't want the potential rollback, these operations should be run at another isolation level. The difference between these two statements is that I think that TRUNCATE TABLE should also move the existing predicate locks to relation locks on the table while DROP TABLE (for obvious reasons) should just delete the predicate locks. DROP DATABASE should quietly clean up any predicate locks from committed transactions which haven't yet hit their cleanup point because of overlapping transactions in other databases. DROP OWNED or DROP SCHEMA could CASCADE to some of the above, in which case the above rules would apply. I need to do some testing with Large Objects to see what state those are in with SSI, unless someone else has already looked at that. SAVEPOINTs have been considered and there is a lot of coding to try to handle them correctly, but they probably merit a bit more attention and testing. On some quick testing everything seemed to be in line with previous discussions and with what seems logical to me, but our SSI regression tests in src/test/isolation lack any coverage for them and I don't know how much others have beat up on them. At a minimum we should add a couple tests. I couldn't find anything else which hadn't already been considered and covered. More to come as I finish investigating. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EXPLAIN Node Docs?
On Apr 29, 2011, at 2:07 PM, Tom Lane wrote: In particular, src/include/nodes/plannodes.h is pretty well commented. Ah, that's a useful file to scan, thanks. If it's not immediately obvious how that maps to what's shown by EXPLAIN, look into commands/explain.c. Yeah, that's the file I have been reading. (There are things that aren't mentioned by EXPLAIN even in verbose mode, such as which columns Group is going to group by; usually that's because it's redundant with info available elsewhere, such as the sort columns of a lower sort node.) Right, I figured that one out. Same does not appear to be true of Filter elements, though. Keep in mind also that we reserve the right to whack these things around in arbitrary ways from one release to the next. Yeah, though I assume you mean major releases, not maintenance releases. Still, it'd be nice to have a documentation reference. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SYSTEM_IDENTIFY fields was:(Re: [COMMITTERS] pgsql: Include more status information in walsender results)
On Thu, Feb 3, 2011 at 7:56 AM, Magnus Hagander mag...@hagander.net wrote: Include more status information in walsender results Add the current xlog insert location to the response of IDENTIFY_SYSTEM why was this third field added to SYSTEM_IDENTIFY? can't find any place where it's used... not even on BaseBackup() before the call to SYSTEM_IDENTIFY was removed -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Sync Rep v19
Bruce Momjian wrote: Simon Riggs wrote: On Wed, 2011-03-09 at 21:21 -0500, Bruce Momjian wrote: Simon Riggs wrote: On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote: postgres=# SELECT application_name, state, sync_priority, sync_state FROM pg_stat_replication; application_name | state | sync_priority | sync_state --+---+---+ one | STREAMING | 1 | POTENTIAL two | streaming | 2 | sync (2 rows) Bug! Thanks. Is there a reason these status are all upper-case? NOT AS FAR AS I KNOW. I'll add it to the list of changes for beta. The attached patch lowercases the labels displayed in the view above. (The example above was originally all upper-case.) Applied. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Predicate locking
29.04.2011 21:18, Kevin Grittner wrote: Vlad Arkhipov wrote: But even if it would work it would not help me anyways. Because my constraint is much more complex and depends on other tables, I cannot express it in terms of exclusion constraints. Are you aware of the changes to the SERIALIZABLE transaction isolation level in the upcoming 9.1 release? http://wiki.postgresql.org/wiki/Serializable http://wiki.postgresql.org/wiki/SSI If you can wait for that, it might be just what you're looking for. -Kevin I would not like to make the whole transaction serializable because of performance and concurrency reasons. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
