Hello, thank you for taking the time for comment.
At Wed, 21 Dec 2011 11:09:59 -0500, Robert Haas wrote
> I find the names of the functions added here to be quite
> confusing and would suggest renaming them. I expected
> PQgetAsCstring to do something similar to PQgetvalue, but the
> code is com
Hello
2011/12/23 Tomas Vondra :
> Hi all,
>
> most of the time I use auto_explain, all I need is duration of the query
> and the plan with estimates and actual row counts. And it would be handy
> to be able to catch long running queries with estimates that are
> significantly off (say 100x lower o
> I don't think this is a given ... In fact, IMO if we're only two or
> three fixes away from having it all nice and consistent, I think
> reverting is not necessary.
>
>
FWIW, here's a quick fix for the issue that Robert pointed out. Again it's
a variation of the first issue that he reported. We
Excerpts from Nikhil Sontakke's message of vie dic 23 00:25:26 -0300 2011:
> Hi,
>
> > There is at least one other
> > problem. Consider:
> >
> > rhaas=# create table a (ff1 int, constraint chk check (ff1 > 0));
> > CREATE TABLE
> > rhaas=# create table b (ff1 int, constraint chk check (ff1 > 0)
And yeah, certainly there's a bug as you point out.
postgres=# create table a1 (ff1 int, constraint chk check (ff1 > 0));
postgres=# create table b1 (ff1 int);
postgres=# alter table only b1 add constraint chk check (ff1 > 0);
postgres=# alter table b1 inherit a1;
The last command should have ref
Hi,
> There is at least one other
> problem. Consider:
>
> rhaas=# create table a (ff1 int, constraint chk check (ff1 > 0));
> CREATE TABLE
> rhaas=# create table b (ff1 int, constraint chk check (ff1 > 0));
> CREATE TABLE
> rhaas=# alter table b inherit a;
> ALTER TABLE
>
> This needs to fail i
Hi all,
most of the time I use auto_explain, all I need is duration of the query
and the plan with estimates and actual row counts. And it would be handy
to be able to catch long running queries with estimates that are
significantly off (say 100x lower or higher compared to actual row numbers).
T
On Thu, Dec 22, 2011 at 3:19 PM, Robert Haas wrote:
> On Thu, Dec 22, 2011 at 2:02 PM, Phil Sorber wrote:
>> On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
>>> Robert Haas writes:
I'm wondering if we oughta just return NULL and be done with it.
>>>
>>> +1. There are multiple precedents
On 12/22/2011 06:11 PM, Andrew Dunstan wrote:
On 12/22/2011 02:17 PM, Andrew Dunstan wrote:
On 12/22/2011 01:05 PM, Tom Lane wrote:
Maybe, though I fear it might complicate the ruleutils code a bit.
You'd probably have to build the output for a column first and then
see how long it is bef
On 12/22/2011 02:17 PM, Andrew Dunstan wrote:
On 12/22/2011 01:05 PM, Tom Lane wrote:
Maybe, though I fear it might complicate the ruleutils code a bit.
You'd probably have to build the output for a column first and then
see how long it is before deciding whether to insert a newline.
In sho
Andrew Dunstan writes:
> On 12/22/2011 10:44 AM, Tom Lane wrote:
>> "Johann 'Myrkraverk' Oskarsson" writes:
>>> I mean to create a typed hstore, called tstore for now.
>> Um ... what is the point of this, exactly? From what I've seen,
>> most applications for hstore are pretty happy with the fac
Simon Riggs wrote:
> It could work that way, but I seriously doubt that a technique
> only mentioned in dispatches one month before the last CF is
> likely to become trustable code within one month. We've been
> discussing CRCs for years, so assembling the puzzle seems much
> easier, when all th
Peter Eisentraut writes:
> Are there any supported platforms that have only on_exit() but not
> atexit()?
Trolling the git logs shows that configure's support for on_exit was
added here:
commit df247b821d811abcfc0ac707e1a3af9dfce474c9
Author: Tatsuo Ishii
Date: Tue Feb
On Thu, Dec 22, 2011 at 9:50 AM, Kevin Grittner
wrote:
> Simon, does it sound like I understand your proposal?
Yes, thanks for restating.
> Now, on to the separate-but-related topic of double-write. That
> absolutely requires some form of checksum or CRC to detect torn
> pages, in order for th
On Mon, Dec 12, 2011 at 12:00 PM, Kohei KaiGai wrote:
> The "v8.option-2" add checks around examine_simple_variable, and
> prevent to reference statistical data, if Var node tries to reference
> relation with security-barrier attribute.
I adopted this approach, and committed this.
--
Robert Haa
On Tue, Dec 13, 2011 at 6:05 AM, Lionel Elie Mamane wrote:
> * On the one hand, it gives too much since LIBS is filtered to only a
> subset in src/interface/libpq/Makefile.
What is it excluding that it ought to include? I am not quite clear
on why that code is like that, but it appears to be
Are there any supported platforms that have only on_exit() but not
atexit()?
It would be good in some cases to rewrite custom arrangements such as
exit_nicely() or die_horribly() using those exit hooks, but supporting
both through ifdefs makes the code more ugly than before. I dug around
the buil
On Thu, Dec 22, 2011 at 3:04 PM, Robert Haas wrote:
> On Thu, Dec 22, 2011 at 1:50 PM, Jignesh Shah wrote:
>> In the double write implementation, every checkpoint write is double
>> writed,
>
> Unless I'm quite thoroughly confused, which is possible, the double
> write will need to happen the fir
On Thu, Dec 22, 2011 at 2:02 PM, Phil Sorber wrote:
> On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'm wondering if we oughta just return NULL and be done with it.
>>
>> +1. There are multiple precedents for that sort of response, which we
>> introduced exactly so
On Thu, Dec 22, 2011 at 1:50 PM, Jignesh Shah wrote:
> In the double write implementation, every checkpoint write is double
> writed,
Unless I'm quite thoroughly confused, which is possible, the double
write will need to happen the first time a buffer is written following
each checkpoint. Which
On Thu, Dec 22, 2011 at 2:43 PM, Alvaro Herrera
wrote:
> Excerpts from Nikhil Sontakke's message of mar dic 20 12:03:33 -0300 2011:
>
>> > Apologies, I did not check this particular scenario.
>> >
>> > I guess, here, we should not allow merging of the inherited constraint
>> > into an "only" const
Excerpts from Nikhil Sontakke's message of mar dic 20 12:03:33 -0300 2011:
> > Apologies, I did not check this particular scenario.
> >
> > I guess, here, we should not allow merging of the inherited constraint
> > into an "only" constraint. Because that breaks the semantics for "only"
> > constr
Excerpts from Robert Haas's message of jue dic 22 15:03:36 -0300 2011:
>
> On Mon, Dec 19, 2011 at 2:42 PM, Alvaro Herrera
> wrote:
> > Yeah, it is a pretty old bug -- this code was clearly written by some
> > rookie that didn't know very well what he was doing.
>
> Hey, I got that joke.
>
> I
On lör, 2011-11-26 at 01:28 +0200, Peter Eisentraut wrote:
> I propose that we change createuser so that it does not prompt for
> anything by default. We can arrange options so that you can get prompts
> for whatever is missing, but by default, a call to createuser should
> just run CREATE USER wi
On 12/22/2011 01:05 PM, Tom Lane wrote:
Robert Haas writes:
On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan wrote:
The simple solution I originally proposed to put a line feed and some space
before every target field in pretty print mode. This is a two line patch.
The downsides are a) maybe
On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> I'm wondering if we oughta just return NULL and be done with it.
>
> +1. There are multiple precedents for that sort of response, which we
> introduced exactly so that "SELECT some_function(oid) FROM some_catalog"
> wouldn
On Thu, Dec 22, 2011 at 11:16 AM, Kevin Grittner
wrote:
> Jignesh Shah wrote:
>
>> When we use Doublewrite with checksums, we can safely disable
>> full_page_write causing a HUGE reduction to the WAL traffic
>> without loss of reliatbility due to a write fault since there are
>> two writes always
Robert Haas writes:
> I'm wondering if we oughta just return NULL and be done with it.
+1. There are multiple precedents for that sort of response, which we
introduced exactly so that "SELECT some_function(oid) FROM some_catalog"
wouldn't fail just because one of the rows had gotten deleted by t
On Sat, Dec 17, 2011 at 3:52 PM, Phil Sorber wrote:
> Is SnapshotAny the snapshot I should be using? It seems to get the
> correct results. I can drop a table and I get NULL. Then after a
> vacuumdb it returns an error.
The suggestion on the original thread was to use SnapshotDirty or the
caller'
Robert Haas writes:
> On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan wrote:
>> The simple solution I originally proposed to put a line feed and some space
>> before every target field in pretty print mode. This is a two line patch.
>> The downsides are a) maybe not everyone will like the change
On Thu, Dec 22, 2011 at 12:52 PM, Andrew Dunstan wrote:
> I used to try to be conservative about vertical space, but in these days of
> scrollbars and screens not limited to 24 or 25 lines (Yes, kids, that's what
> some of us grew up with) that seems a bit old-fashioned. One of the
> arguments for
On Mon, Dec 19, 2011 at 2:42 PM, Alvaro Herrera
wrote:
> Yeah, it is a pretty old bug -- this code was clearly written by some
> rookie that didn't know very well what he was doing.
Hey, I got that joke.
I fixed this in master. I'm not going to bother with anything else
unless someone else feel
On 12/22/2011 12:52 PM, Andrew Dunstan wrote:
On 12/22/2011 12:18 PM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan
wrote:
The simple solution I originally proposed to put a line feed and
some space
before every target field in pretty print mode. This is a two line
pa
On Dec 22, 2011, at 7:48 AM, Oleg Bartunov wrote:
> we have pgfoundry project http://pgfoundry.org/projects/dbsamples/.
> Since your sample database is very important (for me also), I suggest to use
> this site.
Or PGXN.
http://pgxn.org/
You can register an account to upload extensions like y
On 12/22/2011 12:18 PM, Robert Haas wrote:
On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan wrote:
The simple solution I originally proposed to put a line feed and some space
before every target field in pretty print mode. This is a two line patch.
The downsides are a) maybe not everyone will
On Mon, Dec 19, 2011 at 1:51 PM, Andrew Dunstan wrote:
> The simple solution I originally proposed to put a line feed and some space
> before every target field in pretty print mode. This is a two line patch.
> The downsides are a) maybe not everyone will like the change and b) it will
> produce s
In bug #6351 it's pointed out that this fails unexpectedly:
CREATE TABLE tab (id SERIAL, a INTEGER, b INTEGER);
CREATE INDEX tab123 ON tab (a, b, a);
SELECT a, b FROM tab WHERE a = 0 AND b = 1;
ERROR: btree index keys must be ordered by attribute
I looked into this a bit and find that indxpath.c
* Joey Adams (joeyadams3.14...@gmail.com) wrote:
> This may be ambitious, but it'd be neat if PostgreSQL supported
> parameterizable types. For example, suppose a contrib module defines
> a "pair" type. It could be used as follows:
Have you looked at what the PostGIS folks are doing..? We do ha
On Thu, Dec 22, 2011 at 11:52 AM, Marti Raudsepp wrote:
> On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
>> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp wrote:
>>> PS: It seems that the min/max optimization isn't documented in the
>>> manual (apart from release notes), so I didn't include
On 12/22/2011 11:34 AM, Robert Haas wrote:
On Thu, Dec 22, 2011 at 1:04 AM, Joey Adams wrote:
What I'm wondering is: how complex would it be to add such a feature
to PostgreSQL's type system?
Very.
It's been discussed before, although I can't tell you the subject
lines of the threads off th
On Mon, Dec 19, 2011 at 1:02 PM, Simon Riggs wrote:
> On Dec 12, you said "It also strikes me that anything
> that is based on augmenting the walsender/walreceiver protocol leaves
> anyone who is using WAL shipping out in the cold. I'm not clear from
> the comments you or Simon have made how impo
On Thu, Dec 22, 2011 at 18:41, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp wrote:
>> PS: It seems that the min/max optimization isn't documented in the
>> manual (apart from release notes), so I didn't include any doc changes
>> in this patch.
>
> I don't see a patch atta
On Wed, Dec 21, 2011 at 5:04 AM, Pavel Stehule wrote:
> this patch adds a bytea_agg aggregation.
>
> It allow fast bytea concatetation.
Looks fine to me. I'll commit this, barring objections.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent v
On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut wrote:
> Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken
> because the module plpython.so was renamed to plpython2.so, and so the
> pg_upgrade check for loadable libraries fails thus:
>
> Your installation references loa
On Mon, Dec 19, 2011 at 5:16 AM, Marti Raudsepp wrote:
> PS: It seems that the min/max optimization isn't documented in the
> manual (apart from release notes), so I didn't include any doc changes
> in this patch.
I don't see a patch attached to this email, so either you forgot to
attach it, or t
On Thu, Dec 22, 2011 at 1:04 AM, Joey Adams wrote:
> What I'm wondering is: how complex would it be to add such a feature
> to PostgreSQL's type system?
Very.
It's been discussed before, although I can't tell you the subject
lines of the threads off the top of my head. The basic problem is
that
On 12/22/2011 10:44 AM, Tom Lane wrote:
"Johann 'Myrkraverk' Oskarsson" writes:
I mean to create a typed hstore, called tstore for now.
Um ... what is the point of this, exactly? From what I've seen, most
applications for hstore are pretty happy with the fact that hstore is
only weakly type
On Thu, Dec 22, 2011 at 1:04 AM, Simon Riggs wrote:
> I understand why you say that and take no offence. All I can say is
> last time I has access to a good test rig and well structured
> reporting and analysis I was able to see evidence of what I described
> to you here.
>
> I no longer have that
Jignesh Shah wrote:
> When we use Doublewrite with checksums, we can safely disable
> full_page_write causing a HUGE reduction to the WAL traffic
> without loss of reliatbility due to a write fault since there are
> two writes always. (Implementation detail discussable).
The "always" there sur
On 22/12/11 10:44, Tom Lane wrote:
> "Johann 'Myrkraverk' Oskarsson" writes:
> > I mean to create a typed hstore, called tstore for now.
>
> Um ... what is the point of this, exactly? From what I've seen, most
> applications for hstore are pretty happy with the fact that hstore is
> only weakly
Bene,
we have pgfoundry project http://pgfoundry.org/projects/dbsamples/.
Since your sample database is very important (for me also), I suggest to use
this site.
Oleg
On Thu, 22 Dec 2011, Benedikt Grundmann wrote:
Hello,
We have a table in a postgres 8.4 database that would make use of date
r
"Johann 'Myrkraverk' Oskarsson" writes:
> I mean to create a typed hstore, called tstore for now.
Um ... what is the point of this, exactly? From what I've seen, most
applications for hstore are pretty happy with the fact that hstore is
only weakly typed, and if an entry *is* an integer, or a fl
On Thu, Dec 22, 2011 at 4:00 AM, Jesper Krogh wrote:
> On 2011-12-22 09:42, Florian Weimer wrote:
>>
>> * David Fetter:
>>
>>> The issue is that double writes needs a checksum to work by itself,
>>> and page checksums more broadly work better when there are double
>>> writes, obviating the need to
Simon Riggs wrote:
> So overall, I do now think its still possible to add an optional
> checksum in the 9.2 release and am willing to pursue it unless
> there are technical objections.
Just to restate Simon's proposal, to make sure I'm understanding it,
we would support a new page header forma
On 2011-12-22 09:42, Florian Weimer wrote:
* David Fetter:
The issue is that double writes needs a checksum to work by itself,
and page checksums more broadly work better when there are double
writes, obviating the need to have full_page_writes on.
How desirable is it to disable full_page_writ
On Thu, Dec 22, 2011 at 8:42 AM, Florian Weimer wrote:
> * David Fetter:
>
>> The issue is that double writes needs a checksum to work by itself,
>> and page checksums more broadly work better when there are double
>> writes, obviating the need to have full_page_writes on.
>
> How desirable is it
On Thu, Dec 22, 2011 at 7:44 AM, Heikki Linnakangas
wrote:
> On 22.12.2011 01:43, Tom Lane wrote:
>>
>> A "utility to bump the page version" is equally a whole lot easier said
>> than done, given that the new version has more overhead space and thus
>> less payload space than the old. What does i
Hello,
We have a table in a postgres 8.4 database that would make use of date
ranges and exclusion constraints if they were available. Sadly I cannot
give you the data as it is based on data we are paying for and as part
of the relevant licenses we are obliqued to not give the data to third
parti
* David Fetter:
> The issue is that double writes needs a checksum to work by itself,
> and page checksums more broadly work better when there are double
> writes, obviating the need to have full_page_writes on.
How desirable is it to disable full_page_writes? Doesn't it cut down
recovery time s
Agreed.
I do agree with Heikki that it really ought to be the OS problem, but
then we thought that about dtrace and we're still waiting for that or
similar to be usable on all platforms (+/- 4 years).
My point is that it looks like this is going to take 1-2 years in
postgresql, so it looks li
Let me mention another lightweight data-interchange format.
At http://www.janestreet.com we have developed a small c module to deal
with S-expressions (sexp) as a way to store arbitrary data. As we write
most of our code in OCaml sexps are a natural way for us to store data.
http://hg.ocaml.info/
It seems that the task of fetching next n results without moving the cursor
seems like too complicated to implement for any query that has
even a little bit of complication in it...
--- On Wed, 12/21/11, Robert Haas wrote:
> From: Robert Haas
> Subject: Re: [HACKERS] Cursor behavior
> To: "ami
Magnus Hagander writes:
> from postgresql.conf.sample:
> #replication_timeout = 60s# in milliseconds; 0 disables
> Seconds or milliseconds? I would suggest we just remove the "in
> milliseconds", and instead say "timeout for replication connections; 0
> disables".
That would take away any in
Christopher Browne writes:
> On Wed, Dec 21, 2011 at 8:32 PM, Johann 'Myrkraverk' Oskarsson
> wrote:
>> I mean to create a typed hstore, called tstore for now. I'm open
>> to name suggestions. It'll only support a subset of core Postgres
>> types to begin with. Keys are always text, it's the
64 matches
Mail list logo
