On 7/14/20 6:32 AM, Bruce Momjian wrote:
On Mon, Jul 6, 2020 at 11:28:28AM -0400, Stephen Frost wrote:
Yeah, thinking about it as a function that inspects partial planner
results, it might be useful for other purposes besides postgres_fdw.
As I said before, I don't think this necessarily has
On Fri, Aug 28, 2020 at 11:46:49AM -0400, Tom Lane wrote:
> Hence I propose 0001 attached. 80% of it is just API additions to allow
> passing down the isTopLevel flag so that we can do the right thing in
> the CLUSTER case; the important change is in vacuum_set_xid_limits.
> (For ease of review, I
On Thu, 2020-08-27 at 17:28 -0700, Peter Geoghegan wrote:
> We have a Postgres 13 open item for Disk-based hash aggregate, which
> is the only non-trivial open item. There is a general concern about
> how often we get disk-based hash aggregation when work_mem is
> particularly low, and recursion se
On Wed, Aug 26, 2020 at 4:21 PM Andy Fan wrote:
>
>
> On Mon, Aug 17, 2020 at 10:12 PM Andy Fan
> wrote:
>
>>
>>
>> On Mon, Jun 22, 2020 at 9:39 AM Tom Lane wrote:
>>
>>> I wrote:
>>> > Nope. The entire reason why we have that kluge is that we don't know
>>> > until much later how many times w
On Sat, Aug 29, 2020 at 12:43 AM Jakub Wartak wrote:
> ... %CPU ... COMMAND
> ... 97.4 ... postgres: startup recovering 00010089
So, what else is pushing this thing off CPU, anyway? For one thing, I
guess it might be stalling while reading the WAL itself, because (1)
we only read
On Fri, Aug 28, 2020 at 1:29 PM Andres Freund wrote:
> It can break HOT chains, plain ctid chains etc, for example. Which, if
> earlier / follower tuples are removed can't be detected anymore at a
> later time.
I think I need a more specific example here to understand the problem.
If the xmax of
On Sat, Aug 29, 2020 at 12:43 AM Jakub Wartak wrote:
> USERPID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> postgres 120935 0.9 0.0 866052 3824 ?Ss 09:47 0:00 postgres:
> checkpointer
> postgres 120936 61.9 0.0 865796 3824 ?Rs 09:47 0:22 postgre
On Fri, Aug 28, 2020 at 2:10 PM Andrey M. Borodin wrote:
> I don't think so. ISTM It's the same problem of xmax just hidden behind detoasing.
> Our regular heap_check was checking xmin\xmax invariants for tables, but
> failed to recognise the problem in toast (while toast was accessible until
>
On Wed, Aug 19, 2020 at 6:28 AM Amul Sul wrote:
> Attached is a rebased on top of the latest master head (# 3e98c0bafb2).
Does anyone, especially anyone named Andres Freund, have comments on
0001? That work is somewhat independent of the rest of this patch set
from a theoretical point of view, an
Em sex., 28 de ago. de 2020 às 03:04, Noah Misch
escreveu:
> On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> > Noah Misch writes:
> > > On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> > >> Looks legit, and at least per commit 13bba02271dc we do fix such
> things,
>
> On Aug 28, 2020, at 11:10 AM, Andrey M. Borodin wrote:
>
>
>
>> 28 авг. 2020 г., в 18:58, Robert Haas написал(а):
>> In the case
>> you mention, I think we should view that as a problem with clog rather
>> than a problem with the table, and thus out of scope.
>
> I don't think so. ISTM I
> 28 авг. 2020 г., в 18:58, Robert Haas написал(а):
> In the case
> you mention, I think we should view that as a problem with clog rather
> than a problem with the table, and thus out of scope.
I don't think so. ISTM It's the same problem of xmax
On 08.07.2020 10:03, Andrey M. Borodin wrote:
2 июля 2020 г., в 17:02, Daniel Gustafsson написал(а):
On 15 May 2020, at 02:03, Kyotaro Horiguchi wrote:
Generally in such cases, condition variables would work. In the
attached PoC, the reader side gets no penalty in the "likely" code
path.
pá 28. 8. 2020 v 8:14 odesílatel Pavel Stehule
napsal:
>
>
> st 26. 8. 2020 v 17:06 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> I simplified access to results of winfuncargs functions by proxy type
>> "typedvalue". This type can hold any Datum value, and allows fast cast to
>> basic buildi
Hi,
On 2020-08-28 12:37:17 -0400, Robert Haas wrote:
> On Mon, Jul 20, 2020 at 4:30 PM Andres Freund wrote:
> > If we really were to do something like this the option would need to be
> > called vacuum_allow_making_corruption_worse or such. Its need to be
> > *exceedingly* clear that it will like
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
> Le 28/08/2020 à 16:52, Stephen Frost a écrit :
> >Using an FDW will often also require having a user mapping and there's
> >no way for that to be accomplished through only GRANT'ing a default
> >role, so I don't think we should mix this speci
On Thu, Aug 27, 2020 at 11:04 PM Noah Misch wrote:
> On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> > It's surely not hard to visualize cases where necessary code could
> > be optimized away if the compiler thinks it's entitled to assume
> > such things.
>
> Good point.
I wonder if w
On Fri, Aug 28, 2020 at 11:56 AM Tom Lane wrote:
> Yeah, I agree that there are way too many copies here. CREATE OPERATOR
> seems sufficient. It also seems like we should just rewrite the typeconv
> and drop_operator examples to use some other operator. We'll have
> to do that eventually anyway
On Mon, Jul 20, 2020 at 4:30 PM Andres Freund wrote:
> If we really were to do something like this the option would need to be
> called vacuum_allow_making_corruption_worse or such. Its need to be
> *exceedingly* clear that it will likely lead to making everything much
> worse.
I don't really und
On Tue, Jul 21, 2020 at 9:21 AM Dilip Kumar wrote:
> In the previous version, the feature was enabled for cluster/vacuum
> full command as well. in the attached patch I have enabled it only
> if we are running vacuum command. It will not be enabled during a
> table rewrite. If we think that it
Thank you for the patch.
My high level review comment:
The patch seems to be implementing a useful and requested feature.
The patch applies cleanly and passes the basic regress tests. Also the
commitfest bot is happy.
A first pass at the code, has not revealed any worthwhile comments.
Please all
Robert Haas writes:
> So, in this version, there are six copies of the deprecation notice
> John wrote, rather than just one. Maybe we need more than one, but I
> doubt we need six. I don't think the CREATE OPERATOR documentation
> needs to mention this both when first introducing the concept and
It strikes me that when we are vacuuming a temporary table (which
necessarily will be one of our own session), we don't really need
to care what the global xmin horizon is. If we're not inside a
user transaction block, then there are no tuples in the table that
could be in-doubt anymore. Neither
On Wed, Aug 19, 2020 at 6:58 PM Alvaro Herrera wrote:
> On 2020-Aug-19, David Rowley wrote:
> > Andres' suggestion:
> > regression=# explain (analyze, costs off, timing off, summary off)
> > select count(*) from tenk1 t1 inner join tenk1 t2 on
> > t1.twenty=t2.unique1;
> >
Le 28/08/2020 à 16:52, Stephen Frost a écrit :
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
Le 28/08/2020 à 15:26, Stephen Frost a écrit :
* Magnus Hagander (mag...@hagander.net) wrote:
On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wro
On Thu, Aug 27, 2020 at 1:07 PM Mark Dilger
wrote:
> Yes, that is better. Attached.
So, in this version, there are six copies of the deprecation notice
John wrote, rather than just one. Maybe we need more than one, but I
doubt we need six. I don't think the CREATE OPERATOR documentation
needs to
> On Aug 27, 2020, at 10:07 PM, Andrey M. Borodin wrote:
>
>
>
>> 25 авг. 2020 г., в 19:36, Mark Dilger
>> написал(а):
>
> Hi Mark!
>
> Thanks for working on this important feature.
>
> I was experimenting a bit with our internal heapcheck and found out that it's
> not helping with tru
On Fri, Aug 28, 2020 at 11:00 AM Robert Haas wrote:
> On Fri, Aug 28, 2020 at 4:44 AM John Naylor
> wrote:
> > On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> > > I'm a bit inclined to kill them both off and standardize on factorial()
> > > (not numeric_fac).
> >
> > +1
>
> Here's a modified
On Fri, Aug 28, 2020 at 4:44 AM John Naylor wrote:
> On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> > I'm a bit inclined to kill them both off and standardize on factorial()
> > (not numeric_fac).
>
> +1
Here's a modified version of John's patch that also describes ! and !!
as deprecated. It
On Sat, 29 Aug 2020 at 02:54, David Rowley wrote:
> I'm open to ideas to make the comparison fairer.
While on that, it's not just queries that don't require the cached
tuple to be deformed that are slower. Here's a couple of example that
do requite both patches to deform the cached tuple:
Some
On Wed, 26 Aug 2020 at 03:52, Andres Freund wrote:
>
> On 2020-08-25 20:48:37 +1200, David Rowley wrote:
> > However, given the correct planner choice, there will never be
> > a gross slowdown due to having the extra node.
>
> There'll be a significant reduction in increase in performance.
So I d
Greetings,
* Gilles Darold (gil...@darold.net) wrote:
> Le 28/08/2020 à 15:26, Stephen Frost a écrit :
> >* Magnus Hagander (mag...@hagander.net) wrote:
> >>On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> >>>* Magnus Hagander (mag...@hagander.net) wrote:
> Without having actually looke
On Fri, Aug 28, 2020 at 4:07 AM Masahiko Sawada
wrote:
> You've removed the description about executing VACUUM with
> DISABLE_PAGE_SKIPPING option on the target relation after using
> pg_surgery functions from the doc but I guess it’s better to recommend
> that in the doc for safety. Could you ple
em sex., 28 de ago. de 2020 às 11:05, Ranier Vilela
escreveu:
> Em sex., 28 de ago. de 2020 às 04:37, Sachin Khanna <
> sachin_kha...@infosys.com> escreveu:
>
>>
>>
>> Now I can see the that libraries are identified in config.log . I also
>> found some error in configuration file as well. Highlig
On Fri, Aug 28, 2020 at 5:55 AM Ashutosh Sharma wrote:
> We can certainly do this way, but I would still prefer having a comparator
> function (tidcmp) here for the reasons that it makes the code look a bit
> cleaner, it also makes us more consistent with the way the comparator
> function argum
Em sex., 28 de ago. de 2020 às 04:37, Sachin Khanna <
sachin_kha...@infosys.com> escreveu:
>
>
> Now I can see the that libraries are identified in config.log . I also
> found some error in configuration file as well. Highlight below.
>
> Please find the attached config.log file for reference.
>
>
On Fri, Aug 28, 2020 at 1:07 AM Andrey M. Borodin wrote:
> I was experimenting a bit with our internal heapcheck and found out that it's
> not helping with truncated CLOG anyhow.
> Will your module be able to gather tid's of similar corruptions?
>
> server/db M # select * from heap_check('pg_toas
Le 28/08/2020 à 15:26, Stephen Frost a écrit :
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
Without having actually looked at the code, definite +1 for this feature.
It's much req
Em sex., 28 de ago. de 2020 às 00:11, Tom Lane escreveu:
>
> In other words, the C standard made a damfool decision and now we need
> to deal with the consequences of that as perpetrated by other fools.
> Still, it's all hypothetical so far --- does anyone have examples of
> actual rather than th
On Fri, Aug 28, 2020 at 2:04 AM Peter Eisentraut
wrote:
> The handling of results of SQL statements executed at the top level
> (a.k.a. direct SQL) is implementation-specific and varies widely in
> practice. More interesting in practice, in terms of functionality and
> also compatibility, are nes
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > Without having actually looked at the code, definite +1 for this feature.
> > > It's much requested...
> >
> > Thanks.
> >
> >
Em sex., 28 de ago. de 2020 às 04:45, escreveu:
>
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, 28 August 2020 03:22, Ranier Vilela
> wrote:
>
> > Hi,
> >
> > Per Coverity.
> >
> > When "Prepare for toasting", it is necessary to turn off the flag
> TOAST_NEEDS_DELETE_OLD,
> > if there
On Fri, 28 Aug 2020 at 08:54, Stephen Frost wrote:
>
> Yes, it's the latter. I'm not really sure about the documentation
> change you're contemplating- have a specific suggestion?
>
Sorry, I was discussing this as if it was an abstract idea, not a concrete
patch. I've just taken a look at the p
Greetings,
* gkokola...@pm.me (gkokola...@pm.me) wrote:
> On Friday, 28 August 2020 15:43, Stephen Frost wrote:
> > > What privileges would the user be left with? Would it be possible to end
> > > up in the same privilege only with a GRANT command?
> >
> > I'm not sure what's being asked here.
>
‐‐‐ Original Message ‐‐‐
On Friday, 28 August 2020 15:43, Stephen Frost wrote:
> Greetings,
>
> - Georgios Kokolatos (gkokola...@protonmail.com) wrote:
>
> > The patch seems to be implementing a useful and requested feature.
> > The patch applies cleanly and passes the basic regre
On Fri, Aug 28, 2020 at 2:43 PM Stephen Frost wrote:
> Greetings,
>
> * Georgios Kokolatos (gkokola...@protonmail.com) wrote:
> > The patch seems to be implementing a useful and requested feature.
> > The patch applies cleanly and passes the basic regress tests. Also the
> commitfest bot is happy
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 28 Aug 2020 at 08:43, Stephen Frost wrote:
> > This would simply REVOKE that role from the user. Privileges
> > independently GRANT'd directly to the user wouldn't be affected. Nor
> > would other role membership.
> >
> > > W
On Fri, 28 Aug 2020 at 08:43, Stephen Frost wrote:
> This would simply REVOKE that role from the user. Privileges
> independently GRANT'd directly to the user wouldn't be affected. Nor
> would other role membership.
>
> > What privileges would the user be left with? Would it be possible to end
On Fri, Aug 28, 2020 at 2:38 PM Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > Without having actually looked at the code, definite +1 for this feature.
> > It's much requested...
>
> Thanks.
>
> > But, should we also have a pg_write_all_data to go along
Hi Thomas, hackers,
>> > To move these writes out of recovery's way, we should probably just
>> > run the bgwriter process during crash recovery. I'm going to look
>> > into that.
>>
>> Sounds awesome.
>
>I wrote a quick and dirty experimental patch to try that. I can't see
>any benefit from it
Greetings,
* Georgios Kokolatos (gkokola...@protonmail.com) wrote:
> The patch seems to be implementing a useful and requested feature.
> The patch applies cleanly and passes the basic regress tests. Also the
> commitfest bot is happy.
>
> A first pass at the code, has not revealed any worthwhil
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> Without having actually looked at the code, definite +1 for this feature.
> It's much requested...
Thanks.
> But, should we also have a pg_write_all_data to go along with it?
Perhaps, but could certainly be a different patch, and it'd
On Fri, 28 Aug 2020 at 10:33, Fujii Masao wrote:
>
>
>
> On 2020/08/27 15:59, Asim Praveen wrote:
> >
> >> On 26-Aug-2020, at 11:10 PM, Fujii Masao
> >> wrote:
> >>
> >> I added the following comments based on the suggestion by Sawada-san
> >> upthread. Thought?
> >>
> >> + * Since this rou
> On 28-Aug-2020, at 7:03 AM, Fujii Masao wrote:
>
> On 2020/08/27 15:59, Asim Praveen wrote:
>>
>> +1. May I suggest the following addition to the above comment (feel free to
>> rephrase / reject)?
>> "If sync_standbys_defined was being set from false to true and we observe it
>> as
>> fals
Hi,
I have done code coverage analysis on the latest patches(v53) and below is
the report for the same.
Highlighted are the files where the coverage modifications were observed.
OS: Ubuntu 18.04
Patch applied on commit : 77c7267c37f7fa8e5e48abda4798afdbecb2b95a
File Name
Coverage
Without logical
On Fri, Aug 28, 2020 at 2:30 AM Stephen Frost wrote:
> Greetings,
>
> There's no shortage of requests and responses regarding how to have a
> 'read all of the data' role in PG, with various hacks involving "GRANT
> ALL" and "ALTER DEFAULT PRIVILEGES" to "solve" this, neither of which
> really wor
> > The tidcmp function can be removed, and ItemPointerCompare used
directly by qsort as:
> >
> > - qsort((void*) tids, ntids, sizeof(ItemPointerData),
tidcmp);
> > + qsort((void*) tids, ntids, sizeof(ItemPointerData),
> > + (int (*) (const void *
Hi, Peter
You gave me two posts for my patch review.
Thank you so much. I'll write all my replies into this post.
>
>
> COMMENT pg_constraint.c (wrong comment?)
>
> - * The new constraint's OID is returned.
> + * The new constraint's OID is returned. (This will be the same as
> + * "conOi
Package libxml2-devel-2.9.1-6.el7.4.ppc64le is already installed.
Thanks and Regards,
SACHIN KHANNA
212 BASIS DBA TEAM OFFSHORE
Office : 204058624
Cell : 9049522511
From: Ranier Vilela
Sent: Thursday, August 27, 2020 6:46 PM
To: PostgreSQL Hackers
Cc: Sachin Khanna
Subject: re: Please help fo
On 2020-07-17 15:55, Masahiko Sawada wrote:
On Fri, 17 Jul 2020 at 11:06, Masahiro Ikeda
wrote:
On 2020-07-16 13:16, Masahiko Sawada wrote:
On Tue, 14 Jul 2020 at 17:24, Masahiro Ikeda
wrote:
I've attached the latest version patches. I've incorporated the
review
comments I got so far a
On Thu, Aug 27, 2020 at 11:16 AM Amit Kapila wrote:
>
> On Wed, Aug 26, 2020 at 11:22 PM Jeff Janes wrote:
> >
> >
> > On Tue, Aug 25, 2020 at 8:58 AM Amit Kapila wrote:
> >
> >>
> >> I am planning
> >> to push the first patch (v53-0001-Extend-the-BufFile-interface) in
> >> this series tomorrow
On Wed, Aug 26, 2020 at 6:57 PM Mark Dilger
wrote:
> I don't have any problem with the changes you made in your patch, but
> building on your changes I also found that the following cleanup causes no
> apparent problems:
>
> -%nonassoc UNBOUNDED /* ideally should have same
>
On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> I'm a bit inclined to kill them both off and standardize on factorial()
> (not numeric_fac).
+1
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pá 28. 8. 2020 v 10:06 odesílatel Masahiro Ikeda
napsal:
> On 2020-08-19 14:48, Drouvot, Bertrand wrote:
> > Hi,
> > On 8/18/20 9:35 AM, Pavel Stehule wrote:
> >
> >> Hi
> >>
> >> út 18. 8. 2020 v 8:54 odesílatel Masahiro Ikeda
> >> napsal:
> >>
> >>> Hi,
> >>>
> I've attached a patch to di
Hi Mark,
-{ oid => '111',
+{ oid => '111', descr => 'factorial',
I see that opr_sanity fails without something here. We explicitly
don't have descriptions of functions that implement deprecated
operators (see setup_description() in initdb.c), but in all other
cases, there are also supported opera
On Fri, Aug 28, 2020 at 10:15:37AM +0200, Dmitry Dolgov wrote:
> Thanks for the patch. It sounds right, so no objections from me. But I
> wonder if something similar has to be done also for
> index_concurrently_swap function?
As of index.c, this already happens:
/* Preserve indisreplident in t
> On Thu, Aug 27, 2020 at 11:57:21AM +0900, Michael Paquier wrote:
>
> I think that this problem is similar to indisclustered, and that we
> had better set indisreplident to false when clearing indisvalid for an
> index concurrently dropped. This would prevent problems with ALTER
> TABLE of course
On Fri, 28 Aug 2020 at 05:14, Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 10:26 PM Ashutosh Sharma
> wrote:
> > Okay, point noted.
>
> I spent some time today working on this patch. I'm fairly happy with
> it now and intend to commit it if nobody sees a big problem with that.
> Per discussion
On 2020-08-19 14:48, Drouvot, Bertrand wrote:
Hi,
On 8/18/20 9:35 AM, Pavel Stehule wrote:
Hi
út 18. 8. 2020 v 8:54 odesílatel Masahiro Ikeda
napsal:
Hi,
I've attached a patch to display individual query in the
pg_stat_activity query field when multiple SQL statements are
currently displa
‐‐‐ Original Message ‐‐‐
On Friday, 28 August 2020 03:22, Ranier Vilela wrote:
> Hi,
>
> Per Coverity.
>
> When "Prepare for toasting", it is necessary to turn off the flag
> TOAST_NEEDS_DELETE_OLD,
> if there is no need to delete external values from the old tuple, otherwise,
> th
70 matches
Mail list logo
