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
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
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
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
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
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
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 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 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 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 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 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 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
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 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
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
>
> 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 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
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 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
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 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
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 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
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: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 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 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
>
> > 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 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
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 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
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 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
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 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 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 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
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
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.
40 matches
Mail list logo
