Awesome, thanks!!
On Fri, Aug 4, 2017 at 11:54 PM, Tom Lane wrote:
> Shay Rojansky writes:
> > Great. Do you think it's possible to backport to the other maintained
> > branches as well, seeing as how this is quite trivial and low-impact?
>
> Already done, will be in next week's minor releases.
Robert,
On Fri, Aug 4, 2017 at 23:17 Robert Haas wrote:
> On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost wrote:
> > Thanks for the patches. I'm planning to push them tomorrow morning
> > after a bit more review and testing. I'll provide an update tomorrow.
>
> Obviously, the part about pushing
On Thu, Aug 3, 2017 at 9:49 PM, Stephen Frost wrote:
> Thanks for the patches. I'm planning to push them tomorrow morning
> after a bit more review and testing. I'll provide an update tomorrow.
Obviously, the part about pushing them Friday morning didn't happen,
and you're running out of time f
On Fri, Aug 4, 2017 at 2:45 PM, Amit Kapila wrote:
> I have not done anything for this comment as it doesn't sound wrong to
> me. I think it is not making much sense in the current code and we
> can remove it or change it as part of the separate patch if you or
> others think so.
I don't get it.
On Thu, Aug 3, 2017 at 8:45 PM, Amit Langote
wrote:
>> 0003 needs a rebase.
>
> Rebased patch attached.
Committed. I think 0004 is a new feature, so I'm leaving that for v11.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On 8/4/17 12:02, Masahiko Sawada wrote:
> To make ALTER SUBSCRIPTION REFRESH being transactional, I prefer
> Petr's proposal. Because it can make ALTER SUBSCRIPTION and DROP
> SUBSCRIPTION stop the table sync workers that are in progress of
> copying data. I'm not sure killing table sync workers in
On Fri, Jul 21, 2017 at 4:51 AM, Alik Khilazhev
wrote:
> (Latest version of pgbench Zipfian patch)
While I'm +1 on this idea, I think that it would also be nice if there
was an option to make functions like random_zipfian() actually return
a value that has undergone perfect hashing. When this opt
I've committed the first-draft release notes for 9.6.4 at
https://git.postgresql.org/pg/commitdiff/03378c4da598840b0520a53580dd7713c95f21c8
(If you prefer to read nicely-marked-up copy, they should be up at
https://www.postgresql.org/docs/devel/static/release-9-6-4.html
in a couple hours from now.
On Mon, Jul 31, 2017 at 10:54 AM, Peter Geoghegan wrote:
> Let's wait to see what difference it makes if Alik's zipfian
> distribution pgbench test case uses unlogged tables. That may gives us a
> good sense of the problem for cases with contention/concurrency.
Yura Sokolov of Postgres Pro perfor
Shay Rojansky writes:
> Great. Do you think it's possible to backport to the other maintained
> branches as well, seeing as how this is quite trivial and low-impact?
Already done, will be in next week's minor releases. (You timed this
bug report well.)
regards, tom lane
On Fri, Aug 4, 2017 at 2:49 PM, Amit Kapila wrote:
> On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas wrote:
>> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
>>> I have increased the number of hash bitmap pages as a separate patch.
>>> I am not completely sure if it is a good idea to directly i
>
> > Doing SSL_CTX_set_session_cache_mode(context, SSL_SESS_CACHE_OFF)
> doesn't
> > have any effect whatsoever - I still have the same issue (session id
> > context uninitialized). I suspect session caching is an entirely
> different
> > feature from session tickets/RFC5077 (although it might sti
On Fri, Aug 4, 2017 at 10:59 PM, Robert Haas wrote:
> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
>> I have increased the number of hash bitmap pages as a separate patch.
>> I am not completely sure if it is a good idea to directly increase it
>> to 1024 as that will increase the size of h
>
> On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote:
> > I'm still not convinced of the risk/problem of simply setting the session
> > id context as I explained above (rather than disabling the optimization),
> > but of course either solution resolves my problem.
>
> How would that do anything? E
On Fri, Aug 4, 2017 at 11:45 PM, Amit Kapila wrote:
> On Fri, Aug 4, 2017 at 11:15 PM, Robert Haas wrote:
>> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
>>> I have implemented the patch with this approach as other approach
>>> require quite extensive changes which I am not sure is the rig
On Fri, Aug 4, 2017 at 11:12 AM, Alvaro Herrera
wrote:
> Interesting. We learned elsewhere that it's better to integrate the
> "!= 0" test as part of the macro definition; so a
> better formulation of this patch would be to change the
> P_INCOMPLETE_SPLIT macro and omit the comparison in the Asse
On Fri, Aug 4, 2017 at 11:15 PM, Robert Haas wrote:
> On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
>> I have implemented the patch with this approach as other approach
>> require quite extensive changes which I am not sure is the right thing
>> to do at this stage.
>
> I think this approach
Masahiko Sawada wrote:
> While hacking the btree code I found two points we can improve in nbtxlog.c.
>
> @@ -135,7 +135,7 @@ _bt_clear_incomplete_split(XLogReaderState
> *record, uint8 block_id)
> Pagepage = (Page) BufferGetPage(buf);
> BTPageOpaque pa
On Fri, Aug 4, 2017 at 9:44 AM, Amit Kapila wrote:
> There is no need to use Parentheses around opaque. I mean there is no
> problem with that, but it is redundant and makes code less readable.
Amit, I'm sure you know this, but just for the benefit of anyone who doesn't:
We often include these
Robert Haas wrote:
> I think this approach is actually better anyway. There's no guarantee
> that VACUUM can be responsive enough to get the job done in time, work
> items or no work items,
Yeah, autovacuum work items don't have a guaranteed response time.
They're okay for things that "ought to
On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
> I have implemented the patch with this approach as other approach
> require quite extensive changes which I am not sure is the right thing
> to do at this stage.
I think this approach is actually better anyway. There's no guarantee
that VACUUM
On Fri, Aug 4, 2017 at 6:22 AM, Amit Kapila wrote:
> I have increased the number of hash bitmap pages as a separate patch.
> I am not completely sure if it is a good idea to directly increase it
> to 1024 as that will increase the size of hashmetapagedata from 960
> bytes to 4544 bytes. Shall we
On Fri, Aug 4, 2017 at 3:38 AM, Amit Langote
wrote:
> The current way to expand inherited tables, including partitioned tables,
> is to use either find_all_inheritors() or find_inheritance_children()
> depending on the context. They return child table OIDs in the (ascending)
> order of those OIDs
>
> Below are the TODOS at this point :
>
> Fix for bug reported by Rajkumar about update with join.
I had explained the root issue of this bug here : [1]
Attached patch includes the fix, which is explained below.
Currently in the patch, there is a check if the tuple is concurrently
deleted by ot
On Fri, Aug 4, 2017 at 5:50 PM, Tom Lane wrote:
> Michael Paquier writes:
>> So I think that the attached patch is able to do the legwork.
>
> I've pushed this into HEAD. It seems like enough of a behavioral
> change that we wouldn't want to back-patch, but IMO it's not too late
> to be making t
On Fri, Aug 4, 2017 at 2:17 AM, Peter Eisentraut
wrote:
> On 7/13/17 23:53, Masahiko Sawada wrote:
>> To summary, I think we now have only one issue; ALTER SUBSCRIPTION is
>> not transactional, 0004 patch is addressing this issue .
>
> We have two competing patches for this issue. This patch move
Michael Paquier writes:
> So I think that the attached patch is able to do the legwork.
I've pushed this into HEAD. It seems like enough of a behavioral
change that we wouldn't want to back-patch, but IMO it's not too late
to be making this type of change in v10. If we wait for the next CF
then
On Mon, Jul 31, 2017 at 8:28 AM, Beena Emerson wrote:
> Thanks for informing.
> PFA the updated patch.
> I have changed the numbering of enum PartitionRangeDatumKind since I
> have to include DEFAULT as well. If you have better ideas, let me
> know.
Why do we need to introduce PARTITION_RANGE_DAT
On Sun, Jul 30, 2017 at 2:07 PM, Ashutosh Sharma wrote:
> Hi,
>
> On Wed, May 10, 2017 at 2:28 PM, Ashutosh Sharma
> wrote:
>> While doing the code coverage testing of v7 patch shared with - [1], I
>> found that there are few lines of code in _hash_next() that are
>> redundant and needs to be re
On Fri, Aug 4, 2017 at 3:24 AM, Fabien COELHO wrote:
>
>>> For the CREATE stuff, the script language is SQL, the command to use it
>>> is
>>> "psql"...
>>
>>
>>> The real and hard part is to fill tables with meaningful pseudo-random
>>> test data which do not violate constraints for any non trivia
On Fri, Aug 4, 2017 at 1:08 PM, Amit Langote
wrote:
> The current way to expand inherited tables, including partitioned tables,
> is to use either find_all_inheritors() or find_inheritance_children()
> depending on the context. They return child table OIDs in the (ascending)
> order of those OIDs
On 01/08/17 23:17, Thomas Munro wrote:
> On Wed, Aug 2, 2017 at 5:36 AM, Peter Eisentraut
> wrote:
>> On 7/16/17 19:09, Thomas Munro wrote:
>>> On Mon, Jul 17, 2017 at 10:26 AM, Thomas Munro
>>> wrote:
ldap-search-filters-v2.patch
>>>
>>> Gah, it would help if I could spell "occurrences" co
On Fri, Aug 4, 2017 at 9:19 AM, AP wrote:
> On Fri, Aug 04, 2017 at 08:21:01AM +0530, Amit Kapila wrote:
>> Note - AP has off list shared the data dump and we (Ashutosh Sharma
>> and me) are able to reproduce the problem and we could see that if we
>> force vacuum via the debugger, then it is able
On Fri, Aug 04, 2017 at 08:21:01AM +0530, Amit Kapila wrote:
> Note - AP has off list shared the data dump and we (Ashutosh Sharma
> and me) are able to reproduce the problem and we could see that if we
> force vacuum via the debugger, then it is able to free overflow pages.
> The exact numbers are
On Fri, Aug 4, 2017 at 8:21 AM, Amit Kapila wrote:
> On Wed, Aug 2, 2017 at 9:04 PM, Robert Haas wrote:
>> On Wed, Jul 12, 2017 at 1:10 AM, Amit Kapila wrote:
> Yes, I also think the same idea can be used, in fact, I have mentioned
> it [1] as soon as you have committed that patch. Do w
Here is an update patch, now renamed the switch to
--load-via-partition-root
and also added the documentation for the new switch into pg_dump as well
as pg_dumpall.
On Fri, Aug 4, 2017 at 7:13 AM, Amit Langote
wrote:
> On 2017/08/04 1:08, David G. Johnston wrote:
> > On Thu, Aug 3, 2017 at 8:5
Hi All,
Consider a parent table which has no child in the current session, but
has temporary children in other sessions.
Session 1
postgres=# create table parent (a int);
CREATE TABLE
Session 2:
postgres=# create temp table temp_child () inherits(parent);
CREATE TABLE
Before commit d3cc37f1d801a
Hi,
While hacking the btree code I found two points we can improve in nbtxlog.c.
@@ -135,7 +135,7 @@ _bt_clear_incomplete_split(XLogReaderState
*record, uint8 block_id)
Pagepage = (Page) BufferGetPage(buf);
BTPageOpaque pageop = (BTPageOpaque)
PageGetSp
On 2017/08/02 19:49, Amit Khandekar wrote:
> On 2 August 2017 at 14:38, Amit Langote wrote:
>>> One approach I had considered was to have find_inheritance_children()
>>> itself lock the children in bound order, so that everyone will have
>>> bound-ordered oids, but that would be too expensive sinc
The current way to expand inherited tables, including partitioned tables,
is to use either find_all_inheritors() or find_inheritance_children()
depending on the context. They return child table OIDs in the (ascending)
order of those OIDs, which means the callers that need to lock the child
tables
40 matches
Mail list logo
