2011/1/11 Tom Lane :
> 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 them at all). An
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
> On Sat, Jan 8, 2011 at 9:52 AM, Tatsuo Ishii 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
>> shutdow
2011/1/11 Robert Haas :
> On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus 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 t
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 SERIALIZABL
On Tue, Jan 11, 2011 at 11:10, Tom Lane wrote:
> Itagaki Takahiro 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.
The documentation says:
| Input is acc
Itagaki Takahiro 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 mailing list (pgsql-hack
Robert Haas writes:
> On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane 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 pretty
> sensible thing to do.
N
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.
-
On Mon, Jan 10, 2011 at 7:52 PM, Tom Lane 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
> getObjectDescription never bothe
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 t
> 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 undepend
Robert Haas writes:
> On Mon, Jan 10, 2011 at 10:25 AM, Tom Lane 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 hasn't got amgettuple? If we don't,
On Mon, Jan 10, 2011 at 10:41 AM, Simon Riggs 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
On Mon, Jan 10, 2011 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane 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 s
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 cl
Josh Berkus 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 test. If
>
Josh Berkus 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.
regards, tom
On Mon, Jan 10, 2011 at 1:17 PM, Josh Berkus 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 be necessary? T
Josh Berkus 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 dependency error m
> 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
>
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
2011/1/10 Magnus Hagander :
> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
> wrote:
>> 2011/1/7 Magnus Hagander :
>>> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
>>> wrote:
2011/1/5 Magnus Hagander :
> On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine
> wrote:
>> Magnus Hagan
Hannu Krosing 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 process. Perl is wha
Shigeru HANADA 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?
Seems like it would be
> 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
2011/1/10 Stefan Kaltenbrunner :
> On 01/10/2011 08:13 PM, Cédric Villemain wrote:
>>
>> 2011/1/10 Magnus Hagander:
>>>
>>> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
>>> wrote:
2011/1/7 Magnus Hagander:
>
> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
> wrote:
>
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
this design, caller can receive results with tts_values/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
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 u
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
2011/1/10 Tom Lane :
> 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 already generate
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
The
Andreas Karlsson 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 was never any
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
Tom Lane 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 should answer this
On 01/10/2011 08:13 PM, Cédric Villemain wrote:
2011/1/10 Magnus Hagander:
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
wrote:
2011/1/7 Magnus Hagander:
On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
wrote:
2011/1/5 Magnus Hagander:
On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine wrote
Magnus Hagander 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 functions to make
>
2011/1/10 Andreas Karlsson :
> 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 in the production
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
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 pg
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 we
2011/1/10 Magnus Hagander :
> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
> wrote:
>> 2011/1/7 Magnus Hagander :
>>> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
>>> wrote:
2011/1/5 Magnus Hagander :
> On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine
> wrote:
>> Magnus Hagan
Josh Berkus 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 except that
ther
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 ex
Josh Berkus 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 having trouble pic
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 tradi
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 selec
On Mon, Jan 10, 2011 at 16:48, Euler Taveira de Oliveira
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
"Kevin Grittner" wrote:
> "Kevin Grittner" 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:
>>
>> http://archives.postgresql.org/pgsql-hack
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 http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo
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 u
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 detai
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 mailing
The attached, applied patch removes toast relid from the relation array
as it is no longer needed. Also other remaming was done.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
comm
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 tra
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 u
On Mon, Jan 10, 2011 at 16:41, Simon Riggs 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 Riggs wrote:
>> >>> On Sun, 2011-01-
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, 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 Riggs wrote:
> >>> On Sun, 2011-01-09 at 12:52 +0100, Magnus Hagander wrote:
> >>>
> On
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 Riggs 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
Robert Haas writes:
> On Sun, Jan 9, 2011 at 6:38 PM, Tom Lane 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 sensible selectivity estimate in
On Mon, Jan 10, 2011 at 08:59:45AM -0600, Kevin Grittner wrote:
> David Fetter 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
> > n
David Fetter 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:
git://git.postgresql
On Mon, Jan 10, 2011 at 08:49:12AM -0600, Kevin Grittner wrote:
> "Kevin Grittner" 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 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 sh
"Kevin Grittner" 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:
>
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01159.php
After re
On Sun, Jan 9, 2011 at 15:53, Simon Riggs 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 location of 0/0.
>
On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
wrote:
> 2011/1/7 Magnus Hagander :
>> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
>> wrote:
>>> 2011/1/5 Magnus Hagander :
On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine
wrote:
> Magnus Hagander writes:
>> * Stefan mentiond 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).
>
> Y
70 matches
Mail list logo
