On Mon, Oct 1, 2012 at 12:57 AM, Magnus Hagander wrote:
> Can we please expose the internal hash id of the statements in
> pg_stat_statements?
>
> I know there was discussions about it earlier, and it wasn't done with
> an argument of it not being stable between releases (IIRC). I think we
> can l
I was wondering recently if there was any command line tool that
utilized PQping() or PQpingParams(). I searched the code and couldn't
find anything and was wondering if there was any interest to have
something like this included? I wrote something for my purposes of
performing a health check that
Excerpts from Dimitri Fontaine's message of lun oct 01 04:44:28 -0300 2012:
> Hi,
>
> Alvaro Herrera writes:
> >> Same for 9.2, attached. master needs yet another patch because of the
> >> recent headers reorg, it seems, that's for another day though.
> >
> > No, just remove the RELKIND_UNCATALOG
Applied to head and 9.2.
---
On Wed, Sep 26, 2012 at 10:06:50PM -0400, Bruce Momjian wrote:
> On Tue, Sep 25, 2012 at 05:36:54PM +0300, Devrim Gunduz wrote:
> >
> > Hi,
> >
> > I just performed a test upgrade from 9.1 to 9
This case points to a weakness in many programming languages, not having a
clear ifof (if and only if) versus if construction.
The sane use case for create schema foo if not exists is for building
a database dynamically, where several points may be the first to put a table in
a schema, and sc
2012/10/2 Alvaro Herrera
> Excerpts from Andrew Dunstan's message of mar oct 02 17:24:38 -0300 2012:
> >
> > On 10/02/2012 03:48 PM, Tom Lane wrote:
> > > Alvaro Herrera writes:
>
> > >> Well, if that's the rationale then you end up with no schema foo at
> all
> > >> (i.e. both die), which seems
On Tue, Oct 02, 2012 at 12:58:15PM -0400, Stephen Frost wrote:
> > I simply do not understand objections to the proposal. Have I missed
> > something?
>
> It was my impression that the concern is the stability of the hash value
> and ensuring that tools which operate on it don't mistakenly lump t
Excerpts from Andrew Dunstan's message of mar oct 02 17:24:38 -0300 2012:
>
> On 10/02/2012 03:48 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Well, if that's the rationale then you end up with no schema foo at all
> >> (i.e. both die), which seems even more surprising (though I admit it
On 10/02/2012 03:48 PM, Tom Lane wrote:
Alvaro Herrera writes:
Excerpts from David E. Wheeler's message of mar oct 02 16:16:37 -0300 2012:
On Oct 2, 2012, at 12:08 PM, Alvaro Herrera wrote:
create schema if not exists foo create table first (a int);
create schema if not exists foo create ta
On Oct 2, 2012, at 12:48 PM, Tom Lane wrote:
> I think we should just disallow putting any contained objects in the
> statement when IF NOT EXISTS is used. It's simple to understand, simple
> to document and implement, and I think it covers all the sane use-cases
> anyway.
+1
David
--
Sent
Excerpts from David E. Wheeler's message of mar oct 02 16:37:30 -0300 2012:
> On Oct 2, 2012, at 12:30 PM, Alvaro Herrera wrote:
>
> > How about call this for precedent:
> >
> > mkdir -p /tmp/foo/bar
> > mkdir -p /tmp/foo/baz
> >
> > In this case you end up with directory "foo" and at least two
Alvaro Herrera writes:
> Excerpts from David E. Wheeler's message of mar oct 02 16:16:37 -0300 2012:
>> On Oct 2, 2012, at 12:08 PM, Alvaro Herrera wrote:
>>> create schema if not exists foo create table first (a int);
>>> create schema if not exists foo create table second (a int);
>>>
>>> As fa
On Oct 2, 2012, at 12:30 PM, Alvaro Herrera wrote:
> How about call this for precedent:
>
> mkdir -p /tmp/foo/bar
> mkdir -p /tmp/foo/baz
>
> In this case you end up with directory "foo" and at least two subdirs in
> it, bar and baz. This works even if /tmp/foo existed previously and
> even if
Excerpts from David E. Wheeler's message of mar oct 02 16:16:37 -0300 2012:
> On Oct 2, 2012, at 12:08 PM, Alvaro Herrera wrote:
>
> > create schema if not exists foo create table first (a int);
> > create schema if not exists foo create table second (a int);
> >
> >
> > As far as I can see, wi
On Oct 2, 2012, at 12:08 PM, Alvaro Herrera wrote:
> create schema if not exists foo create table first (a int);
> create schema if not exists foo create table second (a int);
>
>
> As far as I can see, with the patch as it currently stands, you would
> end up with only table "first" in the sch
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Noah Misch
> Sent: Tuesday, October 02, 2012 3:02 PM
> To: Craig Ringer
> Cc: PostgreSQL Hackers
> Subject: Re: [HACKERS] Raise a WARNING if a REVOKE affects nothing?
Excerpts from Volker Grabsch's message of sáb sep 29 06:32:13 -0300 2012:
> Dickson S. Guedes schrieb:
> > - https://commitfest.postgresql.org/action/patch_view?id=907
> >
> > The patch is small and implements a new syntax to CREATE SCHEMA
> > that allow the creation of a schema be skipped when IF
On 2 October 2012 17:58, Stephen Frost wrote:
> Right, and that's all I'm trying to address here- how do we provide a
> value for a given query which can be relied upon by outside sources,
> even in the face of a point release which changes what our internal hash
> value for a given query is.
I d
The fundamental issue with this patch hasn't been answered sufficiently,
I think. Consider the following sequence of commands:
create schema if not exists foo create table first (a int);
create schema if not exists foo create table second (a int);
As far as I can see, with the patch as it curr
On Tue, Aug 21, 2012 at 02:31:29PM +0800, Craig Ringer wrote:
> It'd really help if REVOKE consistently raised warnings when it didn't
> actually revoke anything.
+1
This will invite the same mixed feelings as the CREATE x IF NOT EXISTS
notices, but I think it's worthwhile.
> Even better, a sp
On 2 October 2012 18:16, Tom Lane wrote
> 1. Why isn't something like md5() on the reported query text an equally
> good solution for users who want a query hash?
Because that does not uniquely identify the entry. The very first
thing that the docs say on search_path is "Qualified names are tedio
On Wed, Oct 3, 2012 at 3:11 AM, Simon Riggs wrote:
> On 2 October 2012 19:06, Fujii Masao wrote:
>> On Sat, Aug 11, 2012 at 2:19 AM, Fujii Masao wrote:
>>> On Thu, Aug 9, 2012 at 8:08 AM, Simon Riggs wrote:
On 29 July 2012 16:01, Fujii Masao wrote:
> Attached patch changes the st
On 2 October 2012 19:06, Fujii Masao wrote:
> On Sat, Aug 11, 2012 at 2:19 AM, Fujii Masao wrote:
>> On Thu, Aug 9, 2012 at 8:08 AM, Simon Riggs wrote:
>>> On 29 July 2012 16:01, Fujii Masao wrote:
>>>
Attached patch changes the startup process so that it creates .done file
whenever W
Hello
I did review of pgbench patch
http://archives.postgresql.org/pgsql-hackers/2012-09/msg00737.php
* this patch is cleanly patched
* I had a problem with doc
make[1]: Entering directory `/home/pavel/src/postgresql/doc/src/sgml'
openjade -wall -wno-unused-param -wno-empty -wfully-tagged -D .
On Sat, Aug 11, 2012 at 2:19 AM, Fujii Masao wrote:
> On Thu, Aug 9, 2012 at 8:08 AM, Simon Riggs wrote:
>> On 29 July 2012 16:01, Fujii Masao wrote:
>>
>>> Attached patch changes the startup process so that it creates .done file
>>> whenever WAL file is successfully restored, whether archive mo
On Tue, Aug 28, 2012 at 05:04:09PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
> >> There's also the big-picture question of whether we should just get rid
> >> of fuzzy comparisons in the geometric types instead of trying to hack
> >> indexes
Stephen Frost writes:
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> I simply do not understand objections to the proposal. Have I missed
>> something?
> It was my impression that the concern is the stability of the hash value
> and ensuring that tools which operate on it don't mistakenly
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 1 October 2012 18:05, Stephen Frost wrote:
> > You're going to have to help me here, 'cause I don't see how there can
> > be duplicates if we include the PGSS_FILE_HEADER as part of the hash,
> > unless we're planning to keep PGSS_FILE_HEADER c
On Tuesday, October 02, 2012 06:30:33 PM Tom Lane wrote:
> Andres Freund writes:
> >> pg_calloc (randomly different API for pg_malloc0)
> >
> > Do we need this?
>
> I thought about getting rid of it, but there are some dozens of calls
> scattered across several files, so I wasn't sure it was wo
On Tue, Oct 2, 2012 at 12:30 PM, Tom Lane wrote:
> Andres Freund writes:
>>> pg_calloc(randomly different API for pg_malloc0)
>
>> Do we need this?
>
> I thought about getting rid of it, but there are some dozens of calls
> scattered across several files, so I wasn't sure it was worth it.
> A
Andres Freund writes:
>> pg_calloc(randomly different API for pg_malloc0)
> Do we need this?
I thought about getting rid of it, but there are some dozens of calls
scattered across several files, so I wasn't sure it was worth it.
Anybody else have an opinion?
> I wonder whether the same set
On Tue, Oct 2, 2012 at 12:02:13PM -0400, Tom Lane wrote:
> While looking around to fix the pg_malloc(0) issue, I noticed that
> various other pieces of code such as pg_basebackup have essentially
> identical functions, except they're called xmalloc(). I propose to
> standardize all these things o
On Tuesday, October 02, 2012 06:02:13 PM Tom Lane wrote:
> While looking around to fix the pg_malloc(0) issue, I noticed that
> various other pieces of code such as pg_basebackup have essentially
> identical functions, except they're called xmalloc(). I propose to
> standardize all these things on
While looking around to fix the pg_malloc(0) issue, I noticed that
various other pieces of code such as pg_basebackup have essentially
identical functions, except they're called xmalloc(). I propose to
standardize all these things on this set of names:
pg_malloc
pg_malloc0 (f
On Tue, Sep 25, 2012 at 09:10:33AM -0400, Bruce Momjian wrote:
> > lc_collate cluster values do not match: old "zh_CN.utf8", new "zh_CN.UTF-8"
> > Failure, exiting
> >
> > zh_CN.utf8 is provided by the installer and zh_CN.UTF-8 is my system
> > default.
>
> OK, this tells us that the canonicaliza
On 09/25/2012 12:28:13 AM, Karl O. Pinc wrote:
> On 09/23/2012 08:57:45 PM, Karl O. Pinc wrote:
>
> > The attached patch documents the oid column of those
> > system catalogs having an oid.
>
> Don't use the first version of this patch (oid_doc.patch)
> without discarding the last hunk. The last
P
On Oct 2, 2012 5:04 PM, "Euler Taveira" wrote:
>
> On 02-10-2012 10:15, Peter Geoghegan wrote:
> > There are other, similar tools that exist in proprietary databases.
> > They expose a hash value, which is subject to exactly the same caveats
> > as our own. They explicitly encourage the type of
On 02-10-2012 10:15, Peter Geoghegan wrote:
> There are other, similar tools that exist in proprietary databases.
> They expose a hash value, which is subject to exactly the same caveats
> as our own. They explicitly encourage the type of aggregation by
> third-party tools that I anticipate will ha
Thom Brown and I were doing some hacking the other day and came across
this missing define. We argued over who was going to send the patch in
and I lost. So here it is.
pg_type_uuid_oid.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
While I'm referring to the 8.4 release, it's a slightly more general question.
We're moving away from using pg_largeobject as fast as we can, and while doing
so I'm seeing interesting behaviour. I'd like to confirm that this is is
expected, or perhaps I don't have tuning parameters set quite cor
On 1 October 2012 18:05, Stephen Frost wrote:
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> That won't really help matters. There'd still be duplicate entries,
>> from before and after the change, even if we make it immediately
>> obvious which is which. The only reasonable solution in tha
2012/10/1 Heikki Linnakangas :
> On 27.09.2012 23:58, Pavel Stehule wrote:
>>
>> Hello
>>
>> I reduced this patch as just plpgsql (SPI) problem solution.
>>
>> Correct generic solution needs a discussion about enhancing our libpq
>> interface - we can take a number of returned rows, but we should t
On Tue, Oct 2, 2012 at 2:57 AM, Peter Eisentraut wrote:
> I'm proposing to make the attached change to some LDAP error messages.
> Aside from fixing a pluralization issue, I want to separate fact (search
> resulted in != 1 result) from interpretation (LDAP user does not exist,
> and that's a probl
On 02.10.2012 10:36, Amit kapila wrote:
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
So let's think how this should ideally work from a user's point of view.
I think there should be just two settings: walsender_timeout and
walreceiver_timeout. walsender_timeout specifies how lon
On 02.10.2012 01:30, Hitoshi Harada wrote:
It seems date_in() has a risk of buffer overrun. If the input is '.',
it sets field[0] to the beginning of workbuf and goes into
DecodeDate(). This function checks null-termination of the head of
string, but it can go beyond the end of string inside th
Hi!
Attached patch removes unused targets which are used only for order by when
data already comes in right order. It introduces resorderbyonly flag of
TargetEntry which indicated that entry is used only for ORDER BY clause. If
data comes in right order then such entries are removed in grouping_pl
On Monday, October 01, 2012 8:36 PM Robert Haas wrote:
On Mon, Oct 1, 2012 at 6:38 AM, Heikki Linnakangas
wrote:
>> Hmm, I think we need to step back a bit. I've never liked the way
>> replication_timeout works, where it's the user's responsibility to set
>> wal_receiver_status_interval < replica
On Monday, October 01, 2012 4:08 PM Heikki Linnakangas wrote:
On 21.09.2012 14:18, Amit kapila wrote:
> On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
> On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapila wrote:
>
Approach-2 :
Provide a variable wal_send_status_interval, such that if
On Fri, Sep 14, 2012 at 01:26:30AM +0200, Brar Piening wrote:
> Heikki Linnakangas wrote:
>> I don't think we can realistically support VS2012 until Microsoft
>> releases the gratis Visual Studio Express 2012 for Windows Desktop.
>
> As they've released now I've updated my Patch with docs and ask
49 matches
Mail list logo
