On Tue, Sep 10, 2019 at 8:19 PM Amit Kapila wrote:
>
> On Tue, Jul 23, 2019 at 1:53 PM Masahiko Sawada wrote:
> >
> >
> > To invoke autovacuum even on insert-only tables we would need check
> > the number of inserted tuples since last vacuum. I think we can keep
> > track of the number of
On Fri, Sep 13, 2019 at 09:59:40AM +0530, Amit Kapila wrote:
> I think that is what we have not done in one of the cases pointed by me.
Thinking more about it, I see your point now. HEAP_LOCKED_UPGRADED is
not a direct combination of the other flags and depends on other
conditions, so we cannot
Michael Paquier writes:
> On Thu, Sep 12, 2019 at 03:03:43PM -0400, Tom Lane wrote:
>> The idea of having CREATE COLLATION automatically create a comment
>> is sort of interesting, although it seems pretty orthogonal to
>> normal command behavior. I wonder whether the seeming need for
>> this
On Tue, Sep 10, 2019 at 12:05:25PM +0900, Michael Paquier wrote:
> Attached is an updated patch? How does it look? I have left the
> parts of readfuncs.c for now as there are more issues behind that than
> doing a single switch, short reads are one, long reads a second. And
> the patch already
On Fri, Sep 13, 2019 at 9:00 AM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:24:17PM +0530, Amit Kapila wrote:
> > On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
> > Hmm, I thought when decode_combined flag is set to false means we will
> > display the raw flags set on the tuple
On Fri, Sep 13, 2019 at 8:52 AM Masahiko Sawada wrote:
> On Tue, Sep 10, 2019 at 8:19 PM Amit Kapila wrote:
> >
> >
> > Generally speaking, having more guc's for autovacuum and that too
> > which are in some way dependent on existing guc's sounds bit scary,
> > but OTOH whatever you wrote makes
On Wed, Sep 11, 2019 at 6:08 PM Fabien COELHO wrote:
> Attached an updated version.
I have reviewed the patch and done some basic testing. It works as
per the expectation
I have a few cosmetic comments
1.
+ if (partitions >= 1)
+ {
+ char ff[64];
+ ff[0] = '\0';
+ append_fillfactor(ff,
On Thu, Sep 12, 2019 at 05:24:17PM +0530, Amit Kapila wrote:
> On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
> Hmm, I thought when decode_combined flag is set to false means we will
> display the raw flags set on the tuple without any further
> interpretation. I think that is what is
On Thu, Sep 12, 2019 at 03:03:43PM -0400, Tom Lane wrote:
> The idea of having CREATE COLLATION automatically create a comment
> is sort of interesting, although it seems pretty orthogonal to
> normal command behavior. I wonder whether the seeming need for
> this indicates that we should add a
On Thu, Sep 12, 2019 at 12:14:16PM -0300, Alvaro Herrera wrote:
> Mostly, because I think they're going to cause trouble. Adding a
> parameter in the middle of the list may cause trouble for third-party
> users of TestLib. I propose that we make the routines a bit smarter to
> cope with the API
Hello,
In the following code in execTuples.c, shouldn' srcdesc point to the source
slot's tuple descriptor? The attached fix passes make check. What kind of
failure could this cause?
BTW, I thought that in PostgreSQL coding convention, local variables should be
defined at the top of blocks,
Robert Haas writes:
> I wouldn't feel comfortable with ignoring information leaks that can
> happen with some valid strings but not others. That sounds like
> exactly the sort of information leak that we must prevent. The user
> can write arbitrary stuff in their query, potentially transforming
>
On Thu, Sep 12, 2019 at 1:38 PM Tom Lane wrote:
> In any case, from a purely theoretical viewpoint, such an error message
> *does* constitute a leak of information about the input strings. Whether
> it's a usable leak is very debatable, but that's basically what we've
> got to decide.
I'm
I've been studying At{Sub,}{Abort,Cleanup}_Portals() for the last few
days and have come to the conclusion that the code is not entirely up
to our usual standards. I believe that a good deal of the reason for
this is attributable to the poor quality of the code comments in this
area, although
Hi Chapman,
On 2019-Sep-05, Chapman Flack wrote:
> Are these on your radar to maybe backpatch in this round of activity?
>
> The latest patches I did for 11 and 10 are in
> https://www.postgresql.org/message-id/5D45A44F.8010803%40anastigmatix.net
Thanks! I just pushed these to those branches.
This v6 is just Fabien's v5, rebased over a very minor conflict, and
pgindented. No further changes. I've marked this Ready for Committer.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git
Alvaro Herrera writes:
> I wonder if INFO is better than NOTICE (I think it is).
You're just waving a red flag in front of a bull, you know.
I don't especially like the idea of having this emit a NOTICE;
it's ugly and in-your-face. INFO is right out.
The idea of having CREATE COLLATION
On 2019-09-10 19:26, Tom Lane wrote:
>> I think the way forward here is to get rid of all uses of system() for
>> calling between PostgreSQL programs.
>
> We could do that perhaps, but how are you going to get make to not use
> /bin/sh while spawning subprocesses? I don't think we want to also
>
I just noticed we had two CF items pointing to this thread,
https://commitfest.postgresql.org/24/2119/
https://commitfest.postgresql.org/24/2180/
so I marked the newer one as withdrawn.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
On 2019-Sep-12, Daniel Verite wrote:
> Michael Paquier wrote:
>
> > On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> > > I think it would be nice to have CREATE COLLATION report this
> > > information as feedback in the form of a NOTICE message.
> > > PFA a simple patch
On Thu, Sep 12, 2019 at 11:30 AM Peter Geoghegan wrote:
> I wonder if it's possible to display a localized version of the
> display string in the NOTICE message? Does that work, or could it? For
> example, do you see the message in French?
BTW, I already know for sure that ICU supports localized
Hi,
On 2019-09-12 09:57:55 -0300, Alvaro Herrera wrote:
> On 2019-Sep-12, Tomas Vondra wrote:
>
> > On Wed, Sep 11, 2019 at 09:51:40AM -0300, Alvaro Herrera from 2ndQuadrant
> > wrote:
> > > On 2019-Sep-11, Amit Khandekar wrote:
>
> > > I think doing this all the time would make restore very
Hi,
On 2019-09-12 09:41:02 -0400, Robert Haas wrote:
> On Thu, Sep 12, 2019 at 5:31 AM Tomas Vondra
> wrote:
> > I don't see how the current API could do that transparently - it does
> > track the files, but the user only gets a file descriptor. With just a
> > file descriptor, how could the
On Wed, Sep 11, 2019 at 7:53 AM Daniel Verite wrote:
> The 'locale' or 'lc_collate/lc_ctype' argument of an ICU collation may
> have a complicated syntax, especially with non-deterministic
> collations, and input mistakes in these names will not necessarily be
> detected as such by ICU.
That's a
I wrote:
> I agree with your point that this is a shouldn't-happen corner case.
> The question boils down to, if it *does* happen, does that constitute
> a meaningful information leak? Up to now we've taken quite a hard
> line about what leakproofness means, so deciding that varstr_cmp
> is
Robert Haas writes:
> On Thu, Sep 12, 2019 at 12:19 PM Tom Lane wrote:
>> After burrowing down further, it's visibly the case that
>> text_cmp and varstr_cmp don't leak in the sense of actually
>> reporting any part of their input strings. What they do do,
>> in some code paths, is things like
On Thu, Sep 12, 2019 at 12:19 PM Tom Lane wrote:
> After burrowing down further, it's visibly the case that
> text_cmp and varstr_cmp don't leak in the sense of actually
> reporting any part of their input strings. What they do do,
> in some code paths, is things like
>
> ereport(ERROR,
I wrote:
> Seems like we have two choices:
> 1. Remove the leakproof marking on texteq()/textne(). This
> would, unfortunately, be catastrophic for performance in
> a lot of scenarios where leakproofness matters.
> 2. Fix text_cmp to actually be leakproof, whereupon we might
> as well mark all
Richard Guo wrote:
> On Wed, Sep 11, 2019 at 3:25 PM Antonin Houska
> wrote:
>
>
> Nevertheless, I don't know how to overcome the problems that I
> mentioned
> upthread.
>
>
> Do you mean the problem "the WHERE clause of the subquery didn't
> participate in the SEMI JOIN
> OK, so we have that now. I suppose this spreadsheet now tells us which
> places are useful and which aren't, at least for the queries that you've
> tested. Dowe that mean that we want to get the patch to consider adding
> paths only the places that your spreadsheet says are useful? I'm not
>
Although the following problem does not seem to be exposed in the core, I
think it's still a problem to fix. (I've hit it when implementing a custom
parser for extension configuration file.)
If makeJsonLexContextCstringLen() is passed need_escapes=false,
JsonLexContext.strval is not initialized,
Currently, texteq() and textne() are marked leakproof, while
sibling operations such as textlt() are not. The argument
for that was that those two functions depend only on memcmp()
so they can be seen to be safe, whereas it's a whole lot less
clear that text_cmp() should be considered leakproof.
On 2019-Aug-06, Tatsuo Ishii wrote:
> It's not mentioned below but some bugs including seg fault when
> --enable-casser is enabled was also fixed in this patch.
>
> BTW, I found a bug with min/max support in this patch and I believe
> Yugo is working on it. Details:
>
I think the TestLib.pm changes should be done separately, not together
with the rest of the hacking in this patch.
Mostly, because I think they're going to cause trouble. Adding a
parameter in the middle of the list may cause trouble for third-party
users of TestLib. I propose that we make the
Arseny Sher writes:
> A problem of similar nature can be reproduced with the following
> stripped-down scenario:
> CREATE TABLE pears(f1 int primary key, f2 int);
> INSERT INTO pears SELECT i, i+1 FROM generate_series(1, 100) i;
> CREATE OR REPLACE FUNCTION pears_f(i int) RETURNS int LANGUAGE
Hi,
Our customer encountered a curious scenario. They have a table with GIN
index on expression, which performs multiple joins with this table
itself. These joins employ another btree index for efficiency.
VACUUM FULL on this table fails with error like
ERROR: could not read block 3534 in file
On 2019-Sep-12, Tomas Vondra wrote:
> On Wed, Sep 11, 2019 at 09:51:40AM -0300, Alvaro Herrera from 2ndQuadrant
> wrote:
> > On 2019-Sep-11, Amit Khandekar wrote:
> > I think doing this all the time would make restore very slow -- there's a
> > reason we keep the files open, after all.
>
> How
Alvaro Herrera writes:
> So is anyone working on a patch to use this approach?
It's on my to-do list, but I'm not sure how soon I'll get to it.
regards, tom lane
On 2019-Jul-30, Tom Lane wrote:
> I wrote:
> > This may be arguing for a change in ruleutils' existing behavior,
> > not sure. But when dealing with traditional-style inheritance,
> > I've always thought that Vars above the Append were referring to
> > the parent rel in its capacity as the
Alvaro Herrera writes:
> [ shrug ] It seemed to require no further work, so I just pushed Tom's
> proposed change.
> I added an empty line after the new combined assertion, which makes
> clearer (to me anyway) that the other assertions are unrelated.
Actually, the thing I wanted to add was some
On Wed, Sep 11, 2019 at 9:45 PM Nino Floris wrote:
> > * We currently don't add new extension SQL-script for new extension
> > version (i.e. ltree--1.2.sql). Instead, we provide just a migration
> > script (i.e. ltree--1.1--1.2.sql). This simplifies testing of
> > extension migration – plain
On Wed, Sep 11, 2019 at 3:30 PM Amit Kapila wrote:
> On Sun, Sep 1, 2019 at 1:37 PM Alexander Korotkov
> wrote:
> > I found it weird that CLUSTER/VACUUM FULL don't write visibility map.
> > Attached patch implements writing visibility map in
> > heapam_relation_copy_for_cluster().
> >
> > I've
On Thu, Sep 12, 2019 at 5:31 AM Tomas Vondra
wrote:
> I don't see how the current API could do that transparently - it does
> track the files, but the user only gets a file descriptor. With just a
> file descriptor, how could the code know to do reopen/seek when it's going
> just through the
On Wed, Sep 11, 2019 at 3:34 AM Nikita Glukhov wrote:
> On 09.09.2019 22:47, Alexander Korotkov wrote:
>
> On Mon, Sep 9, 2019 at 8:32 PM Nikita Glukhov wrote:
>
> On 08.09.2019 22:32, Alexander Korotkov wrote:
>
> On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov
> wrote:
>
> I'm going to push
On 2019-Sep-05, James Coleman wrote:
> Yes, planning on it, just a bit behind right now so will likely be a
> few more days at least.
[ shrug ] It seemed to require no further work, so I just pushed Tom's
proposed change.
I added an empty line after the new combined assertion, which makes
Hi,
One of my colleague at EDB, Rajkumar Raghuwanshi, while testing this
feature reported an issue. He reported that if a full base-backup is
taken, and then created a database, and then took an incremental backup,
combining full backup with incremental backup is then failing.
I had a look over
On Thu, Sep 12, 2019 at 8:55 AM Amit Kapila wrote:
> Robert, Thomas, do you have any more suggestions related to this. I
> am planning to commit the above-discussed patch (Forbid Limit node to
> shutdown resources.) coming Monday, so that at least the reported
> problem got fixed.
I think that
=?utf-8?B?0KHQstGP0YLQvtGB0LvQsNCyINCV0YDQvNC40LvQuNC9?=
writes:
> Hi! Few months ago we have encountered
> situation when some quite big open log files were open by Postres despite
> being deleted.This affects free space caluculation in out managed
> PostgreSQL instances.Currently I'm
On Thu, Sep 12, 2019 at 3:39 PM Euler Taveira wrote:
> Em seg, 10 de jun de 2019 às 14:34, Alexander Korotkov
> escreveu:
> >
> > Pushed!
> >
> Alexander, this commit is ok for 11 and so. However, GUC
> strict_word_similarity_threshold does not exist in 9.6 and 10. The
> attached patch revert
On 2019-Sep-12, Andrey Borodin wrote:
> This patch violates one of amcheck design principles: current code
> does not ever take more than one page lock. I do not know: should we
> hold this rule or should we use more deep check?
The check does seem worthwhile to me.
As far as I know, in btree
Hi!
This is a thread to discuss amcheck feature started in other thread[0].
Currently amcheck is scanning every B-tree level. If verification is done with
ShareLock - amcheck will test that each page leftlink is pointing to page with
rightlink backwards.
This is important invariant, in our
On Fri, Aug 2, 2019 at 6:42 PM Andres Freund wrote:
> The obvious problem with this is the slice fetching logic. For slices
> with an offset of 0, it's obviously trivial to implement. For the higher
> slice logic, I'd assume we'd have to fetch the first slice by estimating
> where the start chunk
On Thu, Sep 5, 2019 at 7:53 PM Amit Kapila wrote:
>
> On Mon, Sep 2, 2019 at 4:51 PM Amit Kapila wrote:
> >
> > On Fri, Aug 9, 2019 at 6:29 PM Robert Haas wrote:
> > >
> > >
> > > But beyond that, the issue here is that the Limit node is shutting
> > > down the Gather node too early, and the
Em seg, 10 de jun de 2019 às 14:34, Alexander Korotkov
escreveu:
>
> Pushed!
>
Alexander, this commit is ok for 11 and so. However, GUC
strict_word_similarity_threshold does not exist in 9.6 and 10. The
attached patch revert this part. It should apply cleanly in 9.6 and
10.
--
Euler Taveira
On Thu, Sep 12, 2019 at 4:48 PM Michael Paquier wrote:
>
> On Thu, Sep 12, 2019 at 05:34:08PM +0800, Masahiko Sawada wrote:
> > On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
> >> I think it is better to use a message like "must be superuser to use
> >> pageinspect functions" as this
On Thu, Sep 12, 2019 at 2:05 PM Kyotaro Horiguchi
wrote:
>
> Hello.
>
> At Wed, 11 Sep 2019 17:26:44 +0300, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote in <
a82a896b-93f0-c26c-b941-f56651313...@postgrespro.ru>
> > 10.09.2019 14:42, Asim R P wrote:
> > > Hi Anastasia
> > >
> > > On
Michael Paquier wrote:
> On Wed, Sep 11, 2019 at 04:53:16PM +0200, Daniel Verite wrote:
> > I think it would be nice to have CREATE COLLATION report this
> > information as feedback in the form of a NOTICE message.
> > PFA a simple patch implementing that.
>
> Why is that better than the
Here is a v5.
Few more in icommand_checks subroutine:
Few unwanted code can be removed.
Indeed, more debug and test code.
Attached v6 fixes these, and I checked for remaining scrubs without
finding any.
--
Fabien.diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
On Thu, Sep 12, 2019 at 05:34:08PM +0800, Masahiko Sawada wrote:
> On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
>> I think it is better to use a message like "must be superuser to use
>> pageinspect functions" as this function doesn't take raw page as
>> input. If you see other functions
Hi! Few months ago we have encountered situation when some quite big open log files were open by Postres despite being deleted.This affects free space caluculation in out managed PostgreSQL instances.Currently I'm investigating this issue.We traced some roots to unclosed descriptors in Perl code
On Thu, Sep 12, 2019 at 2:15 PM Fabien COELHO wrote:
>
>
> >> Ok. Rebased version added, with some minor changes to improve readability
> >> (comments, variables).
> >
> > Few comments: [...]
> >
> > Commented line can be removed
> > Commented lines can be removed
> > ??? can be changed to some
At Thu, 12 Sep 2019 09:44:49 +0530, Dilip Kumar wrote
in
> On Wed, Sep 11, 2019 at 6:22 PM Robert Haas wrote:
> > trivial subtransactions. I used this test case:
> >
> > \timing
> > do $$begin for i in 1 .. 1000 loop begin null; exception when
> > others then null; end; end loop; end;$$;
>
> So these are 4 different data types (or classes of data types) that you
> introduce in your extension? Or is that just a conceptual view and it's
> stored in some other way (e.g. normalized in some way)?
>
At the SQL level these 4 durations are not distinguishable. For example for
a tfloat
On Thu, Sep 12, 2019 at 1:56 PM Amit Kapila wrote:
>
> On Wed, Sep 11, 2019 at 8:53 PM Masahiko Sawada wrote:
> >
> > I've attached the updated patch that incorporated all comments. I kept
> > the function as superuser-restricted.
> >
>
> Thanks for the updated patch.
>
> Few more comments:
Hello.
At Wed, 11 Sep 2019 17:26:44 +0300, Anastasia Lubennikova
wrote in
> 10.09.2019 14:42, Asim R P wrote:
> > Hi Anastasia
> >
> > On Thu, Aug 22, 2019 at 9:43 PM Anastasia Lubennikova
> > mailto:a.lubennik...@postgrespro.ru>>
> > wrote:
> > >
> > > But during the review, I found a bug in
On Wed, Sep 11, 2019 at 09:51:40AM -0300, Alvaro Herrera from 2ndQuadrant wrote:
On 2019-Sep-11, Amit Khandekar wrote:
I reproduced the error "exceeded maxAllocatedDescs (492) while trying
to open file ...", which was also discussed about in the thread [1].
This issue is similar but not
On Thu, Sep 12, 2019 at 11:43 AM Michael Paquier wrote:
>
> On Wed, Sep 11, 2019 at 11:22:45PM +0800, Masahiko Sawada wrote:
> > Hmm it will be more consistent with other functions but I think we
> > would need to increase the pageinspect version to 1.8 and need the new
> > sql file to rename the
Ok. Rebased version added, with some minor changes to improve readability
(comments, variables).
Few comments: [...]
Commented line can be removed
Commented lines can be removed
??? can be changed to some suitable heading
tab-complation to be changed to tab-completion
Commented lines can be
On Thu, Sep 12, 2019 at 11:56 AM Fabien COELHO wrote:
>
> > On Wed, Sep 11, 2019 at 10:52:01PM +0200, Fabien COELHO wrote:
> >> AFAICR this is because the coverage was not the same:-) Some backslash
> >> commands just skip silently to the end of the line, so that intermediate
> >> \commands on
On Wed, Sep 11, 2019 at 10:52:01PM +0200, Fabien COELHO wrote:
AFAICR this is because the coverage was not the same:-) Some backslash
commands just skip silently to the end of the line, so that intermediate
\commands on the same line are not recognized/processed the same, so I moved
everything
Hello,
While thinking about looping hash joins (an alternative strategy for
limiting hash join memory usage currently being investigated by
Melanie Plageman in a nearby thread[1]), the topic of parallel query
deadlock hazards came back to haunt me. I wanted to illustrate the
problems I'm aware
On Wed, Sep 11, 2019 at 11:22:45PM +0800, Masahiko Sawada wrote:
> Hmm it will be more consistent with other functions but I think we
> would need to increase the pageinspect version to 1.8 and need the new
> sql file to rename the function name. And it will be for PG12, not
> PG13. If we have to
On Wed, Sep 11, 2019 at 8:53 PM Masahiko Sawada wrote:
>
> I've attached the updated patch that incorporated all comments. I kept
> the function as superuser-restricted.
>
Thanks for the updated patch.
Few more comments:
*
+ if (!superuser())
+ ereport(ERROR,
+ (errcode
73 matches
Mail list logo
