On Tue, Nov 15, 2011 at 8:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm not really enthused by the idea of completely rewriting lwlocks
for this. Seems like specialised code is likely to be best, as well as
having less collateral damage.
Well, the problem that I have with
On 2011-11-15 22:04, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Oh. I was thinking dead meant no longer visible to anyone. But
it sounds what we call unremovable here is what we elsewhere call
recently dead.
Would have to look at the code to be sure, but I think that
On Wed, Nov 16, 2011 at 1:17 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 15, 2011 at 7:18 PM, Jeff Janes jeff.ja...@gmail.com wrote:
When I apply this to HEAD and run make check, it freezes at:
test tablespace ...
[...]
Does anyone else see this?
It hangs for me,
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
What about adding that into src/tools/editors/pgsrc.el?
Should I add an item for that in the commit fest?
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Thom Brown t...@linux.com writes:
None of those others perform such a role. Instead they add additional
functionality intended to be utilised as part of general data usage,
adding new types, operators, query functions etc. Maybe the term
core is inappropriate. Instead we might wish to refer
Martijn van Oosterhout klep...@svana.org writes:
That said, I still don't see how you can enforce a unique index over
multiple segments over something other than the partition key while
still allowing quick dropping of segments. If you can fix that you can
make it work for the current
On Tue, Nov 15, 2011 at 5:50 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Thom Brown t...@linux.com writes:
None of those others perform such a role. Instead they add additional
functionality intended to be utilised as part of general data usage,
adding new types, operators, query
On Wed, Nov 16, 2011 at 3:31 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Apparently pg_stat* counts the recently_dead tuple under n_live_tup, else 2
is a wrong number, where pgstattuple counts recently_dead under
dead_tuple_count. This could be a source of confusion. If there is any
serious
On Tue, Nov 15, 2011 at 10:02 PM, Royce Ausburn royce...@inomial.com wrote:
Fair enough -- someone knowledgable could set that up if they wanted. My
goal was mostly to have something helpful in the logs. If that's not
something postgres wants/needs Ill drop it =)
IMHO, it's generally not
On Tue, Nov 15, 2011 at 5:41 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
What about adding that into src/tools/editors/pgsrc.el?
Should I add an item for that in the commit fest?
Sounds
On Tue, Nov 15, 2011 at 8:19 PM, Joshua Berkus j...@agliodbs.com wrote:
Here is a patch for that for pg_dump. The sections provided for are
pre-data, data and post-data, as discussed elsewhere. I still feel that
anything finer grained should be handled via pg_restore's --use-list
Robert Haas robertmh...@gmail.com writes:
Should I add an item for that in the commit fest?
Sounds like a good idea.
Done: https://commitfest.postgresql.org/action/patch_view?id=707
Note: I might also add support for equalfuncs and copyfuncs while at,
been doing that again and I guess I would
Robert Haas robertmh...@gmail.com writes:
The term “core” here intends to show off that those extensions are
maintained by the core PostgreSQL developer team. If needs be, those
extensions will get updated in minor releases (crash, bugs, security,
etc).
Everything in contrib meets that
On 16-11-2011 02:28, Greg Smith wrote:
By recent popular request in the ongoing discussion saga around merging the
recovery.conf, I've added an includeifexists directive to the
postgresql.conf in the attached patch.
I'm not following the merging recovery.conf thread but isn't it worth
On Tue, Nov 15, 2011 at 6:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
Patch adds cacheline padding around parts of XLogCtl.
Idea from way back, but never got performance tested in a situation
where WALInsertLock was the bottleneck.
So this is speculative, in need of testing to
Robert Haas robertmh...@gmail.com writes:
Not sure about the log line, but allowing pgstattuple to distinguish
between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though. pgstattuple's idea of
RecentGlobalXmin could even be significantly
Hello,
I'm new in postgreSQL programming. I try to print a tuple from
tupleTableSlot structure..
for example..
outerTupleSlot = ExecHashJoinOuterGetTuple(outerNode,
node,
hashvalue);
how to extract a tuple value?
there are any kind
Ants Aasma ants.aa...@eesti.ee wrote:
Concurrency 8 results should probably be ignored - variance was
huge, definitely more than the differences.
I'm not so sure it should be ignored -- one thing I noticed in
looking at the raw numbers from my benchmarks was that the -O2 code
was much more
Euler Taveira de Oliveira eu...@timbira.com writes:
On 16-11-2011 02:28, Greg Smith wrote:
By recent popular request in the ongoing discussion saga around merging the
recovery.conf, I've added an includeifexists directive to the
postgresql.conf in the attached patch.
I'm not following the
On tis, 2011-11-15 at 22:27 -0500, Tom Lane wrote:
Now, --clean using DROP IF EXISTS would be targeted at, um, what case?
I guess the idea is to be able to load into a database that sort of
mostly shares the same schema as the one you dumped from, only it's
not the same (if it were the same,
On 2011-11-16 15:34, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
Not sure about the log line, but allowing pgstattuple to distinguish
between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though. pgstattuple's idea of
On Wed, Nov 16, 2011 at 9:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Not sure about the log line, but allowing pgstattuple to distinguish
between recently-dead and quite-thoroughly-dead seems useful.
The dividing line is enormously unstable though.
Yeb Havinga yebhavi...@gmail.com writes:
On 2011-11-16 15:34, Tom Lane wrote:
The dividing line is enormously unstable though. pgstattuple's idea of
RecentGlobalXmin could even be significantly different from that of a
concurrently running VACUUM. I can see the point of having VACUUM log
On Wed, Nov 16, 2011 at 9:47 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
This suggests that in the long term, it might be worth investigating
whether we can arrange for a connection's process to have some
degree of core affinity and encourage each process to allocate local
memory
On Wed, Nov 16, 2011 at 12:28 AM, Greg Smith g...@2ndquadrant.com wrote:
By recent popular request in the ongoing discussion saga around merging the
recovery.conf, I've added an includeifexists directive to the
postgresql.conf in the attached patch.
I haven't read the code yet, but just to get
The November CommitFest is now closed for new entries. We have 30
patches in the queue that are still looking for a reviewer at this
point, out of a total of 53. If you'd like to review a patch but are
looking for a suggestion as to which to choose, e-mail the
pgsql-rrreviewers list saying
On Wed, Nov 16, 2011 at 9:20 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
The term “core” here intends to show off that those extensions are
maintained by the core PostgreSQL developer team. If needs be, those
extensions will get updated in minor
Simon Riggs si...@2ndquadrant.com wrote:
I just don't see the reason to do a global search and replace on
the lwlock name
I was going to review further before commenting on that, but since
it has now come up -- it seems odd that a source file which uses
only LW locks needs to change so much
On Wed, Nov 16, 2011 at 10:26 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
For example, if these two macros were defined, predicate.c wouldn't
have needed any modifications, and I suspect that is true of many
other files (although possibly needing a few other macros):
#define
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
I just don't see the reason to do a global search and replace on
the lwlock name
I was going to review further before commenting on that, but since
it has now come up -- it seems odd that a source
Robert Haas robertmh...@gmail.com writes:
Well, it would certainly be easy enough to add those macros, and I'm
not necessarily opposed to it, but I fear it could end up being a bit
confusing in the long run. If we adopt this infrastructure, then I
expect knowledge of different types of
On Wed, Nov 16, 2011 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, it would certainly be easy enough to add those macros, and I'm
not necessarily opposed to it, but I fear it could end up being a bit
confusing in the long run. If we adopt this
On Wed, Nov 16, 2011 at 3:41 PM, Robert Haas robertmh...@gmail.com wrote:
Now, you're always going to use
LWLockAcquire() and LWLockRelease() to acquire and release an LWLock,
but a FlexLockId isn't guaranteed to be an LWLockId - any given value
might also refer to a FlexLock of some other
Robert Haas robertmh...@gmail.com wrote:
Now maybe there is some better way to do this, but at the moment,
I'm not seeing it. If we call them all LWLocks, but only some of
them support LWLockAcquire(), then that's going to be pretty
weird.
Is there any way to typedef our way out of it,
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
This suggests that in the long term, it might be worth [...]
The other possibility is that the OS is smart enough about moving
things around to get good locality that sticking locality hints on
top
On Wed, Nov 16, 2011 at 11:14 AM, Greg Stark st...@mit.edu wrote:
On Wed, Nov 16, 2011 at 3:41 PM, Robert Haas robertmh...@gmail.com wrote:
Now, you're always going to use
LWLockAcquire() and LWLockRelease() to acquire and release an LWLock,
but a FlexLockId isn't guaranteed to be an LWLockId
On Wed, Nov 16, 2011 at 11:17 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
Now maybe there is some better way to do this, but at the moment,
I'm not seeing it. If we call them all LWLocks, but only some of
them support LWLockAcquire(), then
Why do these use anynonarray rather than anyelement? Given that we
support ranges of arrays (there's even a regression test), this seems
a bogus limitation.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Is there any way to typedef our way out of it [?]
Well, if we just say:
typedef FlexLockId LWLockId;
...that's about equivalent to the #define from the compiler's
point of view.
Bummer -- I
On 11/15/11 7:40 PM, Tom Lane wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
If we can't put isn out of its misery, a sensible compromise would be
to rip out the prefix enforcement feature so that, for example, ISBN13
behaved exactly the same as EAN13.
That might be a reasonable
On ons, 2011-11-09 at 20:14 +0100, Dimitri Fontaine wrote:
The task in $subject is something I will have to do repeatedly for
completing the Command Trigger patch. I've been doing some of them
manually, covering initdb. Then I've been scripting away the editing.
The script takes a Node
Peter Eisentraut pete...@gmx.net writes:
This is a massive amount of code that very few people in our community
will use, and very few be able to maintain it, too. If you want to make
a lasting contribution on this area, write a program that generates the
node handling functionality
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
PS Subscribing to psql-hack...@postgresql.org just spins for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Edward Muller edw...@heroku.com wrote:
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
If you want it to be seriously considered, you should post the patch
to this list, which makes it part of the permanent
On Wed, Nov 16, 2011 at 9:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 15, 2011 at 6:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
Patch adds cacheline padding around parts of XLogCtl.
Idea from way back, but never got performance tested in a situation
where WALInsertLock was
Consider the following query:
select (x).key as k, (x).value as v
from (select each(hstore(q)) as x
from (select oid, c.*
from pg_class c
where oid = 'parent'::regclass) q) t;
This gives results like this:
k | v
-+
f1 | 16410
f2 | parent
f3 |
On Tue, Nov 15, 2011 at 1:18 PM, Robert Treat r...@xzilla.net wrote:
On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith g...@2ndquadrant.com wrote:
On 11/15/2011 09:44 AM, Scott Mead wrote:
Fell off the map last week, here's v2 that:
* RUNNING = active
* all states from CAPS to lower case
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Edward Muller edw...@heroku.com wrote:
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
If you want it to be seriously considered,
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Edward Muller edw...@heroku.com wrote:
Looking for comments ...
https://gist.github.com/be937d3a7a5323c73b6e
We'd like to get this, or something like it, into 9.2
On Wed, Nov 16, 2011 at 12:06 PM, Kevin
I wrote:
Why do these use anynonarray rather than anyelement? Given that we
support ranges of arrays (there's even a regression test), this seems
a bogus limitation.
After experimenting with changing that, I see why you did it: some of
the regression tests fail, eg,
SELECT * FROM
The patch applies cleanly to the current git master and is in context diff format.The patch fails the regression tests because it is outputting new DETAIL line which four of tests aren't expecting. The tests will need to be updated.Functionality:The patch works as advertised. An insert or update
On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas robertmh...@gmail.com wrote:
Taking the median of those five results, the patch seems to have sped
things up by 0.3%. At 80 clients:
Thanks for doing that. Even if we fix it as you suggest it seems to
indicate that the WALInsertLock contention is
I noticed that and are not marked as commutator operators,
though a naive view of their semantics suggests they should be.
However, I realized that there might be edge cases I wasn't thinking
about, so I went looking in the patch to try to confirm this. And
I found neither a single line of
On 16 Nov 2011, at 04:53, Greg Smith wrote:
-Called by specifying includedir directory. No changes to the shipped
postgresql.conf yet.
-Takes an input directory name
Very useful idea.
What will happen if I specify:
includedir './'
Ie, what about potential cyclic dependency.
--
Sent
I wrote:
Simon Riggs si...@2ndquadrant.com writes:
We need a function called transactionid_current() so a normal user can write
select virtualtransaction
from pg_locks
where transactionid = transactionid_current()
and have it just work.
That would solve that one specific use-case. The
On Wed, November 16, 2011 6:45 pm, Greg Jaskiewicz wrote:
On 16 Nov 2011, at 04:53, Greg Smith wrote:
-Called by specifying includedir directory. No changes to the
shipped postgresql.conf yet.
-Takes an input directory name
Very useful idea.
What will happen if I specify:
includedir
Josh Berkus j...@agliodbs.com writes:
On 11/15/11 7:40 PM, Tom Lane wrote:
Peter Geoghegan pe...@2ndquadrant.com writes:
If we can't put isn out of its misery, a sensible compromise would be
to rip out the prefix enforcement feature so that, for example, ISBN13
behaved exactly the same as
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Peter Eisentraut pete...@gmx.net writes:
This is a massive amount of code that very few people in our community
will use, and very few be able to maintain it, too.
It's not that massive, at least not as it stands, although I agree it
looks
On Wed, Nov 16, 2011 at 5:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas robertmh...@gmail.com wrote:
Taking the median of those five results, the patch seems to have sped
things up by 0.3%. At 80 clients:
Thanks for doing that. Even if we fix it
Andrew Dunstan and...@dunslane.net writes:
On Wed, November 16, 2011 6:45 pm, Greg Jaskiewicz wrote:
What will happen if I specify:
includedir './'
I would vote for it only to handle plain files (possibly softlinked) in
the named directory.
I think Greg's point is that that would lead to
Andrew Dunstan and...@dunslane.net writes:
What I'm having difficulty understanding is why the limit clause should
make any difference.
Without the LIMIT, the query gets flattened to something like this:
Index Scan using pg_class_oid_index on pg_catalog.pg_class c
(cost=0.00..8.27 rows=1
(I'm a bit concerned about the angle that the code has some smarts
currently about where to put hyphens in output. If we rip that out
it could definitely break application code, whereas dropping a check
shouldn't.)
Right. Do we need to dump the hyphen logic?
--
Josh Berkus
PostgreSQL
On 17 November 2011 02:32, Josh Berkus j...@agliodbs.com wrote:
(I'm a bit concerned about the angle that the code has some smarts
currently about where to put hyphens in output. If we rip that out
it could definitely break application code, whereas dropping a check
shouldn't.)
Right. Do
I wrote:
and the issue seems to be that in execution of a RowExpr, the
executor doesn't pay any attention to preserving the column names
in the generated tupledesc --- see the ExecTypeFromExprList call
in execQual.c. ...
We could certainly make it do that --- it wouldn't even be terribly
I wrote:
PFC, a patch that does this.
Upon further review, this patch would need some more work even for the
RowExpr case, because there are several places that build RowExprs
without bothering to build a valid colnames list. It's clearly soluble
if anyone cares to put in the work, but I'm not
Peter Geoghegan pe...@2ndquadrant.com writes:
On 17 November 2011 02:32, Josh Berkus j...@agliodbs.com wrote:
Right. Do we need to dump the hyphen logic?
Only if you think that it's better to have something that covers many
cases but is basically broke. Perhaps it's different for code that
Robert Haas robertmh...@gmail.com writes:
(I wonder if we shouldn't just align every shared memory allocation to
64 or 128 bytes. It wouldn't waste much memory and it would make us
much more resistant to performance changes caused by minor
modifications to the shared memory layout.)
I could
On Tue, Nov 15, 2011 at 7:20 PM, Robert Haas robertmh...@gmail.com wrote:
The lower layer I called FlexLocks,
and it's designed to allow a variety of locking implementations to be
built on top of it and reuse as much of the basic infrastructure as I
could figure out how to make reusable
On Wed, Nov 16, 2011 at 11:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
(I wonder if we shouldn't just align every shared memory allocation to
64 or 128 bytes. It wouldn't waste much memory and it would make us
much more resistant to performance changes
Hi Gabriele,
On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
CREATE TABLE pt (
id INTEGER PRIMARY KEY,
...
);
CREATE TABLE ft (
id SERIAL PRIMARY KEY,
pids INTEGER[] REFERENCES pt,
...
);
This seems useful.
I'm assuming the SQL spec says nothing about a
On Wed, Nov 16, 2011 at 11:16 PM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Tue, Nov 15, 2011 at 7:20 PM, Robert Haas robertmh...@gmail.com wrote:
The lower layer I called FlexLocks,
and it's designed to allow a variety of locking implementations to be
built on top of it and reuse as
Hello
2011/11/17 Noah Misch n...@leadboat.com:
Hi Gabriele,
On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
CREATE TABLE pt (
id INTEGER PRIMARY KEY,
...
);
CREATE TABLE ft (
id SERIAL PRIMARY KEY,
pids INTEGER[] REFERENCES pt,
...
);
This seems
On Thu, Nov 17, 2011 at 10:01 AM, Robert Haas robertmh...@gmail.com wrote:
I am not convinced that that's a better API. I mean, consider
something like this:
/*
* OK, let's do it. First let other backends know I'm in ANALYZE.
*/
LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
On 11/16/11 7:54 PM, Tom Lane wrote:
Heck, we don't even have a field bug report that the design limitation
is causing any real problems for real users ... so IMO, the claims that
this is dangerously broken are a bit overblown.
This is why I mentioned clients using ISBN in production. I have
Noah Misch n...@leadboat.com writes:
On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
CREATE TABLE pt (
id INTEGER PRIMARY KEY,
CREATE TABLE ft (
id SERIAL PRIMARY KEY,
pids INTEGER[] REFERENCES pt,
I'm assuming the SQL spec says nothing about a feature like this?
I'm
BTW, has anyone thought through whether this is a sane idea at all?
It seems to me to be full of cases that will require rather arbitrary
decisions, like whether ON DELETE CASCADE should involve deleting the
whole row or just one array element.
One array element, presumably.
Does the patch
2011/11/17 Tom Lane t...@sss.pgh.pa.us:
Noah Misch n...@leadboat.com writes:
On Fri, Nov 04, 2011 at 01:48:02PM +0100, Gabriele Bartolini wrote:
CREATE TABLE pt (
id INTEGER PRIMARY KEY,
CREATE TABLE ft (
id SERIAL PRIMARY KEY,
pids INTEGER[] REFERENCES pt,
I'm assuming the SQL spec says
Folks,
BTW, I don't want to block this patch. However, it occurs to me that a
more generalized FK based on non-equality conditions (i.e. expressions)
would be nice if it were possible. Then we could have FKs from all
kinds of complex structures.
--
Josh Berkus
PostgreSQL Experts Inc.
On Wed, Nov 16, 2011 at 11:28 PM, Noah Misch n...@leadboat.com wrote:
Removing values from the array seems best to me. There's no doubt about what
ON UPDATE CASCADE should do, and having ON DELETE CASCADE excise individual
array elements is consistent with that. It's less clear for SET NULL,
Josh Berkus j...@agliodbs.com writes:
BTW, has anyone thought through whether this is a sane idea at all?
It seems to me to be full of cases that will require rather arbitrary
decisions, like whether ON DELETE CASCADE should involve deleting the
whole row or just one array element.
One array
80 matches
Mail list logo
