I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
No, type of this storage describes type of keys. For gin_hstore_ops each key and
each value will be stored as a text value. The root of problem is a JavaScript
or/and our numeric type. In JavaScr
Dear Developers,
Please help with the following problem. I am running PostgreSQL 9.2.3 on SUN
Solaris 9. This is 64 bit system with 32G swap and 16G RAM. I use same
configuration file as on Linux or SUN Solaris 10, where everything is ok. I am
unable to set shared buffer 5G, the maximum possible
Hello, I examined the your patch and it seemed reasonable, but I
have one question about this patch.
You made ec_relids differ to the union of all ec members'
em_relids. Is it right?
At Mon, 03 Mar 2014 14:05:10 -0500, Tom Lane wrote
> Noah Misch writes:
> > If you are convinced that a sepa
> > If its not the case, the user should be more careful about when he is
> > scheduling backups to so that they dont conflict with DDL changes.
>
> That is most certainly the wise choice.
>
> > I am not too comfortable with exposing the locking type to the user. That
> > may be just me though.
>
>
On Tue, Mar 4, 2014 at 1:30 AM, Oleg Bartunov wrote:
> Thanks, looks like a bug.
I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
+ CREATE OPERATOR CLASS gin_hstore_ops
+ DEFAULT FOR TYPE hstore USING gin
+ AS
+ OPERATOR7 @>
Hi all,
I think this patch is completely forgotten, and feel very unfortunate:(
Min, max, and stdev is basic statistics in general monitoring tools,
So I'd like to push it.
(2014/02/12 15:45), KONDO Mitsumasa wrote:
(2014/01/29 17:31), Rajeev rastogi wrote:
No Issue, you can share me the test
On 4 March 2014 08:39, Atri Sharma wrote:
>
>>
>> Good points.
>>
>> In most cases, DDL is applied manually after careful thought, so
>> people seldom dump at the same time they upgrade the database. This is
>> especially true for pg_dump since it captures the logical definition
>> of tables. So m
Thanks, looks like a bug.
On Tue, Mar 4, 2014 at 12:38 PM, Peter Geoghegan wrote:
> Hi Oleg,
>
> On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov wrote:
>> you can always look at our development repository:
>
> I think I found a bug:
>
> [local]/postgres=# \d+ bar
> Table "
On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
> You're reasoning from a false premise: it's *not* necessarily an error.
When wouldn't it be an error? Can you give a real-life example of when
it would be a good idea to use the same name of an input parameter as
a declared variable?
Isn't this
On 4 March 2014 04:18, Amit Kapila wrote:
> On Mon, Mar 3, 2014 at 3:38 PM, Andres Freund wrote:
>> On 2014-02-28 20:55:20 +0530, Amit Kapila wrote:
>>> On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
>>> > Well, as I already stated: we don't. I copied the behavior we use in
>>> > CHECK constrai
>
> Good points.
>
> In most cases, DDL is applied manually after careful thought, so
> people seldom dump at the same time they upgrade the database. This is
> especially true for pg_dump since it captures the logical definition
> of tables. So most people will be happy with the default locking, b
Hi Oleg,
On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov wrote:
> you can always look at our development repository:
I think I found a bug:
[local]/postgres=# \d+ bar
Table "public.bar"
Column | Type | Modifiers | Storage | Stats target | Description
+---+-
(2014/03/04 17:28), Fabien COELHO wrote:
OK. I'm not sure which idia is the best. So I wait for comments in community:)
Hmmm. Maybe you can do what Tom voted for, he is the committer:-)
Yeah, but he might change his mind by our disscuttion. So I wait untill tomorrow,
and if nothing to comment,
On 4 March 2014 01:07, Andres Freund wrote:
> On 2014-03-03 19:15:27 -0500, Tom Lane wrote:
>> Noah Misch writes:
>> > Just to be clear, that list is not a commentary on the particular patch at
>> > hand. Those are merely the kinds of regressions to look for in a patch
>> > affecting this area o
OK. I'm not sure which idia is the best. So I wait for comments in
community:)
Hmmm. Maybe you can do what Tom voted for, he is the committer:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
101 - 115 of 115 matches
Mail list logo