On Fri, 2011-01-07 at 12:32 +0100, t...@fuzzy.cz wrote:
the problem is you will eventually need to drop the results and rebuild
it, as the algorithms do not handle deletes (ok, Florian mentioned an
algorithm L_0 described in one of the papers, but I'm not sure we can
use
it).
Yes, but even
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/7 Magnus Hagander mag...@hagander.net:
On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/5 Magnus Hagander mag...@hagander.net:
On Wed, Jan 5, 2011 at
On Sun, Jan 9, 2011 at 15:53, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to my
patch for streaming base backups - they now show up in
pg_stat_replication, with a streaming
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
In going back through old emails to see what issues might have
been raised but not yet addressed for the SSI patch, I found the
subject issue described in a review by Jeff Davis here:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to my
patch for streaming base backups -
On Mon, Jan 10, 2011 at 08:49:12AM -0600, Kevin Grittner wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
In going back through old emails to see what issues might have
been raised but not yet addressed for the SSI patch, I found the
subject issue described in a review by Jeff
David Fetter da...@fetter.org wrote:
Could people fix it after the patch? ISTM that a great way to
test it is to make very sure it's available ASAP to a wide range
of people via the next alpha (or beta, if that's where we're going
next).
People can always pull from the git repo:
On Mon, Jan 10, 2011 at 08:59:45AM -0600, Kevin Grittner wrote:
David Fetter da...@fetter.org wrote:
Could people fix it after the patch? ISTM that a great way to
test it is to make very sure it's available ASAP to a wide range
of people via the next alpha (or beta, if that's where we're
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
or we could hack eqsel() to bound the no-stats estimate to a bit less
than 1.
This seems like a pretty sensible thing to do. I can't immediately
imagine a situation in which 1.0 is a
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggssi...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
One thing I noticed is that it gives an interesting property to
On Mon, 2011-01-10 at 17:05 +0200, Heikki Linnakangas wrote:
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon Riggssi...@2ndquadrant.com wrote:
On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
Em 10-01-2011 12:05, Heikki Linnakangas escreveu:
So how does a walsender that's waiting for a command from the client
show up? Surely it's not in catchup mode yet?
It is kind of initializing catchup. I think it is not worth representing
those short lifespan states (in normal scenarios).
--
On Mon, Jan 10, 2011 at 16:41, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2011-01-10 at 17:05 +0200, Heikki Linnakangas wrote:
On 10.01.2011 16:49, Simon Riggs wrote:
On Mon, 2011-01-10 at 15:20 +0100, Magnus Hagander wrote:
On Sun, Jan 9, 2011 at 15:53, Simon
On 23/12/10 15:40, Jan Urbański wrote:
Here's a patch implementing custom Python exceptions for SPI errors
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the explicit-subxacts patch sent eariler.
I changed that patch to use
Attached is a rebased roll-up of the 3 and 3a patches from last month.
-Kevin
--- a/src/backend/commands/variable.c
+++ b/src/backend/commands/variable.c
@@ -544,29 +544,72 @@ show_log_timezone(void)
/*
+ * SET TRANSACTION READ ONLY and SET TRANSACTION READ WRITE
+ *
+ * These should be
The attached, applied patch removes toast relid from the relation array
as it is no longer needed. Also other remaming was done.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything
Hi. I try to compile postgres with mingw32. When configure runs, it
tells that found perl 5.6 which is too old. I install perl 5.10 from
activestate but configure cant find it. How to set up path to newer
perl?
--
Sent from my mobile device
pasman
--
Sent via pgsql-hackers
To All,
I am attempting to setup a server to use SSPI for mapping operating system
users/groups to various postgres roles. In process I found that everything is
driven off of the username in the mapping with no group but the mapping file
supports regular expressions to do some mapping.
As
On 01/10/2011 11:51 AM, pasman pasmański wrote:
Hi. I try to compile postgres with mingw32. When configure runs, it
tells that found perl 5.6 which is too old. I install perl 5.10 from
activestate but configure cant find it. How to set up path to newer
perl?
Assuming you installed into the
On Mon, Jan 10, 2011 at 10:03:18AM -0600, Kevin Grittner wrote:
Due to popular request (Hey, David's popular, right?),
Well, I'm a person, and popular originally refers to something like
that ;)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
In going back through old emails to see what issues might have
been raised but not yet addressed for the SSI patch, I found the
subject issue described in a review by Jeff Davis here:
On Mon, Jan 10, 2011 at 16:48, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 10-01-2011 12:05, Heikki Linnakangas escreveu:
So how does a walsender that's waiting for a command from the client
show up? Surely it's not in catchup mode yet?
It is kind of initializing catchup. I think
On 1/10/11 7:25 AM, Tom Lane wrote:
I'm a bit worried though that there might be other
cases where the estimator comes up with 1.0 selectivity but it'd still
be worth considering a bitmap scan.
Well, I think the answer is to apply the other fixes, and test. If
there are other cases of
On 1/9/11 5:27 PM, Robert Haas wrote:
I agree. I think we should assume that existing code which asks for
serializable behavior wants serializable behavior, not broken
serializable behavior. There certainly could be cases where the
opposite is true (the code wants, specifically, our
Josh Berkus j...@agliodbs.com wrote:
many such applications would be written with workarounds for
broken serializable behavior, workarounds which would behave
unpredictably after an upgrade.
Can you elaborate?
The techniques we use in our shop wouldn't interact badly with SSI,
and I'm
On 1/10/11 10:28 AM, Kevin Grittner wrote:
The techniques we use in our shop wouldn't interact badly with SSI,
and I'm having trouble picturing what would. Sure, some of these
techniques would no longer be needed, and would only add overhead if
SSI was there.
Yeah? Well, you have more
Josh Berkus j...@agliodbs.com wrote:
my clients have tended to use SELECT FOR UPDATE instead of
SERIALIZABLE.
If they're not using SERIALIZABLE, this patch will have no impact on
them at all. If they are using SELECT FOR UPDATE *with*
SERIALIZABLE, everything will function exactly as it is
2011/1/10 Magnus Hagander mag...@hagander.net:
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/7 Magnus Hagander mag...@hagander.net:
On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/5 Magnus
On 1/10/11 10:47 AM, Kevin Grittner wrote:
If they're not using SERIALIZABLE, this patch will have no impact on
them at all. If they are using SELECT FOR UPDATE *with*
SERIALIZABLE, everything will function exactly as it is except that
there may be some serialization failures which they
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Joel Jacobson discovered a bug in the function pg_describe_object where
it does not produce unique identifiers for some entries in pg_amproc.
This patch fixes the bug where when two entries in
Attached is an updated version of Heikki's patch to use a parser for
the walsender commands, instead of parsing things manually. It also
does some minor refactoring in walsender.c to break out
IdentifySystem() and StartReplication() to their own functions to make
it more readable.
While having an
2011/1/10 Andreas Karlsson andr...@proxel.se:
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Many thanks for fixing the bug!
I also implemented the pg_describe_object in pure SQL, for those of us
who have not yet switched to PostgreSQL 9
Magnus Hagander mag...@hagander.net writes:
Attached is an updated version of Heikki's patch to use a parser for
the walsender commands, instead of parsing things manually. It also
does some minor refactoring in walsender.c to break out
IdentifySystem() and StartReplication() to their own
On 01/10/2011 08:13 PM, Cédric Villemain wrote:
2011/1/10 Magnus Hagandermag...@hagander.net:
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/7 Magnus Hagandermag...@hagander.net:
On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
Tom Lane t...@sss.pgh.pa.us wrote:
I think we've learned over the years that GUCs that significantly
change semantics can be foot-guns. I'm not sure exactly how
dangerous this one would be
I didn't respond to this at first because the idea seemed DOA, but
with Josh's concerns I guess I
On Fri, 2011-01-07 at 12:32 +0100, t...@fuzzy.cz wrote:
the problem is you will eventually need to drop the results and rebuild
it, as the algorithms do not handle deletes (ok, Florian mentioned an
algorithm L_0 described in one of the papers, but I'm not sure we can use
it).
Yes, but even
Andreas Karlsson andr...@proxel.se writes:
Here is the bug-fix patch again with a description of the context so I
can add it to the commit fest.
Joel Jacobson discovered a bug in the function pg_describe_object where
it does not produce unique identifiers for some entries in pg_amproc.
There
Here's a patch that adds a few PL/Python functions for quoting strings.
It's an incremental patch on top of the plpython-refactor patch sent in
http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/functions
2011/1/10 Tom Lane t...@sss.pgh.pa.us:
There was never any intention that that code produce a guaranteed-unique
identifier; it's only meant to be a humanly useful identifer, and this
patch seems to me to mostly add noise.
For all objects, except for these pg_amproc regclass, the function
does
I wrote:
The proposed GUC would suppress the monitoring in SERIALIZABLE
mode and avoid the new serialization failures, thereby providing
legacy behavior -- anomalies and all.
After posting that I realized that there's no technical reason that
such a GUC couldn't be set within each session
When a function is created, the system validates the syntax and
complains if any function the created function attempts to call is
missing.
I think this is really good, since it traps typos and warns you if you
have forgotten to install any functions your function depends on.
It would be equally
/tts_isnull
arrays.
Regards,
--
Shigeru Hanada
20110110-ResetCopyFrom.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10.1.2011 17:20, Jan Urbański wrote:
On 23/12/10 15:40, Jan Urbański wrote:
Here's a patch implementing custom Python exceptions for SPI errors
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the explicit-subxacts patch sent
2011/1/10 Stefan Kaltenbrunner ste...@kaltenbrunner.cc:
On 01/10/2011 08:13 PM, Cédric Villemain wrote:
2011/1/10 Magnus Hagandermag...@hagander.net:
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/7 Magnus Hagandermag...@hagander.net:
On
There was never any intention that that code produce a guaranteed-unique
identifier; it's only meant to be a humanly useful identifer, and this
patch seems to me to mostly add noise.
Would making the identifier unique do any *harm*?
--
-- Josh Berkus
Shigeru HANADA han...@metrosystems.co.jp writes:
For the purpose of file_fdw, additional ResetCopyFrom() would be
necessary. I'm planning to include such changes in file_fdw patch.
Please find attached partial patch for ResetCopyFrom(). Is there
anything else which should be done at reset?
Hannu Krosing ha...@2ndquadrant.com writes:
On 10.1.2011 17:20, Jan UrbaÅski wrote:
I changed that patch to use Perl instead of sed to generate the
exceptions, which should be a more portable.
Why not python ?
Because we're not adding even more different tool requirements to the
build
2011/1/10 Magnus Hagander mag...@hagander.net:
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/7 Magnus Hagander mag...@hagander.net:
On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/1/5 Magnus
On Mon, 2011-01-10 at 11:29 -0800, Josh Berkus wrote:
On 1/10/11 10:47 AM, Kevin Grittner wrote:
If they're not using SERIALIZABLE, this patch will have no impact on
them at all. If they are using SELECT FOR UPDATE *with*
SERIALIZABLE, everything will function exactly as it is except that
If we must have a GUC, perhaps we could publish a sunset one release in
the future.
I was thinking default to false/off in 9.1, and disappear in 9.3.
Really, the biggest risk of such a GUC is the confusion factor when
supporting people. If we're told that the transactions involved in
some
Josh Berkus j...@agliodbs.com writes:
There was never any intention that that code produce a guaranteed-unique
identifier; it's only meant to be a humanly useful identifer, and this
patch seems to me to mostly add noise.
Would making the identifier unique do any *harm*?
It would make
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus j...@agliodbs.com wrote:
I'm going to disagree here. For a large, sprawling, legacy application
changing SERIALIZABLE to REPEATABLE READ in every place in the code
which might call it can be prohibitively difficult.
What makes you think that would
Josh Berkus j...@agliodbs.com writes:
How is this different from our other backwards-compatibility GUCs?
Mainly, that it's not clear we need it. Nobody's pointed to a concrete
failure mechanism that makes it necessary for an existing app to run
under fake-SERIALIZABLE mode.
Josh Berkus j...@agliodbs.com writes:
On 1/10/11 7:25 AM, Tom Lane wrote:
I'm a bit worried though that there might be other
cases where the estimator comes up with 1.0 selectivity but it'd still
be worth considering a bitmap scan.
Well, I think the answer is to apply the other fixes, and
Josh Berkus wrote:
Really, the biggest risk of such a GUC is the confusion factor
when supporting people.
How is this different from our other backwards-compatibility GUCs?
I thought Tom might be concerned about such a GUC destabilizing
things in other ways. I just wanted to make clear
On Mon, Jan 10, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
or we could hack eqsel() to bound the no-stats estimate to a bit less
than 1.
This seems like a pretty sensible
On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we need a status enum. ('BACKUP', 'CATCHUP', 'STREAM') for the 3
phases of replication.
That seems reasonable. But if we keep BACKUP in there, should we
really have it called pg_stat_replication? (yeah, I
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 10, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm currently
leaning to the idea of tweaking the logic in indxpath.c; in particular,
why wouldn't it be a good idea to force consideration of the bitmap path
if the index type
Mainly, that it's not clear we need it. Nobody's pointed to a concrete
failure mechanism that makes it necessary for an existing app to run
under fake-SERIALIZABLE mode.
I think it's quite possible that you're right, and nobody depends on
current SERIALIZABLE behavior because it's
On Sat, Jan 08, 2011 at 10:20:22PM -0600, Kevin Grittner wrote:
One thing that would help a lot besides code review is performance
testing. I did some months ago and I know Dan booked time on MIT
benchmarking systems and got good numbers, but with the refactoring
it would be good to redo
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It would make dependency error messages significantly longer and less
readable. Quite aside from the point at hand here, we elide schema
names in many cases (and it looks like there are some code paths where
It was reported from a tester that we don't have casts of money from/to integer
types even though we have from/to numeric type.
http://archives.postgresql.org/pgsql-testers/2011-01/msg0.php
Did we have any discussions about the behavior?
I think we should have them for consistency.
Robert Haas robertmh...@gmail.com writes:
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
My point is that this isn't a bug fix, it's more like moving the
goalposts on what getObjectDescription is supposed to do.
I think that adding the types to the description string is a
Itagaki Takahiro itagaki.takah...@gmail.com writes:
It was reported from a tester that we don't have casts of money from/to
integer
types even though we have from/to numeric type.
In most locales, the idea isn't sensible.
regards, tom lane
--
Sent via pgsql-hackers
On Tue, Jan 11, 2011 at 11:10, Tom Lane t...@sss.pgh.pa.us wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
It was reported from a tester that we don't have casts of money from/to
integer
types even though we have from/to numeric type.
In most locales, the idea isn't sensible.
I wrote:
Last time we did stress tests, it uncovered some race conditions.
Those were fixed at the time, and hopefully we haven't introduced
any new ones; but it's a Very Good Thing that Dan is able to run
some more DBT-2 tests, even if that test isn't ideal for
highlighting SERIALIZABLE
2011/1/11 Robert Haas robertmh...@gmail.com:
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus j...@agliodbs.com wrote:
I'm going to disagree here. For a large, sprawling, legacy application
changing SERIALIZABLE to REPEATABLE READ in every place in the code
which might call it can be prohibitively
On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii is...@postgresql.org wrote:
While looking at the backend code, I realized that error code for
terminating connection due to conflict with recovery is
ERRCODE_ADMIN_SHUTDOWN.
I thought the error code is for somewhat a human interruption, such as
Tried asking this in pgsql-general but I got no response, so I thought
I'd give hackers a shot:
postgres=# select (((1.7976931348623157081e+308)::double
precision)::text)::double precision;
ERROR: 1.79769313486232e+308 is out of range for type double precision
I'm working on a pg driver and in
2011/1/11 Tom Lane t...@sss.pgh.pa.us:
It would make dependency error messages significantly longer and less
readable. Quite aside from the point at hand here, we elide schema
names in many cases (and it looks like there are some code paths where
getObjectDescription never bothers to print
70 matches
Mail list logo
