On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
Good:
It's easy to see SQL objects (\df) of extensions (think contribs) you
installed, and as extension developpers are required to use it, you
don't have to care about
On Tuesday 26 May 2009 17:44:59 Magnus Hagander wrote:
Hmm. I looked through the source of the import script. It appears to
mention tags here and there, but doesn't seem to do it.
Which is part of the reason we use this script and not one of the other ones,
because some of our tags are broken.
On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
It appears for this workload using a 16KB or 32KB gets more than 4%
throughput improvement, but some of that could be noise.
The baseline appears to have a significant jump in txn response time
after 77 mins on the baseline test. I think you
Hi,
David E. Wheeler da...@kineticode.com writes:
On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
Proposal: pg_extension, a new dedicated system schema for extensions
I like this, although I'd want to be able, as a user, to override that
default and tell an extension to install in some
On Tue, 2009-05-26 at 11:06 +0900, Fujii Masao wrote:
Yes. Since walsender is treated as special backend, we can use
pg_terminate_backend() to terminate replication and let the server
standalone. This feature is simple but very useful, so I'll address it
(my previous patch has not provided
On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote:
Patch for plpythonu
Primary motivation of the attached patch is to support handling bytea
conversion allowing for embedded nulls, which in turn allows for supporting
the marshal module.
Secondary motivation is slightly improved
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken
Please keep in mind that the amount of brokenness here depends a lot
on the tool used for the conversion to git.
Hi,
Quoting Peter Eisentraut pete...@gmx.net:
.. some of our tags are broken. Any conversion will either have to drop
or repair some tags; see my previous posts to hackers about this.
Can you please point me to that post? I didn't find it.
In what way do you consider the tags broken? (As
Hello, postgresmen.
I found solution how to implement keep alive through sockets in
archive: http://archives.postgresql.org/pgsql-interfaces/2006-11/msg00014.php
However, it is dated 2006 year and I am wonder if this is for real? At
least in Windows environment?
If not are there any solutions?
Markus Wanner wrote:
Hi,
Quoting Aidan Van Dyk ai...@highrise.ca:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken
Please keep in mind that the amount of brokenness here depends a lot
on the tool used for
On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed for the
matching rows but the rows will
Greg Stark wrote:
On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed for the
matching rows
Magnus Hagander wrote:
Markus Wanner wrote:
Quoting Aidan Van Dyk ai...@highrise.ca:
This has been raised and ignored many times before on -hackers... The
reason is because the tags in the CVS repository are broken
Please keep in mind that the amount of brokenness here depends a lot
on the
On Tue, 26 May 2009, Robert Haas wrote:
I'm not totally keen on pulling the subject lines. I know that's what
we've mostly been doing, but sometimes the subject line is something
like patch to improve the way that foo does bar, rather than make
bar use baz algorithm or (even worse) patch to
Hi,
Quoting Magnus Hagander mag...@hagander.net:
No, we use fromcvs, not git cvsimport.
Oh, thanks for the correction.
I haven't heard of fromcvs before, but solely judging by lines of
code, it's hardly as elaborate as cvs2svn. So my arguments hold true
for it as well.
IIRC that was
On Wed, May 27, 2009 at 1:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
The big plus of the current technique is that it is so convenient to
Ctrl+C something which is running too long, arrow up, hit Home, and
put the EXPLAIN word in front. Turning the query into a character
string
Hello
this small patch replace redundant plpgsql_dstring functionality.
regards
Pavel Stehule
*** ./src/pl/plpgsql/src/gram.y.orig 2009-05-27 12:56:10.0 +0200
--- ./src/pl/plpgsql/src/gram.y 2009-05-27 13:59:37.0 +0200
***
*** 17,22
--- 17,23
#include
On Wednesday 27 May 2009 13:25:14 Markus Wanner wrote:
Hi,
Quoting Peter Eisentraut pete...@gmx.net:
.. some of our tags are broken. Any conversion will either have to drop
or repair some tags; see my previous posts to hackers about this.
Can you please point me to that post? I didn't
Hi,
On Wed, May 27, 2009 at 3:27 PM, Kolb, Harald (NSN - DE/Munich)
harald.k...@nsn.com wrote:
In our use case it's important to have a short failover time.
So everything what keeps the time low, would be good to have.
Yes. I think that it's a matter of priority.
We already made some
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I tried throwing various kinds of subtle garbage into the errmsg/ngettext
line, but it was all discovered by gcc -Wall.
I experimented with this and found that indeed both format strings are
checked ... if you have a reasonably
Pavel Golub wrote:
Hello, postgresmen.
I found solution how to implement keep alive through sockets in
archive: http://archives.postgresql.org/pgsql-interfaces/2006-11/msg00014.php
However, it is dated 2006 year and I am wonder if this is for real?
setsockopt has been around since at least
On Wednesday 27 May 2009 00:54:52 Marc G. Fournier wrote:
So, you are suggesting:
cvs -q tag -d REL7_1_BETA2 .
cvs -q tag -d REL7_1_BETA3 .
Note that there are actually two different issues related to tags:
One is, the tags REL7_1_BETA2 and REL7_1_BETA3 cannot be parsed by cvsps. But
no
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many
Why on earth would there be a dip precisely at 8k with both smaller
and larger block sizes being faster??
--
Greg
On 27 May 2009, at 03:51, Mark Wong mark...@gmail.com wrote:
Hi all,
A long long time ago (in 2004) I ran a series of tests surveying the
results of changing BLCKSZ when it
Greg Stark st...@enterprisedb.com wrote:
http://article.gmane.org/gmane.comp.db.postgresql.devel.patches/21614/match=siginfo
It let you hit a control character while the query was running to
view
the explain analyze for the results so far. The query kept running
and
you could request
On Wednesday 27 May 2009 05:51:05 Mark Wong wrote:
BS notpm % Change from default
-- - --
1 14673 -4.8%
2 15864 2.9%
4 15774 2.3%
8 15413 (default)
16 16118 4.6%
32 16051 4.1%
64 14874 -3.5%
This means that both somewhat larger and somewhat smaller than 8 give better
Greg Stark st...@enterprisedb.com writes:
On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed
On Wed, 2009-05-27 at 21:28 +0900, Fujii Masao wrote:
Hi,
On Wed, May 27, 2009 at 3:27 PM, Kolb, Harald (NSN - DE/Munich)
harald.k...@nsn.com wrote:
In our use case it's important to have a short failover time.
So everything what keeps the time low, would be good to have.
Yes. I think
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without
extending
the interface between the backend and
* Markus Wanner mar...@bluegap.ch [090527 06:20]:
Has anybody ever tried using cvs2git? Being based on cvs2svn, it should
yield better results than cvsps. It's even recommended from the issues
section of the git-cvsimport man page [1]. And git-cvsimport seems to be
able to continue from an
* Marc G. Fournier scra...@hub.org [090526 18:00]:
Specifically, it's 2 tags, and I just remove them:
REL7_1_BETA2
REL7_1_BETA3
So, you are suggesting:
cvs -q tag -d REL7_1_BETA2 .
cvs -q tag -d REL7_1_BETA3 .
correct?
Not directly, I claim *no* knowledge of the safety of any CVS
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I don't think we're going to get this to work reliably without
extending
the interface
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [090527 07:29]:
OTOH, there's some value in staying with current GIT repository. In
EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
repository that's based on the PostgreSQL mirror. If PostgreSQL switches
to
Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
I think the big frustration is that this issue was first brought up
March 25 and it took two months to resolve it, at which point we were in
beta. I think many hoped a better
On Wed, 2009-05-27 at 09:51 -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:13 -0400, Bruce Momjian wrote:
I think the big frustration is that this issue was first brought up
March 25 and it took two months to resolve it, at
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [090527 07:29]:
OTOH, there's some value in staying with current GIT repository. In
EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
repository that's based on the PostgreSQL mirror. If
Hi,
On Wed, May 27, 2009 at 10:49 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-05-27 at 21:28 +0900, Fujii Masao wrote:
Hi,
On Wed, May 27, 2009 at 3:27 PM, Kolb, Harald (NSN - DE/Munich)
harald.k...@nsn.com wrote:
In our use case it's important to have a short failover time.
Robert Haas robertmh...@gmail.com wrote:
I noticed in Bruce's talk that there are a number of post-migration
steps which are currently partially manual. Ideally we'd like to
automate them all, preferably in some sort of well-thought-out
order.
I actually suspect this is something like:
Hi,
Peter Eisentraut wrote:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg01879.php
Thanks for the link. I'm assuming you've adjusted the tags to fit a
single commit.
Out of curiosity: do you think (or have evidence that) this is the only
tag that spans multiple commits?
In what
On Wed, May 27, 2009 at 11:44 AM, Markus Wanner mar...@bluegap.ch wrote:
Peter Eisentraut wrote:
In what way do you consider the tags broken?
The tag applies to different commits on different files.
That's perfectly valid for CVS (and can be represented in subversion as
well). Such a tag
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
Well, we knew there was an issue but we didn't finalize our conclusions
and address it as best we could
On Wed, 2009-05-27 at 12:08 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2009-05-27 at 09:48 -0400, Bruce Momjian wrote:
We are not going to improve unless we face our faults.
True. Who or what is at fault, in your opinion?
Well, we knew there was an issue but we
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement. I can't think of an occasion when this
has happened on any matter of significance, and I can remember many
times when Tom, Bruce and others
On May 23, 2009, at 9:51 PM, Robert Haas wrote:
vacuums everything. ISTM it'd be useful to be able to just vacuum all
databases in a cluster, so I hacked it into vacuumdb.
I think you meant ISTM it'd be useful to be able to just analyze all
databases in a cluster.
Heh. Oops.
Of course,
On May 27, 2009, at 1:50 AM, Dimitri Fontaine wrote:
The moment you're adding specific schemas where to put extensions
into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid
having
those people to care
On Wed, May 27, 2009 at 1:14 PM, Andrew Dunstan and...@dunslane.net wrote:
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement. I can't think of an occasion when this has
happened on any matter of
On Wed, 2009-05-27 at 13:14 -0400, Andrew Dunstan wrote:
Simon Riggs wrote:
My experience is that consensus/votes will be overruled by final
committer, if they disagree,
That's a fairly strong statement.
I was attempting to be open and honest to allow us to face our faults,
as
On Wed, 2009-05-27 at 17:39 +0300, Heikki Linnakangas wrote:
I agree we could've should've handled this more promptly, and I'll take
my part of the blame for that. I let the various proposed patches sit
for long times before reviewing them thoroughly, partly because I was
busy and partly
I wrote:
Greg Stark st...@enterprisedb.com wrote:
This thread has really been one of those cases where everyone
thought they were having a different kind of discussion.
Apparently so.
In light of discussions at PGCon, I'm going to abandon this thread in
favor of a discussion of what
On Wed, 2009-05-27 at 13:34 -0500, Kevin Grittner wrote:
For the record, it became clear that I did a bad job of communicating
on this thread...
You did good work, IMHO. Not everything will reach consensus and that's
not your fault.
first implement table level predicate
locks, since that
All data types should map to the same python object types as they did before,
so int32-PyInt, int64-PyLong, numeric-PyFloat, etc.
The conversion routines are slightly different, eg int32 is initialized via
PyInt_FromLong() instead of first converting the integer to a string then
calling
Simon Riggs si...@2ndquadrant.com wrote:
Do we need table-level predicate locks at all? What would they give
us? Why not just go straight for fine-grained page-level locks?
I don't want to get too far into implementation discussions at this
phase (see Tom's slides ;-)), but suffice it to
On Monday 25 May 2009 17:52:07 Zdenek Kotala wrote:
Peter Eisentraut píše v ne 24. 05. 2009 v 00:40 +0300:
I think this is not the best way to do it, because it will confuse
pgindent and editors and such. The DATA() macros in include/catalog have
this solved; see include/catalog/genbki.sh.
Peter Eisentraut píše v út 26. 05. 2009 v 13:39 +0300:
Of course the concrete example that you show doesn't actually take advantage
of this, so if it is important to you, please send a patch to fix it.
Fix attached. I found only two problems, both in psql. I did not fix .po
files. Is
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
The problem here is (1 row) instead of (%lu row). When I run msgfmt
without -v everything works fine but I think we should fixed it (there
are more occurrences of this issue).
I don't think we can find all these occurrences without the
On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I tried throwing various kinds of subtle garbage into the errmsg/ngettext
line, but it was all discovered by gcc -Wall.
I experimented with this and found that indeed both format strings are
checked
I want to try to get agreement that it would be a good idea to
implement serializable transactions, and what that would look like
from the user side. At this point, we should avoid discussions of
whether it's possible or how it would be implemented, but focus on
what that would look like and
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
I experimented with this and found that indeed both format strings are
checked ... if you have a reasonably recent libintl.h AND you have
specified --enable-nls. Otherwise it all goes to heck, apparently
David == David E Wheeler da...@kineticode.com writes:
The moment you're adding specific schemas where to put extensions
into, you have to adapt your search_path. Some applications
already have to manage search_path for their own needs, so we're
trying to avoid having those people to care
On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
Previously numeric-string-PyFloat_FromString, now
numeric-double-PyFloat_FromDouble, which makes use of postgres
numeric-double routines rather than python string-double routines, and it
is conceivable that there are precision variations
Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection parameters in order to select which
Andrew Gierth and...@tao11.riddles.org.uk writes:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
Here is output of:
for FILE in `find . -name *.po`;do LC_ALL=C msgfmt -v -o /dev/null $FILE
2 msgfmt.txt; done
Zdenek
Peter Eisentraut píše v st 27. 05. 2009 v 23:08 +0300:
On Monday 25 May 2009 19:11:24 Zdenek Kotala wrote:
The problem here is (1 row) instead of (%lu row). When I
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 27 May 2009 21:53:31 Caleb Welton wrote:
... My own
feeling on the matter is that PyFloat is the wrong mapping for numeric, but
I didn't want to muddy this patch by changing that.
Yeah, that one had me wondering for a while as well, but
On Monday 25 May 2009 00:55:17 Tom Lane wrote:
2. In tsearch.sql, there are multiple places where the test is trying
to exercise some just-created index. This works as expected if the
tests are run serially, but the indexes are (usually) not used if the
tests are run in parallel. The reason
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement. Some folks on this
list might recognize the following coding
Robert Haas wrote:
Tom and Bruce do give way before a clear consensus, but on the other
hand I think Simon is right that there was never much chance of
getting anything committed here without Heikki's endorsement, which
was slow in coming by his own admission. (I'm not in any way saying
he
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [090527 07:29]:
OTOH, there's some value in staying with current GIT repository. In
EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT
repository that's based on the PostgreSQL mirror. If PostgreSQL switches
to
Josh Berkus j...@agliodbs.com writes:
Wait, I thought we'd given up on the search path model and wanted to
track extensions via dependencies. No?
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension
Yes, in Python = 2.4 there is the Decimal datatype.
However, unlike the other mappings employed by plpythonu, Decimal requires an
import statement to be in scope.
-Caleb
On 5/27/09 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On Wednesday 27 May 2009
All,
Wait, I thought we'd given up on the search path model and wanted to
track extensions via dependencies. No?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Apr 28, 2009 at 5:35 PM, Guillaume Smet
guillaume.s...@gmail.com wrote:
On Tue, Apr 28, 2009 at 5:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
At a normal startup, the checkpoint record would be there as usual. And an
archive recovery starts at the location
Greetings, Please help provide a chm file for 8.4b2. Unlike prior Windows
installations, the postgreSQL.chm is absent. This file format provides very
valuable searching capabilities.
Appreciatively! --LS
Larry Silvermintz, Ph.D.| Biologist Engineer
(510) 705-1432
--
Sent via
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 26 May 2009 21:05:29 Tom Lane wrote:
I experimented with this and found that indeed both format strings are
checked ... if you have a reasonably recent libintl.h AND you have
specified --enable-nls. Otherwise it all goes to heck, apparently
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:
Splitting up search_path is something I've been thinking about for a
while (and threw out on IRC as a suggestion, which is where Dimitri
got it); it was based on actual experience running an app that set the
search path in the connection
On Mon, May 25, 2009 at 11:16 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Hi,
Preliminary note: I'm using the term extension as if it's what we
already agree to call them, feel free to ignore this and use whatever
term you see fit. We'll have the naming issue tackled, please not now
On May 27, 2009, at 2:14 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
I was just about to raise that as a requirement.
Yeah, I likes.
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
Linux version 2.6.16.60-0.31-smp (ge...@buildhost) (gcc version 4.1.2
20070115 (SUSE Linux)) #1 SMP Tue Oct 7 16:16:29 UTC 2008
./configure --prefix=/usr/local/pgsql-8.4beta2
--enable-integer-datetimes --enable-debug
Joe Conway m...@joeconway.com writes:
The attached addresses items#2 and 3 as listed by Bruce here:
http://momjian.us/cgi-bin/pgsql/joe
I think it is consistent with the discussions we had a PGCon last week.
Any objections to me committing this for 8.4?
It's hard to review it without any
On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
(2) The standard requires this because it is the only cost-effective
way to ensure data integrity in some environments, particularly those
with a large number of programmers, tables, and queries; and which
have complex data integrity
Jeff Davis pg...@j-davis.com wrote:
On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
(C) One or more GUCs will be added to control whether the new
behavior is used when serializable transaction isolation is
requested or whether, for compatibility with older PostgreSQL
releases,
Tom,
I think what this discussion is about is trying to gauge just what
amount of support we could give someone who insisted on dropping each
extension into a different schema. It's not really related to how
we track which objects belong to which extension.
Really, they're on their own.
Josh Berkus j...@agliodbs.com writes:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
Well, we could certainly take that attitude and eliminate all this
hassle ;-).
On Wed, 2009-05-27 at 18:54 -0500, Kevin Grittner wrote:
I've gotten the distinct impression that some would prefer to continue
to use their existing techniques under snapshot isolation. I was sort
of assuming that they would want a GUC to default to legacy behavior
with a new setting for
Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Personally, if we're tracking stuff through special dependancies which
pg_dump will be aware of anyway, I don't see why extension objects
should go into a special schema.
Well, we could certainly take that attitude and eliminate
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-05-27 at 18:54 -0500, Kevin Grittner wrote:
I've gotten the distinct impression that some would prefer to continue
to use their existing techniques under snapshot isolation. I was sort
of assuming that they would want a GUC to default to
On Wed, May 27, 2009 at 7:54 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Jeff Davis pg...@j-davis.com wrote:
On Wed, 2009-05-27 at 15:34 -0500, Kevin Grittner wrote:
(C) One or more GUCs will be added to control whether the new
behavior is used when serializable transaction
Jeff Davis pg...@j-davis.com wrote:
1. implementation of the paper's technique sans predicate locking,
that would avoid more serialization anomalies but not all?
I saw that as a step along the way to support for fully serializable
transactions. If covered by a migration path GUC which
On Wed, May 27, 2009 at 1:46 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
It appears for this workload using a 16KB or 32KB gets more than 4%
throughput improvement, but some of that could be noise.
The baseline appears to have a
Jeff Davis pg...@j-davis.com writes:
On Wed, 2009-05-27 at 20:38 -0400, Tom Lane wrote:
* Anything else you want to control should be a GUC, as long as it
doesn't affect any correctness properties.
But that still leaves out another behavior which avoids some of the
serialization anomalies
On Wed, 2009-05-27 at 19:51 -0500, Kevin Grittner wrote:
Jeff Davis pg...@j-davis.com wrote:
1. implementation of the paper's technique sans predicate locking,
that would avoid more serialization anomalies but not all?
I saw that as a step along the way to support for fully
Robert Haas robertmh...@gmail.com wrote:
I think we should introduce a new value for SET TRANSACTION
ISOLATION
LEVEL, maybe SNAPSHOT, intermediate between READ COMMITTED and
SERIALIZABLE.
The standard defines such a level, and calls it REPEATABLE READ.
Snapshot semantics are more strict
Tom,
Well, we could certainly take that attitude and eliminate all this
hassle ;-). However, I think that more-flexible search path handling
might have other uses, so I don't see any reason not to think about it.
Sure. I think that having better search path management would be a
wonderful
Tom Lane t...@sss.pgh.pa.us wrote:
Hmm, what I gathered was that that's not changing any basic semantic
guarantees (and therefore is okay to control as a GUC). But I
haven't read the paper so maybe I'm missing something.
The paper never suggests attempting these techniques without a
Mark Wong mark...@gmail.com writes:
Oopsies. I've rerun, but now that there is no dip, the average
throughput still didn't change much:
BS notpm % Change from default
-- - --
1 14673 -5.1%
2 15864 2.7%
4 15774 2.1%
8 15454 (default)
16 16118 4.3%
32 16051 3.9%
64 14874
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, May 27, 2009 16:33:28 +0300 Peter Eisentraut
pete...@gmx.net
wrote:
On Wednesday 27 May 2009 00:54:52 Marc G. Fournier wrote:
So, you are suggesting:
cvs -q tag -d REL7_1_BETA2 .
cvs -q tag -d REL7_1_BETA3 .
Note that
On Wed, 2009-05-27 at 20:55 -0400, Tom Lane wrote:
Hmm, what I gathered was that that's not changing any basic semantic
guarantees (and therefore is okay to control as a GUC). But I haven't
read the paper so maybe I'm missing something.
On second read of this comment:
On Wed, 2009-05-27 at 20:38 -0400, Tom Lane wrote:
A lesson that I think we've learned the hard way over the past few years
is that GUCs are fine for controlling performance issues, but you expose
yourself to all sorts of risks if you make fundamental semantics vary
depending on a GUC.
I
1 - 100 of 124 matches
Mail list logo
