On Fri, Jan 31, 2014 at 6:09 AM, Robert Haas wrote:
> On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
> wrote:
>>> For the documentation patch, I propose the attached to avoid future
>>> confusions. Comments? It might make sense to back-patch as well.
>>
>> Compiles, didn't find any typos and I
On Thu, Jan 30, 2014 at 9:26 PM, Claudio Freire wrote:
> Maybe not TOAST compression, but prefix compression.
I've thought about it as well. It's totally feasible, and likely
worthwhile, but a little more tricky.
> I've been wondering lately, whether a format change in the B-Tree
> could be wort
On 01/30/2014 08:14 PM, MauMau wrote:
>> Does this issue also occur on 9.3.2, or in 9.4 HEAD, when tested on
>> Win2k12?
>
> I'm sure it should. The release note doesn't have any reference to this
> issue. Another user who reported this issue in pgsql-general
> experienced this with 9.2.4.
> In
On Tue, Jan 21, 2014 at 1:10 AM, Antonin Houska
wrote:
> On 01/15/2014 10:52 PM, Alvaro Herrera wrote:
>> I gave this patch a look. There was a bug that the final bounds check
>> for int32 range was not done when there was no suffix, so in effect you
>> could pass numbers larger than UINT_MAX and
On Thu, Jan 30, 2014 at 9:34 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On more occasions than I care to recall, someone has suggested that it
>> would be valuable to do something with strxfrm() blobs in order to
>> have cheaper locale-aware text comparisons. One obvious place to do so
>> w
On Thu, Jan 30, 2014 at 5:05 PM, Peter Geoghegan wrote:
> On Thu, Jan 30, 2014 at 5:04 PM, Tom Lane wrote:
>>> That's not hard to prevent. If that should happen, we don't go with
>>> the strxfrm() datum. We have a spare IndexTuple bit we could use to
>>> mark when the optimization was applied.
>>
Bruce Momjian writes:
> OK, seven hours later, I have fixed pg_bsd_indent to no longer insert
> blank lines above #elif/#else/#endif, and therefore removed the special
> case code from pgindent.
> You will need to download version 1.3 of pg_bsd_indent for this to work,
> and pgindent will complai
On 01/31/2014 02:50 AM, Pavel Stehule wrote:
>
> 5. I didn't test it on windows
I guess that's my cue. I'll be home later today, and will take a look at
it on my Windows test setup.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
On Thu, Jan 30, 2014 at 03:36:48PM -0500, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
> > Or this:
> >
> > - mp_int_copy(a, b); /* ok: 0 <= r < b */
> > - mp_int_copy(&q, a); /* ok: q <= a */
> > + mp_int_copy(a, b); /* ok: 0 <= r < b */
> > + mp_int_copy
On Fri, Jan 31, 2014 at 2:01 AM, Andrew Dunstan wrote:
>
> On 01/30/2014 03:12 PM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> On 12/22/2013 11:30 PM, Amit Kapila wrote:
>>> - * backend start.
>>> + * backend start. However for windows, we need to
>>> proc
On Thu, Jan 30, 2014 at 01:52:55PM -0500, Bruce Momjian wrote:
> On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> > >> I assert that we should simply remove both of these bits of code, as
> > >> ju
Hi Anirudh,
On Fri, Jan 31, 2014 at 12:23 PM, Anirudh wrote:
> Hello everyone,
>
> My name is Anirudh Subramanian and I am a graduate student in Computer
> Science. I would like to participate in Google Summer of Code and would like
> to contribute to postgresql. I am not familiar with the postgr
Hello everyone,
My name is Anirudh Subramanian and I am a graduate student in Computer
Science. I would like to participate in Google Summer of Code and would
like to contribute to postgresql. I am not familiar with the postgresql
codebase yet but will surely get started in the near future. Right
(2014/01/28 22:01), Etsuro Fujita wrote:
(2014/01/27 21:49), Shigeru Hanada wrote:
Is it too big change that making ANALYZE command to handle foreign
tables too even if no table name was specified? IIRC, performance
issue was the reason to exclude foreign tables from auto-analyze
processing. A
On 1/20/14, 8:08 PM, Alvaro Herrera wrote:
> Peter Eisentraut escribió:
>> src/backend/postmaster/postmaster.c:2255: indent with spaces.
>> +else
>> src/backend/postmaster/postmaster.c:2267: indent with spaces.
>> +break;
>
> I just checked the Jenkins page for this patch:
> ht
On 01/31/2014 09:01 AM, Stephen Frost wrote:
> I don't see where this follows at all- clearly, you already get a subset
> of rows from the child than if you queried the parent because there are
> other children.
Er, what? I don't see what you're saying here.
Currently, when you query the parent,
On Thu, Jan 30, 2014 at 3:49 PM, Peter Geoghegan wrote:
> So ISTM that we could come up with an infrastructure, possibly just
> for insertion scanKeys (limiting the code footprint of all of this) in
> order to inner-page-process datums at this juncture, and store a blob
> instead, for later saving
On 01/23/2014 11:22 PM, Emre Hasegeli wrote:
> inet-gist
> -
> I realized that create extension btree_gist fails with the patch.
ERROR: could not make operator class "gist_inet_ops" be default for type inet
DETAIL: Operator class "inet_ops" already is the default.
I think making the n
On 01/30/2014 09:48 PM, Robert Haas wrote:
> On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing wrote:
>> On 10/17/2013 02:42 PM, Robert Haas wrote:
>>> On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing wrote:
On 10/17/2013 10:03 AM, Fabien COELHO wrote:
> My guess is that it won't be committed if
On Thu, Jan 30, 2014 at 4:52 PM, Andrew Dunstan wrote:
>
> On 01/30/2014 07:21 PM, Merlin Moncure wrote:
>> postgres=# select hstore(row(1, array[row(1, array[row(1,
>> array[1,2])::z])::y])::x);
>> hstore
>>
>> -
On Thu, Jan 30, 2014 at 5:04 PM, Tom Lane wrote:
>> That's not hard to prevent. If that should happen, we don't go with
>> the strxfrm() datum. We have a spare IndexTuple bit we could use to
>> mark when the optimization was applied.
>
> You'd need a bit per column, no?
I don't think so. It would
On Thu, Jan 30, 2014 at 4:45 PM, Peter Geoghegan wrote:
> So we consider the
> appropriateness of a regular strcoll() or a strxfrm() in all contexts
> (in a generic and extensible manner, but that's essentially what we
> do). I'm not too discouraged by this restriction, because in practice
> it wo
Peter Geoghegan writes:
> On Thu, Jan 30, 2014 at 4:34 PM, Tom Lane wrote:
>> Quite aside from the index bloat risk, this effect means a 3-4x reduction
>> in the maximum string length that can be indexed before getting the
>> dreaded "Values larger than 1/3 of a buffer page cannot be indexed" err
On Thursday, January 30, 2014, Craig Ringer wrote:
>
> > This strikes me as a bit odd- isn't this against how we handle the
> > GRANT system when it comes to inheiritance? That is to say- if
> > you have access to query the parent, then you'll get rows back from
> > the child and I believe everyo
On Thu, Jan 30, 2014 at 5:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane wrote:
>>> I think this is totally misguided. Who's to say that some weird FDW
>>> might not pay attention to attstorage? I could imagine a file-based
>>> FDW using that to deci
On 01/30/2014 07:21 PM, Merlin Moncure wrote:
Something seems off:
postgres=# create type z as (a int, b int[]);
CREATE TYPE
postgres=# create type y as (a int, b z[]);
CREATE TYPE
postgres=# create type x as (a int, b y[]);
CREATE TYPE
-- test a complicated construction
postgres=# select row
On Thu, Jan 30, 2014 at 4:34 PM, Tom Lane wrote:
> Quite aside from the index bloat risk, this effect means a 3-4x reduction
> in the maximum string length that can be indexed before getting the
> dreaded "Values larger than 1/3 of a buffer page cannot be indexed" error.
> Worse, a value insertion
On 01/31/2014 01:18 AM, Robert Haas wrote:
> On Thu, Jan 30, 2014 at 2:39 AM, Craig Ringer wrote:
>> Earlier discussions seemed to settle on each relation having its own
>> row-security quals applied independently. So quals on a parent rel did
>> not cascade down to child rels.
>
> Do you have a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/30/2014 10:41 PM, Stephen Frost wrote:
>> Earlier discussions seemed to settle on each relation having its
>> own row-security quals applied independently. So quals on a
>> parent rel did not cascade down to child rels.
>
> This strikes me as
Peter Geoghegan writes:
> On more occasions than I care to recall, someone has suggested that it
> would be valuable to do something with strxfrm() blobs in order to
> have cheaper locale-aware text comparisons. One obvious place to do so
> would be in indexes, but in the past that has been dismis
On Thu, Jan 30, 2014 at 1:07 PM, Andrew Dunstan wrote:
>
> On 01/29/2014 04:56 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
>
>
> H
Pavel Raiskup writes:
> [ 0001-pg_upgrade-make-the-locale-comparison-more-toleratin.patch ]
Committed with minor adjustments (mostly, wordsmithing the comments).
Although this was categorized as a bug fix, I'm not sure it's worth
taking the risk of back-patching. We've not seen very many report
On more occasions than I care to recall, someone has suggested that it
would be valuable to do something with strxfrm() blobs in order to
have cheaper locale-aware text comparisons. One obvious place to do so
would be in indexes, but in the past that has been dismissed on the
following grounds:
*
On 1/28/14, 3:59 PM, Rohit Goyal wrote:
The data from IndexTupleData is written to disk, and then read back in
again. Did you initdb a new database cluster after you made your change? If
you did the initdb with the original code, and then tried to point your new
code at the old disk fil
On Thu, January 30, 2014 23:15, Erik Rijkers wrote:
> On Thu, January 30, 2014 20:07, Andrew Dunstan wrote:
>>
>> Updated patches for both pieces. Included is some tidying done by
>>
>> [ nested-hstore-9.patch.gz ]
>
> Here is a small doc-patch to Table F-6. hstore Operators
>
> It corrects its
On Thu, January 30, 2014 20:07, Andrew Dunstan wrote:
>
> Updated patches for both pieces. Included is some tidying done by
>
> [ nested-hstore-9.patch.gz ]
Here is a small doc-patch to Table F-6. hstore Operators
It corrects its booleans in the 'Result' column ( t and f instead of true and
Robert Haas writes:
> On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane wrote:
>> I think this is totally misguided. Who's to say that some weird FDW
>> might not pay attention to attstorage? I could imagine a file-based
>> FDW using that to decide whether to compress columns, for instance.
>> Admitte
On Thu, Jan 30, 2014 at 11:04 AM, Tom Lane wrote:
> Shigeru Hanada writes:
>> At the moment we don't use attstorage for foreign tables, so allowing
>> SET STORAGE against foreign tables never introduce visible change
>> except \d+ output of foreign tables. But IMO such operation should
>> not al
On 30 January 2014 17:27, Robert Haas wrote:
> On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs wrote:
>> On 14 January 2014 08:38, Christian Kruse wrote:
>>> Hi,
>>> On 13/01/14 20:06, Heikki Linnakangas wrote:
On 12/17/2013 04:58 PM, Christian Kruse wrote:
>attached you will find a patch
On Thu, Jan 30, 2014 at 12:32 PM, Tom Lane wrote:
>> In reality, actual applications
>> could hardly be further from the perfectly uniform distribution of
>> distinct queries presented here.
>
> Yeah, I made the same point in different words. I think any realistic
> comparison of this code to wha
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
wrote:
>> For the documentation patch, I propose the attached to avoid future
>> confusions. Comments? It might make sense to back-patch as well.
>
> Compiles, didn't find any typos and I think it is comprehensible.
I took a look at this with a vie
On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing wrote:
> On 10/17/2013 02:42 PM, Robert Haas wrote:
>> On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing wrote:
>>> On 10/17/2013 10:03 AM, Fabien COELHO wrote:
My guess is that it won't be committed if there is a single "but it
might break one co
On Thu, Jan 30, 2014 at 03:32:27PM -0500, Robert Haas wrote:
> Or this:
>
> - mp_int_copy(a, b); /* ok: 0 <= r < b */
> - mp_int_copy(&q, a); /* ok: q <= a */
> + mp_int_copy(a, b); /* ok: 0 <= r < b */
> + mp_int_copy(&q, a); /* ok: q <= a */
>
> I do agree with you some of the changes-a
Alvaro Herrera writes:
> Robert Haas escribió:
>> I don't have any comment on that specific point, but I took a quick
>> look through one of these diffs and it looks like a lot of churn for
>> no improvement. So I'm not sure what we want to do here, but I don't
>> think it's this.
> I, on the co
Peter Geoghegan writes:
> On Thu, Jan 30, 2014 at 9:57 AM, Tom Lane wrote:
>> BTW ... it occurs to me to wonder if it'd be feasible to keep the
>> query-texts file mmap'd in each backend, thereby reducing the overhead
>> to write a new text to about the cost of a memcpy, and eliminating the
>> re
On Thu, Jan 30, 2014 at 3:04 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
>> > I compute 6627 lines as modified. What I did not do is handle _only_
>> > cases with periods before the tabs. Should I try that?
>>
>> I don't have any c
On 01/30/2014 03:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/22/2013 11:30 PM, Amit Kapila wrote:
- * backend start.
+ * backend start. However for windows, we need to process
+ * config file during backend start for non-default
parameter
Andrew Dunstan writes:
> On 12/22/2013 11:30 PM, Amit Kapila wrote:
> - * backend start.
> + * backend start. However for windows, we need to process
> + * config file during backend start for non-default
> parameters,
> + * so we ne
Robert Haas escribió:
> On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
> > I compute 6627 lines as modified. What I did not do is handle _only_
> > cases with periods before the tabs. Should I try that?
>
> I don't have any comment on that specific point, but I took a quick
> look thro
On Wed, Jan 29, 2014 at 11:21 PM, Bruce Momjian wrote:
> On Wed, Jan 29, 2014 at 07:31:29PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>> > I have cleaned up entab.c so I am ready to add a new option that removes
>> > tabs from only comments. Would you like me to create that and provide a
>
On 12/22/2013 11:30 PM, Amit Kapila wrote:
I had observed one problem with PGC_BACKEND parameters while testing patch
for ALTER SYSTEM command.
Problem statement: If I change PGC_BACKEND parameters directly in
postgresql.conf and then do pg_reload_conf() and reconnect, it will
On Thu, Jan 30, 2014 at 9:57 AM, Tom Lane wrote:
> BTW ... it occurs to me to wonder if it'd be feasible to keep the
> query-texts file mmap'd in each backend, thereby reducing the overhead
> to write a new text to about the cost of a memcpy, and eliminating the
> read cost in pg_stat_statements()
2014-01-19 Tom Lane :
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> I kind of don't see the point of having IF NOT EXISTS for things that
> >> have OR REPLACE, and am generally in favor of implementing OR REPLACE
> >> rather than IF NOT EXISTS where possible. The
On Thu, Jan 23, 2014 at 03:17:35PM +0100, Ronan Dunklau wrote:
> > > - for after triggers, the whole queuing mechanism is bypassed for foreign
> > > tables. This is IMO acceptable, since foreign tables cannot have
> > > constraints or constraints triggers, and thus have not need for
> > > deferrabl
On 01/30/2014 01:50 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
We'd have to move that code from hstore to jsonb_support.c and then
make hstore refer to it.
Or just copy it and leave hstore alone - the
On Thu, Jan 30, 2014 at 01:46:34PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> >> I assert that we should simply remove both of these bits of code, as
> >> just about every committer on the project is smarter about when to use
> >>
Hello
This patch creates a infrastructure for client side testing environment
1. Surely we want this patch, this infrastructure - lot of important
functionality is not covered by tests - pg_dump, pg_basebackup, ... Without
infrastructure is terrible work to create some tests.
2. This patch does
Andrew Dunstan writes:
> On 01/30/2014 01:03 PM, Hannu Krosing wrote:
>> On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
>>> We'd have to move that code from hstore to jsonb_support.c and then
>>> make hstore refer to it.
>> Or just copy it and leave hstore alone - the code duplication is not
>> te
On Fri, Aug 9, 2013 at 09:12:03AM -0400, Robert Haas wrote:
> On Mon, Aug 5, 2013 at 4:53 PM, Dimitri Fontaine
> wrote:
> > Bruce Momjian writes:
> >> So do we want to keep that "AND" in the 9.3beta and 9.4 documentation?
> >
> > The grammar as in gram.y still allows the AND form, and I think w
Bruce Momjian writes:
> On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
>> I assert that we should simply remove both of these bits of code, as
>> just about every committer on the project is smarter about when to use
>> vertical whitespace than this program is.
> OK, I have developed t
On Thu, Jul 18, 2013 at 12:27:21AM -0400, Tom Lane wrote:
> It's always annoyed me that pgindent insists on adjusting vertical
> whitespace around #else and related commands. This has, for example,
> rendered src/include/storage/barrier.h nigh illegible: you get things
> like
>
> /*
> * lwsync o
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan
wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for
Christian Kruse wrote:
> +Since Gentoo often supports different versions of a package to be
> +installed you have to tell the PostgreSQL build environment where the
> +Docbook DTD is located:
> +
> +cd /path/to/postgresql/sources/doc
> +make DOCBOOKSTYLE=/usr/share/sgml/docbook/sgml-dt
Hi.
Now it looks fine for me.
2014-01-28 Dimitri Fontaine :
> Hi,
>
> Sergey Muraviov writes:
> > Now patch applies cleanly and works. :-)
>
> Cool ;-)
>
> > But I have some notes:
> >
> > 1. There is an odd underscore character in functions
> > find_in_extension_control_path and list_extension
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
>
> On 01/30/2014 12:34 PM, Merlin Moncure wrote:
>> On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan
>> wrote:
> Now, if we're agreed on that, I then also wonder if the 'as_text'
> argument needs to exist at all for the populate functions excep
BTW ... it occurs to me to wonder if it'd be feasible to keep the
query-texts file mmap'd in each backend, thereby reducing the overhead
to write a new text to about the cost of a memcpy, and eliminating the
read cost in pg_stat_statements() altogether. It's most likely not worth
the trouble; but
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json side (not jsonb). For
Robert Haas writes:
> One could test it with each pgbench thread starting at a random point
> in the same sequence and wrapping at the end.
Well, the real point is that 1 distinct statements all occurring with
exactly the same frequency isn't a realistic scenario: any hashtable size
less than
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan wrote:
>>> Now, if we're agreed on that, I then also wonder if the 'as_text'
>>> argument needs to exist at all for the populate functions except for
>>> backwards compatibility on the json side (not jsonb). For non-complex
>>> structures it does be
On Wed, Jan 29, 2014 at 3:11 PM, Simon Riggs wrote:
> On 14 January 2014 08:38, Christian Kruse wrote:
>> Hi,
>> On 13/01/14 20:06, Heikki Linnakangas wrote:
>>> On 12/17/2013 04:58 PM, Christian Kruse wrote:
>>> >attached you will find a patch for showing the current transaction id
>>> >(xid) an
On Thu, Jan 30, 2014 at 12:23 PM, Tom Lane wrote:
> I wrote:
>> If I understand this test scenario properly, there are no duplicate
>> queries, so that each iteration creates a new hashtable entry (possibly
>> evicting an old one). And it's a single-threaded test, so that there
>> can be no benef
I wrote:
> If I understand this test scenario properly, there are no duplicate
> queries, so that each iteration creates a new hashtable entry (possibly
> evicting an old one). And it's a single-threaded test, so that there
> can be no benefit from reduced locking.
After looking more closely, it'
On Thu, Jan 30, 2014 at 2:39 AM, Craig Ringer wrote:
> Earlier discussions seemed to settle on each relation having its own
> row-security quals applied independently. So quals on a parent rel did
> not cascade down to child rels.
Do you have a link to that prior discussion? I don't remember
rea
Peter Geoghegan writes:
> On Wed, Jan 29, 2014 at 8:48 PM, KONDO Mitsumasa
> wrote:
>> method | try1 | try2 | try3 | degrade performance ratio
>> -
>> method 1 | 6.546 | 6.558 | 6.638 | 0% (reference score)
>> method 2 | 6
On 01/30/2014 01:53 AM, Tomas Vondra wrote:
(3) A file with explain plans for 4 queries suffering ~2x slowdown,
and explain plans with 9.4 master and Heikki's patches is available
here:
http://www.fuzzy.cz/tmp/gin/queries.txt
All the queries have 6 common words, and the ex
Shigeru Hanada writes:
> At the moment we don't use attstorage for foreign tables, so allowing
> SET STORAGE against foreign tables never introduce visible change
> except \d+ output of foreign tables. But IMO such operation should
> not allowed because users would be confused. So I changed
> AT
KONDO Mitsumasa writes:
> (2014/01/30 8:29), Tom Lane wrote:
>> If we felt that min/max were of similar value to stddev then this
>> would be mere nitpicking. But since people seem to agree they're
>> worth less, I'm thinking the cost/benefit ratio isn't there.
> Why do you surplus worried about
ok, great. This is really fabulous. So far most everything feels
natural and good.
I see something odd in terms of the jsonb use case coverage. One of
the major headaches with json deserialization presently is that
there's no easy way to easily move a complex (record- or array-
containing)
Hi,
On 30/01/14 10:01, Tom Lane wrote:
> While I haven't actually read the gettext docs, I'm pretty sure that
> gettext() is defined to preserve errno. It's supposed to be something
> that you can drop into existing printf's without thinking, and if
> it mangled errno that would certainly not be
Tom Lane wrote:
> Christian Kruse writes:
> > Have a look at the psprintf() call: we first have a _("failed to look
> > up effective user id %ld: %s") as an argument, then we have a (long)
> > user_id and after that we have a ternary expression using errno. Isn't
> > it possible that the first _()
Christian Kruse writes:
> Have a look at the psprintf() call: we first have a _("failed to look
> up effective user id %ld: %s") as an argument, then we have a (long)
> user_id and after that we have a ternary expression using errno. Isn't
> it possible that the first _() changes errno?
While I h
On Mon, Jan 27, 2014 at 10:48:16PM -0500, Bruce Momjian wrote:
> On Mon, Jan 27, 2014 at 07:19:21PM -0500, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Oh, one odd thing about this patch. I found I needed to use INT64_MAX,
> > > but I don't see it used anywhere else in our codebase. Is this O
Craig, all,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> I'm considering just punting on inheritance for 9.4, adding checks to
> prohibit inheritance from being added to a rel with row security and
> prohibiting any rel with inheritance from being given a row-security policy.
I'm alright with
On 30 January 2014 11:55, Dean Rasheed wrote:
> Hmm, looks like this is a pre-existing bug.
>
> The first thing I tried was to reproduce it using SQL, so I used a
> RULE to turn a DELETE into a SELECT FOR UPDATE. This is pretty dumb,
> but it shows the problem:
>
> CREATE TABLE foo (a int);
> CRE
Hi,
Alvaro Herrera writes:
> So here's a patch implementing the ideas expressed in this thread.
> There are two new SQL functions:
I spent some time reviewing the patch and tried to focus on a higher
level review, as I saw Andres already began with the lower level stuff.
The main things to keep
2014-01-30 Jeevan Chalke :
> OK.
>
> Assigned it to committer.
>
> Thanks for the hard work.
>
Thank you for review
Pavel
>
>
> On Thu, Jan 30, 2014 at 6:16 PM, Pavel Stehule wrote:
>
>> Hello
>>
>> All is ok
>>
>> Thank you
>>
>> Pavel
>>
>
> --
> Jeevan B Chalke
> Principal Software Engineer
OK.
Assigned it to committer.
Thanks for the hard work.
On Thu, Jan 30, 2014 at 6:16 PM, Pavel Stehule wrote:
> Hello
>
> All is ok
>
> Thank you
>
> Pavel
>
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
Hello
All is ok
Thank you
Pavel
2014-01-30 Jeevan Chalke :
> Hi Pavel,
>
> Now patch looks good to me and I think it is in good shape to pass it on to
> the committer as well.
>
> However, I have
> - Tweaked few comments
> - Removed white-space errors
> - Fixed typos
> - Fixed indentation
>
>
From: "Ronan Dunklau"
There is no regression tests covering this bugfix, althought I don't know
if
it would be practical to implement them.
Thanks for reviewing the patch. I'm glad to know that it seems OK.
Unfortunately, the current regression test system cannot handle the testing
of pg_c
I'm sorry for the late reply. I was unable to access email.
From: "Craig Ringer"
On 01/24/2014 06:42 PM, MauMau wrote:
The customer is using 64-bit PostgreSQL 9.1.x
Which "x"?
9.1.6.
Does this issue also occur on 9.3.2, or in 9.4 HEAD, when tested on
Win2k12?
I'm sure it should. The
Hi Pavel,
Now patch looks good to me and I think it is in good shape to pass it on to
the committer as well.
However, I have
- Tweaked few comments
- Removed white-space errors
- Fixed typos
- Fixed indentation
Attached patch with my changes. However entire design and code logic is
untouched.
P
On Wed, Jan 29, 2014 at 12:35 PM, Michael Paquier
wrote:
> On Wed, Jan 29, 2014 at 10:55 AM, Fujii Masao wrote:
>> On Wed, Jan 29, 2014 at 3:07 AM, Alvaro Herrera
>> wrote:
>>>
>>> Anybody knows about this patch?
>>> http://www.postgresql.org/message-id/508dfec9.4020...@uptime.jp
>>
>> Though I'
On 30 January 2014 05:36, Craig Ringer wrote:
> On 01/29/2014 08:29 PM, Dean Rasheed wrote:
>> On 29 January 2014 11:34, Craig Ringer wrote:
>>> On 01/23/2014 06:06 PM, Dean Rasheed wrote:
On 21 January 2014 09:18, Dean Rasheed wrote:
> Yes, please review the patch from 09-Jan
> (ht
On Tue, Jan 21, 2014 at 1:33 AM, Simon Riggs wrote:
> On 20 January 2014 17:00, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> What if you're a superuser and you want to move everybody's objects
>>> (perhaps in preparation for dropping the tablespace)? I think there's
>>> val
On Thu, Jan 30, 2014 at 12:23 PM, Amit Kapila wrote:
> On Wed, Jan 29, 2014 at 8:13 PM, Heikki Linnakangas
> wrote:
>
> Few observations in patch (back-to-pglz-like-delta-encoding-1):
>
> 1.
> +#define pgrb_hash_unroll(_p, hindex) \
> + hindex = hindex ^ ((_p)[0] << 8)
>
> shouldn't it shift by 6
Hi Pavel,
I looked at your latest cleanup patch. Yes its looks more cleaner in term
equivalent_locale & equivalent_encoding separate functions.
I did run the test again on latest patch and all looks good.
Marking it as ready for committer.
Regards,
On Fri, Jan 24, 2014 at 9:49 PM, Pavel Rais
Hello
patch with updated comment
regards
Pavel
2014-01-30 Jeevan Chalke :
> Hi Pavel,
>
> it should be fixed by
>>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b152c6cd0de1827ba58756e24e18110cf902182acommit
>>>
>>
> Ok. Good.
> Sorry I didn't update my sources. Done no
On Wed, Jan 29, 2014 at 8:48 PM, KONDO Mitsumasa
wrote:
> I'd like to know the truth and the fact in your patch, rather than your
> argument:-)
I see.
> [part of sample sqls file, they are executed in pgbench]
> SELECT
> 1-1/9+5*8*6+5+9-6-3-4/9%7-2%7/5-9/7+2+9/7-1%5%9/3-4/4-9/1+5+5/6/5%2+1*2*3-
(2014/01/30 8:29), Tom Lane wrote:
> Andrew Dunstan writes:
>> I could live with just stddev. Not sure others would be so happy.
>
> FWIW, I'd vote for just stddev, on the basis that min/max appear to add
> more to the counter update time than stddev does; you've got
> this:
>
> + e-
30.01.2014 11:37, Jeevan Chalke kirjoitti:
Hi Oskari,
Are you planning to work on what Tom has suggested ? It make sense to me
as well.
What are your views on that ?
Tom's suggestions make sense to me, but unfortunately I haven't had time
to work on this feature recently so I don't think it'
1 - 100 of 109 matches
Mail list logo
