On 17.06.2018 03:00, Andres Freund wrote:
On 2018-06-16 23:25:34 +0300, Konstantin Knizhnik wrote:
On 16.06.2018 22:02, Andres Freund wrote:
On 2018-06-16 11:38:59 +0200, Tomas Vondra wrote:
On 06/15/2018 08:01 PM, Andres Freund wrote:
On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik
Hi Alvaro,
>> There was a slight oversight in the twophase_gid length calculation in
>> the XactLogCommitRecord() code path in the cf5a1890592 commit. The
>> corresponding XactLogAbortRecord() code path was ok. PFA, a small
>> patch to fix the oversight.
>
> Forgot to add: maybe it would be
> On 17 Jun 2018, at 14:47, Michael Paquier wrote:
>
> On Thu, Jun 14, 2018 at 08:14:54PM +, Bossart, Nathan wrote:
>> I'll go ahead and mark this as Ready for Committer.
>
> Another thing not mentioned on this thread is that bms_membership is
> faster than bms_num_members by design with
2018-06-16 16:21 GMT+02:00 John Dent :
> Hi folks,
>
> I thought I’d share an update to my pet project, which dynamically
> rewrites queries to target materialized views when they are available and
> can satisfy a query (or part of it) with a lower cost plan.
>
> The extension is now a regular
On Sat, Jun 16, 2018 at 8:51 PM, Alvaro Herrera
wrote:
> I don't necessarily object to the proposed change, but I think you
> should generally wait a bit longer for others to react.
What wait period do you think is appropriate in this case?
The doc section that I removed was a last minute
> "Amit" == Amit Kapila writes:
>> Presumably the problem is that the standby isn't authorized to change
>> the btree index's "entry is dead" bits,
Amit> I don't see anything like that in the code. We use _bt_killitems
Amit> to mark the items as dead and neither that function or any of
On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
> Thoughts?
Okay, this is still an open item. Are there any objections to the
previous patch applied on master and the addition of the following
undefined flags to pg_config.h.win32 for back-branches? Here is the
list of flags
> "Tom" == Tom Lane writes:
Tom> * During recovery we ignore killed tuples and don't bother to kill
them
Tom> * either. We do this because the xmin on the primary node could
easily be
Tom> * later than the xmin on the standby node, so that what the primary
Tom> *
On Thu, Jun 14, 2018 at 08:14:54PM +, Bossart, Nathan wrote:
> I'll go ahead and mark this as Ready for Committer.
Another thing not mentioned on this thread is that bms_membership is
faster than bms_num_members by design with many members, so this change
makes sense to shave a couple of
On 06/17/2018 08:15 AM, Michael Paquier wrote:
On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
Thoughts?
Okay, this is still an open item. Are there any objections to the
previous patch applied on master and the addition of the following
undefined flags to
On Thu, Jun 14, 2018 at 10:38:14PM -0400, Tom Lane wrote:
> David Rowley writes:
>> On 15 June 2018 at 02:42, Tom Lane wrote:
>>> I think that if possible, we should still allow a partitioned table
>>> in which all the rels are temp tables of the current session. What we
>>> have to disallow is
On Fri, Jun 15, 2018 at 05:23:27PM -0400, Robert Haas wrote:
> On Thu, Jun 14, 2018 at 7:43 AM, Magnus Hagander wrote:
>> I still think that the fact that we are still discussing what is basically
>> the *basic concepts* of how this would be set up after we have released
>> beta1 is a clear sign
[ trimming cc's ]
Andrew Gierth writes:
> See index_fetch_heap:
> /*
>* If we scanned a whole HOT chain and found only dead tuples, tell
> index
>* AM to kill its entry for that TID (this will take effect in the next
>* amgettuple call, in index_getnext_tid). We
Andrew Dunstan writes:
>> On Thu, Jun 14, 2018 at 10:49:52AM +0900, Michael Paquier wrote:
>> Okay, this is still an open item. Are there any objections to the
>> previous patch applied on master and the addition of the following
>> undefined flags to pg_config.h.win32 for back-branches? Here
I wrote:
> So I'm now pretty well convinced that this is a good change and we
> should slip it into v11.
I wrote a test case and was about ready to commit this, when I started
wondering about the behavior for fdresult == FUNCDETAIL_MULTIPLE.
That is, suppose that the notation f(x) matches more
On Wed, Jun 13, 2018 at 09:00:47AM +0900, Michael Paquier wrote:
> Note for everybody on this list: I will be out for a couple of days at
> the end of this week, and my intention is to finish wrapping this patch
> at the beginning of next week, with a back-patch down to 9.5 where
> palloc_extended
On Sun, Jun 17, 2018 at 10:57:16AM -0400, Tom Lane wrote:
> If we're just leaving them undefined, isn't this purely cosmetic?
> At least, that was what I understood to be the reasoning for leaving
> such symbols out of pg_config.h.win32 in the past.
>
> I'm on board with making things more
Michael Paquier writes:
> Trying to run regression tests in parallel in ~9.5 leads to spurious
> failures, which is annoying... I had a patch fixing that but I cannot
> put my finger on the thread where this has been discussed.
Yeah, for me parallelized check-world only works in >= 9.6. My
Hi,
On 2018-06-17 22:31:02 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > Trying to run regression tests in parallel in ~9.5 leads to spurious
> > failures, which is annoying... I had a patch fixing that but I cannot
> > put my finger on the thread where this has been discussed.
>
>
On 2018/06/15 20:41, David Rowley wrote:
> On 15 June 2018 at 20:37, Amit Langote wrote:
>> select * from partitioned_table_a
>> union all
>> select * from partitioned_table_b
>>
>> The only thing that changes with the patch is that
>> ExecLockNonLeafAppendTables is called *twice* for the two
On 18 June 2018 at 14:36, Amit Langote wrote:
> On 2018/06/15 20:41, David Rowley wrote:
>> If the top level Append is the UNION ALL one, then there won't be any
>> partitioned_rels. If that's what you mean by no-op then, yeah. There
>> are no duplicate locks already obtained in the parent with
On Wed, Jun 13, 2018 at 4:29 PM, Kato, Sho wrote:
> I add a function called ECPGfreeSQLDA() becasue there is no API for releasing
> the SQLDA stored the result set.
Hello Kato-san,
Thank you for sending the patch!
+ Alternatively, use the standard C library's free() function as
in the
On Mon, Jun 18, 2018 at 10:21 AM, Amit Khandekar wrote:
> Attached is v2 version of the patch. It contains the above
> trigger-related issue fixed.
>
> The updated tuple is passed back using the existing newslot parameter
> of GetTupleForTrigger(). When ExecBRDeleteTriggers() is called using a
>
On Sun, Jun 17, 2018 at 9:33 PM Peter Geoghegan wrote:
> On Sat, Jun 16, 2018 at 8:51 PM, Alvaro Herrera
> wrote:
> > I don't necessarily object to the proposed change, but I think you
> > should generally wait a bit longer for others to react.
>
> What wait period do you think is appropriate in
Hi.
On 2018/06/17 22:11, Michael Paquier wrote:
> On Thu, Jun 14, 2018 at 10:38:14PM -0400, Tom Lane wrote:
>> David Rowley writes:
>>> On 15 June 2018 at 02:42, Tom Lane wrote:
I think that if possible, we should still allow a partitioned table
in which all the rels are temp tables
On Sun, Jun 17, 2018 at 07:33:01PM -0700, Andres Freund wrote:
> On 2018-06-17 22:31:02 -0400, Tom Lane wrote:
>> Yeah, for me parallelized check-world only works in >= 9.6. My (vague)
>> recollection is that multiple fixes were needed to get to that point,
>> so I doubt it's worth trying to fix
Hi,
I have written a code for quick indextuple deletion from an relation by
heap tuple TID. The code relate to "Retail IndexTuple deletion"
enhancement of btree index on postgresql wiki [1].
Briefly, it includes three steps:
1. Key generation for index tuple searching.
2. Index relation search
On Thu, Jun 14, 2018 at 09:50:33AM -0400, Robert Haas wrote:
> On Mon, Jun 11, 2018 at 6:11 PM, Alvaro Herrera
> wrote:
>> I would go as far as suggesting to remove qualifiers that indicate what
>> the file is for (such as "relation mapping file"); relying on the path
>> as indicator of what's
On 11 June 2018 at 15:29, Amit Kapila wrote:
> On Mon, Jun 11, 2018 at 3:02 PM, Amit Kapila wrote:
>> On Thu, Jun 7, 2018 at 1:53 PM, Amit Khandekar
>> wrote:
>>> On 7 June 2018 at 11:44, Amit Kapila wrote:
On Tue, Jun 5, 2018 at 8:03 PM, Amit Khandekar
wrote:
I think
Hi!
On Sat, Jun 16, 2018 at 11:23 PM Darafei "Komяpa" Praliaskouski
wrote:
> It is cool to see this in Postgres 11. However:
>
>>
>> 4) vacuum_cleanup_index_scale_factor can be set either by GUC or reloption.
>> Default value is 0.1. So, by default cleanup scan is triggered after
>> increasing
On Sat, Jun 16, 2018 at 9:29 AM, Robert Haas wrote:
>
> By that logic, we should not have suggested that anyone use table
> inheritance, because they would have to change their configuration
> when we implemented table partitioning. Indeed, switching from table
> inheritance to table
31 matches
Mail list logo
