On Wed, September 25, 2013 00:14, Alvaro Herrera wrote:
> [minmax-4-incr.patch]
After a --data-checksums initdb (successful), the following error came up:
after the statement: create index t_minmax_idx on t using minmax (r);
WARNING: page verification failed, calculated checksum 25951 but ex
On Tue, Sep 24, 2013 at 9:49 PM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund wrote:
>>> > Hm, I guess you dont't want to add it to global/ or so because of the
>>> > mmap implementation where you presumably scan the directory?
>>>
>>> Yes, and also because I thought this
On Tue, 2013-09-24 at 21:04 +0900, MauMau wrote:
> "4. I guess some users really want to continue to use ShiftJIS or EUC_JP for
> database encoding, and use NCHAR for a limited set of columns to store
> international text in Unicode:
> - to avoid code conversion between the server and the client fo
On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
> Hmm not sure i understand this argument either: this patch doesn't
> allow disabling a primary key. It only supports FKs and CHECK
> constraints explicitly.
Well, as soon as the patch for cataloging not-null constraints as check
constraints
On Tue, Sep 24, 2013 at 7:35 AM, Robert Haas wrote:
> I don't really disagree with any of that. TBH, I think the question
> of how long value locks (as you call them) are held is going to boil
> down to a question of how they end up being implemented.
Well, I think we can rule out value locks th
On Tue, Sep 24, 2013 at 2:22 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Now I admit that's an arguable point. We could certainly define an
>> intermediate notion of equality that is more equal than whatever =
>> does, but not as equal as exact binary equality.
>
>
At 2013-09-24 09:51:00 -0700, jeff.ja...@gmail.com wrote:
>
> I get wrong answers from this index sometimes.
Thanks for the report and the test case. I'll investigate.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Sep 24, 2013 10:12 AM, "Josh Berkus" wrote:
>
> All,
>
> I've send kernel.org a message that we're keen on seeing these changes
> become committed.
I thought it was merged already in 3.12. There are a few related
patches, but here's one:
commit 519e52473ebe9db5cdef44670d5a97f1fd53d721
Author:
Stephen Frost wrote:
>> I think the conservative (and therefore correct) approach is to
>> decide that we're always going to update if we detect any
>> difference at all.
>
> And there may be users who are surprised that a refresh changed
> parts of the table that have nothing to do with what was
Jaime Casanova wrote:
> Found another problem with the this steps:
>
> create table t1 (i int);
> create index idx_t1_i on t1 using minmax(i);
> insert into t1 select generate_series(1, 200);
> ERROR: could not read block 1 in file "base/12645/16397_vm": read
> only 0 of 8192 bytes
Thanks.
On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule
> wrote:
> >> I have developed the attached patch based on your suggestion. I did not
> >> see anything in the code that would make it STABLE, except a lookup of a
> >> dictionary librar
On Thu, Sep 12, 2013 at 09:38:43AM +0530, Amit Kapila wrote:
> > I have created the attached patch which issues an error when SET
> > TRANSACTION and SET LOCAL are used outside of transactions:
> >
> > test=> set transaction isolation level serializable;
> > ERROR: SET TRANSACTION
Split 3 of the initial submission, which actually deal with data measured and
reported on stderr under various options.
This version currently takes into account many comments by Noah Mish. In
particular, the default "no report" behavior under benchmarking is not
changed, although I really t
On 09/22/2013 10:44 PM, Fabien COELHO wrote:
> Due to the possibly repetitive table structure of the data, maybe CSV
> would make sense as well. It is less extensible, but it is directly
> usable by sqlite or pg.
I'd be OK with CSV. At least I wouldn't be regexing the output.
--
Josh Berkus
Pos
On Tue, Sep 24, 2013 at 3:14 PM, Adam Jelinek wrote:
> I agree with the best effort type of conversion, and only being able to
> handle JSON array's that conform to an SQL array. With that said I would
> love to collaborate with you on this, but there is one thing holding me
> back. The current c
I agree with the best effort type of conversion, and only being able to
handle JSON array's that conform to an SQL array. With that said I would
love to collaborate with you on this, but there is one thing holding me
back. The current company I work for (an insurance company) says it is a
conflict
On Wed, Sep 25, 2013 at 6:25 AM, Andres Freund wrote:
> On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
> > On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> > > David Rowley escribió:
> > >
> > > > I do see a 15-18% slow down with the patched version, so perhaps
> I'll need
> > > > to look
Dear Robert,
(1) ...
I really don't think it's a good idea to change the default behavior.
We've had many discussions about how the overhead of gettimeofday() can
sometimes be surprisingly large; I don't think we should assume it's
guaranteed to be small in this case.
Also, changing establ
* Robert Haas (robertmh...@gmail.com) wrote:
> Now I admit that's an arguable point. We could certainly define an
> intermediate notion of equality that is more equal than whatever =
> does, but not as equal as exact binary equality.
I suggested it up-thread and don't recall seeing a response, so
Hello Noah,
meet all those goals simultaneously with simpler code, can we not?
int64 wait = (int64) (throttle_delay *
Min(7.0, -log(1 - pg_erand48(thread->random_state;
If you truncate roughly the multipler, as it is done here with "min", you
nece
On 2013-09-24 19:56:32 +0200, Andres Freund wrote:
> On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> > David Rowley escribió:
> >
> > > I do see a 15-18% slow down with the patched version, so perhaps I'll need
> > > to look to see if I can speed it up a bit, although I do feel this
> > > be
On 2013-09-24 12:19:51 -0400, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund wrote:
> >> > Hm, I guess you dont't want to add it to global/ or so because of the
> >> > mmap implementation where you presumably scan the directory?
> >>
> >> Yes, and also because I thought this
On Tue, Sep 24, 2013 at 1:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost wrote:
>> > It wouldn't address my concerns anyway, which are around these binary
>> > operators and the update-in-place approach being risky and
On 2013-09-24 13:51:04 -0300, Alvaro Herrera wrote:
> David Rowley escribió:
>
> > I do see a 15-18% slow down with the patched version, so perhaps I'll need
> > to look to see if I can speed it up a bit, although I do feel this
> > benchmark is not quite a normal workload.
>
> Ouch. That's cert
All,
I've send kernel.org a message that we're keen on seeing these changes
get committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh Berk
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh B
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost wrote:
> > It wouldn't address my concerns anyway, which are around these binary
> > operators and the update-in-place approach being risky and setting us up
> > for problems down the road.
>
> I think
On Sat, Sep 14, 2013 at 11:14 AM, Abhijit Menon-Sen wrote:
> Hi.
>
> This is a cleaned-up and rebased version of the bitmap index patch from
> Gavin Sherry, later revised by Gianni Ciolli and Gabriele Bartolini, and
> others including Daniel Bausch.
>
> I've been working on this patch for a while,
David Rowley escribió:
> I do see a 15-18% slow down with the patched version, so perhaps I'll need
> to look to see if I can speed it up a bit, although I do feel this
> benchmark is not quite a normal workload.
Ouch. That's certainly way too much. Is the compiler inlining
process_log_prefix_p
On Tue, Sep 24, 2013 at 12:30 PM, Alvaro Herrera
wrote:
> I mean, if that 1kB limit is the only quarrel you have with this patch,
> I'm happy.
You should probably be happy, then. :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost wrote:
> It wouldn't address my concerns anyway, which are around these binary
> operators and the update-in-place approach being risky and setting us up
> for problems down the road.
I think that if you want to hold up a bug fix to a feature that's
Peter Eisentraut wrote:
> In the source code, I'm dubious about the use of is_dml_trigger. I can
> see where you are coming from, but in most of the code, a trigger is a
> trigger and an event trigger is an event trigger. Let's not introduce
> more terminology.
>
> Other opinions on that?
I'm
Robert Haas escribió:
> On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
> wrote:
> > Here's an updated version; this mainly simplifies code, per comments
> > from Andres (things were a bit too baroque in places due to the way the
> > code had evolved, and I hadn't gone over it to simplify it).
> >
On Fri, Sep 20, 2013 at 7:44 AM, Andres Freund wrote:
>> > Hm, I guess you dont't want to add it to global/ or so because of the
>> > mmap implementation where you presumably scan the directory?
>>
>> Yes, and also because I thought this way would make it easier to teach
>> things like pg_basebac
On 09/24/2013 11:21 AM, Andres Freund wrote:
Not having a consumer of the walsender interface included sounds like a
bad idea to me, even if it were only useful for testing. Now, you could
argue it should be in /contrib - and I wouldn't argue against that
except it shares code with the rest of sr
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > The promise that we'll always return the binary representation of the
> > data that we saw last. When greatest(x,y) comes back 'false' for a
> > MAX(), we then have to go check "well, does the type consider them
> > equal?", b
Hello, hackers.
In this patch I've implemented support for different storage types for cubes.
Now it supports float8, float4, int4, int2, int1. Type stored in the header of
each cube, one for all coordinates. So for cubes with int1 coordinates it can
save up to 8x disk space. Typed cubes can be
On 2013-09-24 11:04:06 -0400, Robert Haas wrote:
> - Requiring a client is a short-sighted design. There's no reason we
> shouldn't *support* having a client, but IMHO it shouldn't be the only
> way to use the feature.
There really aren't many limitations preventing you from doing anything
else.
Stephen Frost wrote:
> Kevin Grittner (kgri...@ymail.com) wrote:
>> Stephen Frost wrote:
>> > I worry that adding these will come back to bite us later
>>
>> How?
>
> User misuse is certainly one consideration,
I think that one has been talked to death already, with the
consensus that we should
Abhijit Menon-Sen wrote:
> I read through the patch, and it looks sensible.
Thanks for the thorough review!
> I would have preferred the ldap_simple_bind_s() call in the HAVE_LIBLDAP
> branch to not be inside an else {} (the if block above returns if there
> is an error anyway), but that's a mino
On Sun, Sep 22, 2013 at 3:40 PM, didier wrote:
> fix a small memory leak in guc-file.l ParseConfigFile
>
> AbsoluteConfigLocation() return a strdup string but it's never free or
> referenced outside ParseConfigFile
>
> Courtesy Valgrind and Noah Misch MEMPOOL work.
I'd like to look at this, but I
On Tue, Sep 24, 2013 at 4:15 AM, Andres Freund wrote:
> There needs to be a client acking the reception of the data in some
> form. There's currently two output methods, SQL and walstreamer, but
> there easily could be further, it's basically two functions you have
> write.
>
> There are several r
On Tue, Sep 24, 2013 at 5:14 AM, Andres Freund wrote:
> Various messages are discussing semantics around visibility. I by now
> have a hard time keeping track. So let's keep the discussion of the
> desired semantics to this thread.
>
> There have been some remarks about serialization failures in r
On Tue, Sep 24, 2013 at 5:58 AM, Bernd Helmle wrote:
> --On 13. September 2013 20:17:19 -0400 Robert Haas
> wrote:
>> You're missing the point. Peter wasn't worried that your patch throws
>> an error; he's concerned about the fact that it doesn't.
>>
>> In PostgreSQL, you can only create the fol
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > I worry that adding these will come back to bite us later
>
> How?
User misuse is certainly one consideration, but I wonder what's going to
happen if we change our internal representation of data (eg: numerics
get changed aga
On Mon, Sep 23, 2013 at 7:05 PM, Peter Geoghegan wrote:
> It suits my purposes to have the value locks be held for only an
> instant, because:
>
> [ detailed explanation ]
I don't really disagree with any of that. TBH, I think the question
of how long value locks (as you call them) are held is g
On Mon, Sep 23, 2013 at 4:15 PM, Tomas Vondra wrote:
> Seems "ready for commiter" to me. I'll wait a few days for others to
> comment, and then I'll update the commitfest page.
Some thoughts:
The documentation doesn't reflect the restriction to type internal.
On a related note, why restrict this
Stephen Frost wrote:
> We need justification to add operators, imv, especially ones that
> expose our internal binary representation of data.
I believe I have done so.
> I worry that adding these will come back to bite us later
How?
> and that we're making promises we won't be able to keep.
On Mon, Sep 23, 2013 at 4:51 PM, Alvaro Herrera
wrote:
> Here's an updated version; this mainly simplifies code, per comments
> from Andres (things were a bit too baroque in places due to the way the
> code had evolved, and I hadn't gone over it to simplify it).
>
> The only behavior change is tha
* Kevin Grittner (kgri...@ymail.com) wrote:
> That's the point, and the whole point. You have not shown that it
> doesn't. You have not shown why adding a 12th non-default opclass
> is a particular problem here (although we have a consensus to use
> different operators, to reserve this operator n
On Mon, Sep 23, 2013 at 5:48 AM, Amit Khandekar
wrote:
>>> The assert levels sound a bit like a user might be confused by these
>>> levels being present at both places: In the RAISE syntax itself, and the
>>> assert GUC level. But I like the syntax. How about keeping the ASSERT
>>> keyword option
On Tue, Sep 24, 2013 at 5:04 AM, David Rowley wrote:
>> So... I guess the question that I'd ask is, if you write a PL/pgsql
>> function that does RAISE NOTICE in a loop a large number of times, can
>> you measure any difference in how fast that function executes on the
>> patch and unpatched code?
On Tue, Sep 24, 2013 at 6:48 AM, Andres Freund wrote:
> On 2013-09-24 12:39:39 +0200, Tom Lane wrote:
>> Andres Freund writes:
>> > So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
>> > boundaries. That means that on x86-64 (64byte cachelines, 24bytes
>> > unpadded lwlock)
> On 24 September 2013 at 13:46 Andrew Dunstan wrote:
>
>
> Feel free to ask questions.
>
> The heart of the API is the event handlers defined in this stuct in
> include/utils/jsonapi.h:
>
> typedef struct JsonSemAction
> {
> void *semstate;
> json_struct_acti
Hello
There is new version of patch. I have separated ordering operators to different
patch (https://commitfest.postgresql.org/action/patch_view?id=1243), fixed
formatting issues and implemented backward compatibility with old-style points
in cube_is_point() and cube_out().
Also comparing outp
On Tue, Sep 24, 2013 at 7:14 AM, Stephen Frost wrote:
>> Of course, you don't need citext, or any other data type with a loose
>> notion of equality, to generate that sort of problem:
> [...]
>> rhaas=# set datestyle = 'german';
>> SET
>
> I'm talking about *planner differences* changing the resul
On 09/23/2013 12:15 PM, Cédric Villemain wrote:
I'm working on it. It appears to have a slight problem or two I want
to fix at the same time, rather than backpatch something broken.
Would you mind sharing the problems you are facing ?
You've noticed the problem about installdirs, I suppose. Th
On 09/24/2013 12:59 AM, Chris Travers wrote:
I am still in the process of wrapping my head around the current JSON
logic. I hope to produce a proof of concept that can later be turned
into a patch. See my previous post on this topic. Again
collaboration is welcome.
Feel free to ask
* Vesa-Matti J Kari (vmk...@cc.helsinki.fi) wrote:
> Many thanks to all who contributed to the fix.
Great! Thanks for the report and the testing.
Stephen
signature.asc
Description: Digital signature
Stephen Frost wrote:
> Skipping out on much of the side-discussion to try and drive at
> the heart of this..
>
> Robert Haas (robertmh...@gmail.com) wrote:
>> I would suggest that you read the referenced papers for details
>> as to how the algorithm works. To make a long story short, they
>> do
Hello,
On Mon, 23 Sep 2013, Stephen Frost wrote:
> I've now committed a fix for this issue.
I cloned the 9.4devel branch and linked my authmilter and a test program
(based on Heikki's earlier design) against the libpq that comes with it.
After hours of pretty extensive stress testing using 2,
From: "Peter Eisentraut"
That assumes that the conversion client encoding -> server encoding ->
NCHAR encoding is not lossy.
Yes, so Tatsuo san suggested to restrict server encoding <-> NCHAR encoding
combination to those with lossless conversion.
I thought one main point of this exercise
On 2013-09-23 14:41:16 +0300, Heikki Linnakangas wrote:
> On 06.06.2013 17:22, Robert Haas wrote:
> >On Thu, May 30, 2013 at 2:29 AM, Andres Freund
> >wrote:
> >>>Yeah, I think it's fine. The patch also looks fine, although I think
> >>>the comments could use a bit of tidying. I guess we need t
* Robert Haas (robertmh...@gmail.com) wrote:
> Your example demonstrates that if a given query can generate two
> different outputs, A and B, based on the same input data, then the
> contents of the materialized view cannot be equal to be A and also
> equal to B. Well, no duh.
Two different outpu
On 2013-09-24 12:39:39 +0200, Tom Lane wrote:
> Andres Freund writes:
> > So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
> > boundaries. That means that on x86-64 (64byte cachelines, 24bytes
> > unpadded lwlock) two lwlocks share a cacheline.
> > In my benchmarks changing
Andres Freund writes:
> So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
> boundaries. That means that on x86-64 (64byte cachelines, 24bytes
> unpadded lwlock) two lwlocks share a cacheline.
Yup.
> In my benchmarks changing the padding to 64byte increases performance in
>
--On 13. September 2013 20:17:19 -0400 Robert Haas
wrote:
You're missing the point. Peter wasn't worried that your patch throws
an error; he's concerned about the fact that it doesn't.
In PostgreSQL, you can only create the following view because test1
has a primary key over column a:
=>
On 09/23/2013 10:38 PM, Stephen Frost wrote:
>
>>> and heavily caveated.
>> I'm not sure what caveats would be needed. It seems to me that a
>> clear description of what it does would suffice. Like all the
>> other non-default opclasses in core, it will be non-default because
>> it is less freque
Hi,
Various messages are discussing semantics around visibility. I by now
have a hard time keeping track. So let's keep the discussion of the
desired semantics to this thread.
There have been some remarks about serialization failures in read
committed transactions. I agree, those shouldn't occur.
On Tue, Sep 24, 2013 at 5:16 AM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 11:28 PM, David Rowley
> wrote:\
> > I put the above results into the attached spreadsheet. On my intel i5
> laptop
> > I'm seeing a slow down of about 1 second per million queries for the
> longer
> > log_line_prefix
On 2013-09-23 21:21:53 -0400, Stephen Frost wrote:
> Here's an example to illustrate what I'm talking about when it comes
> down to "you can't claim that you'll produce exactly what the query
> will always, with these types:"
>
> =# table citext_table;
> id | name
> +---
> 1 | one
>
On 2013-09-23 23:12:53 -0400, Robert Haas wrote:
> What exactly is the purpose of this tool? My impression is that the
> "output" of logical replication is a series of function calls to a
> logical replication plugin, but does that plugin necessarily have to
> produce an output format that gets st
72 matches
Mail list logo
