On Fri, Jan 22, 2016 at 11:46 PM, Simon Riggs wrote:
> On 22 January 2016 at 16:34, Robert Haas wrote:
>
>
>> For my part, I am not sure the names in the release notes are actually
>> all that helpful.
>
>
> It has one important effect of current interest: establishing the truth
> that multiple
Hi,
The vacuum doesn't recycle the rows obsoleted by update? I don't think
so. In the above vacuum result, I do not delete any rows, but the
vacuum still recycles a fraction of rows, obviously they're obsoleted
by update.
I know plain vacuum (without full option) do not reduce the size of
the who
On Sat, Jan 23, 2016 at 12:13 PM, Jinhua Luo wrote:
>
> Hi All,
>
> Here is my test environment:
>
> postgresql 9.4.5, Ubuntu 14.04, 8 CPU core, 8GB ram, SCSI hard disk
>
> I have a table with 70 columns, and 6 indexes. The data flow is a
> special OLTP model: frequent inserts (2000 tps), and each
On Tue, Jan 12, 2016 at 2:41 PM, Dilip Kumar wrote:
> On Thu, Jan 7, 2016 at 4:53 PM, Andres Freund wrote:
>
>> On 2016-01-07 16:48:53 +0530, Amit Kapila wrote:
>>
>> I think it's a worthwhile approach to pursue. But until it actually
>> fixes the problem of leaving around uninitialized pages I
Hi All,
Here is my test environment:
postgresql 9.4.5, Ubuntu 14.04, 8 CPU core, 8GB ram, SCSI hard disk
I have a table with 70 columns, and 6 indexes. The data flow is a
special OLTP model: frequent inserts (2000 tps), and each inserted row
would be updated very soon (i.e. the number of inserts
On 23 January 2016 at 03:32, Thom Brown wrote:
> On 22 January 2016 at 19:30, Victor Wagner wrote:
>> On Tue, 19 Jan 2016 14:34:54 +
>> Thom Brown wrote:
>>
>>>
>>> The segfault issue I originally reported now appears to be resolved.
>>>
>>> But now I have another one:
>>>
>>> psql
>>> 'post
On 22 January 2016 at 19:30, Victor Wagner wrote:
> On Tue, 19 Jan 2016 14:34:54 +
> Thom Brown wrote:
>
>>
>> The segfault issue I originally reported now appears to be resolved.
>>
>> But now I have another one:
>>
>> psql
>> 'postgresql://thom@127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,1
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This reply will covers a 10,000 foot level review of the feature (some of my
On 01/23/2016 02:35 AM, Michael Paquier wrote:
On Fri, Jan 22, 2016 at 9:41 PM, Greg Stark wrote:
On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra
wrote:
On 01/22/2016 06:45 AM, Michael Paquier wrote:
So, I have been playing with a Linux VM with VMware Fusion and on
ext4 with data=ordered the
On Fri, Jan 22, 2016 at 10:13 PM, David Rowley
wrote:
> On 22 January 2016 at 17:25, Haribabu Kommi wrote:
>> Along with these changes, I added a float8 combine function to see
>> how it works under parallel aggregate, it is working fine for float4, but
>> giving small data mismatch with float8 d
I wrote:
> Dean Rasheed writes:
>> Attached are patches for this and the new functions in degrees, now
>> with POSIX compatible Inf/NaN handling.
> Pushed with minor, mostly cosmetic fixes.
So the early returns from the buildfarm aren't very good:
* tern/sungazer isn't getting exactly 0.5 from
On Fri, Jan 22, 2016 at 9:41 PM, Greg Stark wrote:
> On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra
> wrote:
>> On 01/22/2016 06:45 AM, Michael Paquier wrote:
>>
>>> So, I have been playing with a Linux VM with VMware Fusion and on
>>> ext4 with data=ordered the renames are getting lost if the roo
On 23 January 2016 at 09:44, David Rowley wrote:
> On 23 January 2016 at 09:17, Jeff Janes wrote:
>> On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote:
>>> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley
>>> wrote:
Agreed. So I've attached a version of the patch which does not have any of
David Rowley writes:
> [ prune_group_by_clause_59f15cf_2016-01-15.patch ]
I spent some time looking through this but decided that it needs some work
to be committable.
The main thing I didn't like was that identify_key_vars seems to have a
rather poorly chosen API: it mixes up identifying a rel'
Michael Paquier wrote:
> On Tue, Jan 12, 2016 at 7:56 AM, Elvis Pranskevichus
> wrote:
> > It looks like pg_dump emits incorrect text for domain constraint comments:
> >
> > Assuming the following structure,
>
> Nice catch! qtypname already has fmtId applied to it, so quotes are
> applied twice
Hi,
here is updated version of this patch, calling the messages logical
(decoding) messages consistently everywhere and removing any connection
to standby messages. Moving this to it's own module gave me place to
write some brief explanation about this so the code documentation has
hopefully
On 22 January 2016 at 05:07, Noah Misch wrote:
> On Wed, Jan 20, 2016 at 06:58:24PM +, Simon Riggs wrote:
> > The main problem is the length of the integration phase, which is mostly
> > where nothing happens.
>
> The open items wiki page saw steady change from 30 April to 28 December[1];
> t
Dean Rasheed writes:
> I tried using feclearexcept + fetestexcept as recommended by
> POSIX.1-2008, and that does indeed make the above examples compliant
> on my linux box. Unfortunately it introduces new errors -- asin starts
> generating FE_UNDERFLOW errors for numbers that are really not that
On 23 January 2016 at 09:17, Jeff Janes wrote:
> On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote:
>> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley
>> wrote:
>>> Agreed. So I've attached a version of the patch which does not have any of
>>> the serialise/deserialise stuff in it.
>>
>> I re-re
On 23 January 2016 at 05:36, Tomas Vondra wrote:
> OK. I've looked at the patch again today, and it seems broken bv 45be99f8 as
> the partial paths were not passing the unique_inner to the create_*_path()
> functions. The attached patch should fix that.
>
Thanks for looking at this again, and tha
On Wed, Jan 20, 2016 at 11:06 AM, Robert Haas wrote:
> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley
> wrote:
>> Agreed. So I've attached a version of the patch which does not have any of
>> the serialise/deserialise stuff in it.
>
> I re-reviewed this and have committed most of it with only mino
On 20/01/2016 15:17, Fujii Masao wrote:
>
> When I compiled the PostgreSQL with the patch, I got the following error.
> ISTM that the inclusion of pg_am.h header file is missing in ginfast.c.
>
> ginfast.c: In function 'gin_clean_pending_list':
> ginfast.c:980: error: 'GIN_AM_OID' undeclared (fir
You're editing the expected file for the libpq-regress thingy, but you
haven't added any new lines to test the new capability. I think it'd be
good to add some there. (I already said this earlier in the thread; is
there any reason you ignored it the first time?)
If the test program requires impr
On Tue, 19 Jan 2016 14:34:54 +
Thom Brown wrote:
>
> The segfault issue I originally reported now appears to be resolved.
>
> But now I have another one:
>
> psql
> 'postgresql://thom@127.0.0.1:5530,127.0.0.1:5531,127.0.0.1:5532,127.0.0.1:5533/postgres?hostorder=random&readonly=1&failover_
Hi,
Here's an updated patch improving on how the horizontal and vertical
headers can be sorted.
The discussion upthread went into how it was desirable
to have independant sorts for these headers, possibly driven
by another column, in addition to the query's ORDER BY.
Thus the options now accep
>
>
> So for now, you create an empty partitioned table specifying all the
> partition keys without being able to define any partitions in the same
> statement. Partitions (and partitions thereof, if any) will be created
> using CREATE PARTITION statements, one for each.
>
...and I would assume t
On Fri, Jan 22, 2016 at 7:19 PM, Andres Freund wrote:
> On 2016-01-22 08:18:45 -0600, Jim Nasby wrote:
> > Personally, I don't see why we have our scarcest resource doing what is
> > essentially a project management task, especially when at least one
> > commercial company has offered to donate p
On 2016-01-22 08:50:15 -0600, Jim Nasby wrote:
> I think that's a great way to ensure we shrink the pool of reviewers when
> someone works on a patch and then it goes nowhere.
True, it really sucks. But what's your counter proposal? Commitfests
dragging on forever, and people burning out on contin
On 2016-01-22 08:18:45 -0600, Jim Nasby wrote:
> Personally, I don't see why we have our scarcest resource doing what is
> essentially a project management task, especially when at least one
> commercial company has offered to donate paid staff time.
Because so far all CFs that weren't managed by
On 22 January 2016 at 16:34, Robert Haas wrote:
> For my part, I am not sure the names in the release notes are actually
> all that helpful.
It has one important effect of current interest: establishing the truth
that multiple people and multiple companies are involved in producing and
maintai
On 2016-01-22 08:40:28 -0600, Jim Nasby wrote:
> Ideally reviewers shouldn't be doing any testing, because the tests
> that are part of the patch should answer every question they would
> have, but I don't see that happening until we have a separate
> automation-only target that we don't care how l
On 1/20/16 4:29 PM, Bruce Momjian wrote:
On Wed, Jan 20, 2016 at 09:12:07AM -0800, Joshua Drake wrote:
I just don't buy the Ubuntu release model for our database. Ubuntu is
trying to balance hot features vs stability, while we are really focused
on stability, similar to Debian.
I understand b
On 1/21/16 1:48 PM, Pavel Stehule wrote:
the form of regress tests is not pretty significant issue. Jim's
design is little bit transparent, Marko's is maybe little bit
practical. Both has sense from my opinion, and any hasn't
significant advantage against other.
any possible agr
On 1/20/16 11:40 AM, Tom Lane wrote:
Yeah. It's certainly unfair if someone's patch doesn't get reviewed,
but there are only 24 hours in a day, and we have a limited pool of
reviewer and committer manpower. I think we just have to say that
sometimes life is unfair.
I think that's a great way
On 1/20/16 11:49 PM, Tom Lane wrote:
Michael Paquier writes:
On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote:
What benefit does porting sqlsmith for inclusion in core have? I can
only think of costs, including those that you mentioned.
We have automatic buildfarm coverage on many pl
On 1/21/16 2:29 AM, Amit Kapila wrote:
I also think there should be some way to give credit to CFM, if it is
difficult to do anything related to money, then we can enforce that if
CFM submits any patches for next CF, then those should be prioritised.
Personally, I don't see why we have our scar
On 1/21/16 4:57 PM, Pavel Stehule wrote:
It is not correct - outside PLPython you got a Error (PostgreSQL error
has not any classes), and isn't important the raising class (Error or
SPIError). Inside PL/Python you will got SPIError or successors (based
on SQLcode).
Right. The closest thing we h
Robert Haas writes:
> Actually, though, varstr_levenshtein_less_equal() never gets called
> from parse_relation.c with a distance bound of more than four, so it
> can't actually go quadratic. There's another call in that file to
> varstr_levenshtein(), which in retrospect looks silly, but I'm pre
On 2016-01-22 11:40:24 -0500, Robert Haas wrote:
> It occurred to me to wonder if it might be better to
> propagate logical slots partially or entirely outside the WAL stream,
> because with this design you will end up with the logical slots on
> every replica, including cascaded replicas, and I'm
On Fri, Jan 22, 2016 at 2:46 AM, Craig Ringer wrote:
> It's also going to be necessary to handle what happens when a new failover
> slot (physical or logical) is created on the master where it conflicts with
> the name of a non-failover physical slot that was created on the replica. In
> this case
Hi,
On 12/17/2015 02:17 PM, David Rowley wrote:
On 17 December 2015 at 19:11, Simon Riggs mailto:si...@2ndquadrant.com>> wrote:
On 17 December 2015 at 00:17, Tomas Vondra
mailto:tomas.von...@2ndquadrant.com>>
wrote:
I'd go with match_first_tuple_only.
+1
unique_i
On Fri, Jan 22, 2016 at 10:43 AM, Alvaro Herrera
wrote:
>> If we were to expand that to
>> cover reviewers, we would then be overburdinging that system and we
>> would probably end up removing all names from the release notes.
>
> To me, this reads just as a threat that "if you disturb the waters
Hi Pavel,
Sorry for the lack of review here. I didn't realize I was still the
reviewer for this after it had been moved to another commitfest.
That said, I think I've exhausted my usefulness here as a reviewer.
Marking ready for committer.
.m
--
Sent via pgsql-hackers mailing list (pgsq
On 12/30/2015 06:49 PM, Stas Kelvich wrote:
Hi, Tomáš! Thanks for comprehensive review.
On 15 Dec 2015, at 06:07, Tomas Vondra wrote:
1) It's a bit difficult to judge the usefulness of the API, as I've
always been a mere user of full-text search, and I never had a need
(or courage) to
Bruce Momjian wrote:
> FYI, the fact that feature authors appear in the release notes is an
> artifact of how we track who wrote which stuff, and is not designed for
> rewarding, though it has that effect.
I think you can claim this all you want, but I'd be surprised if anyone
actually believed i
22.01.2016 01:47, David Rowley:
On 20 January 2016 at 06:08, Anastasia Lubennikova
wrote:
18.01.2016 01:02, David Rowley пишет:
On 14 January 2016 at 08:24, David Rowley wrote:
I will try to review the omit_opclass_4.0.patch soon.
Hi, as promised, here's my review of the omit_opclass_4.0
On Wed, Jan 20, 2016 at 11:46 PM, Peter Geoghegan wrote:
> On Wed, Jan 20, 2016 at 8:32 PM, Michael Paquier
> wrote:
>> Perhaps some people are more interested in implementing new
>> features than working on bugs and would just continue hacking and
>> arguing about new features, at least a stabil
On Thu, Jan 21, 2016 at 4:08 PM, David Rowley
wrote:
> It's quite simple to test how much of a win it'll be in the serial
> case today, and yes, it's not much, but it's a bit.
>
> create table t1 as select x from generate_series(1,100) x(x);
> vacuum analyze t1;
> select count(*) from (select
Hi Amit,
thanks for working on this. Seems the last version of the patch was
submitted more than 2 months ago and I believe large parts of it will
get reworked based on the extensive discussion on this list, so I
haven't looked at the code at all.
I'd like to comment on the one thing and tha
On 2016-01-22 21:32:29 +0900, Michael Paquier wrote:
> Group shot with 3), 4) and 5). Well, there is no data loss here,
> putting me in the direction of considering this addition of an fsync
> as an optimization and not a bug.
I think this is an extremely weak argument. The reasoning when exactly
On Fri, Jan 22, 2016 at 8:26 AM, Tomas Vondra
wrote:
> On 01/22/2016 06:45 AM, Michael Paquier wrote:
>
>> So, I have been playing with a Linux VM with VMware Fusion and on
>> ext4 with data=ordered the renames are getting lost if the root
>> folder is not fsync. By killing-9 the VM I am able to r
On Fri, Jan 22, 2016 at 5:26 PM, Tomas Vondra
wrote:
> On 01/22/2016 06:45 AM, Michael Paquier wrote:
>> Here are some comments about your patch after a look at the code.
>>
>> Regarding the additions in fsync_fname() in xlog.c:
>> 1) In InstallXLogFileSegment, rename() will be called only if
>> H
On 22 January 2016 at 17:25, Haribabu Kommi wrote:
> Along with these changes, I added a float8 combine function to see
> how it works under parallel aggregate, it is working fine for float4, but
> giving small data mismatch with float8 data type.
>
> postgres=# select avg(f3), avg(f4) from tbl;
>
Hi,
> First of all, why not merge both patches into one? They aren't too
> big anyway.
Agree.
> I think comments should be changed, to be more informative here.
> Add a comment here too.
> Maybe you should explain this magic number 7 in the comment above?
Done.
> Then, this thread became too
This patch affects header files. By any chance didn't you forget to run
`make clean` after applying it? As we discussed above, when you
change .h files autotools doesn't rebuild dependent .c files:
http://www.postgresql.org/message-id/caf4au4y4mtapp2u3ugtbqd_z0chesjwfnavrgk4umfcwa4e...@mail.gmail.
On Fri, Jan 22, 2016 at 9:26 AM, Tomas Vondra
wrote:
> Hi,
>
> On 01/22/2016 06:45 AM, Michael Paquier wrote:
>
> So, I have been playing with a Linux VM with VMware Fusion and on
>> ext4 with data=ordered the renames are getting lost if the root
>> folder is not fsync. By killing-9 the VM I am a
On 01/22/2016 04:28 AM, Tom Lane wrote:
> Vik Fearing writes:
>> I looked around for other places where this code should be used and
>> didn't find any. I am marking this patch Ready for Committer.
>
> I pushed this with some adjustments, mainly to make sure that the
> erroneous-units errors exa
Hi,
On 01/22/2016 06:45 AM, Michael Paquier wrote:
So, I have been playing with a Linux VM with VMware Fusion and on
ext4 with data=ordered the renames are getting lost if the root
folder is not fsync. By killing-9 the VM I am able to reproduce that
really easily.
Yep. Same experience here (w
58 matches
Mail list logo