On Fri, Jan 24, 2020 at 8:20 AM Fujii Masao wrote:
>
> On 2020/01/24 15:38, Arthur Zakirov wrote:
> > On 2020/01/24 14:56, Michael Paquier wrote:
> >> On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> >>> It is compiled and passes the tests. There is the documentation and
> >>> it
On 2020/01/24 15:38, Arthur Zakirov wrote:
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There is the documentation and
it is
built too without an error.
It seems that consensus about the
On Wed, Jan 22, 2020 at 05:51:51PM -0300, Ranier Vilela wrote:
> After review the patches and build all and run regress checks for each
> patch, those are the ones that don't break.
There is some progress. You should be careful about your patches,
as they generate compiler warnings. Here is one
Hi
st 22. 1. 2020 v 0:55 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sun, Jan 19, 2020 at 9:57 PM Paul A Jungwirth
> wrote:
> > On Sun, Jan 19, 2020 at 4:38 PM Tom Lane wrote:
> > > True for casts involving concrete types, mainly because we'd like
> > > the
Hi, first patch here and first post to pgsql-hackers. Here goes.
Enclosed please find a patch to tweak the documentation of the ALTER TABLE
page. I believe this patch is ready to be applied to master and backported
all the way to 9.2.
On the ALTER TABLE page, it currently notes that if you
On 2020/01/24 14:56, Michael Paquier wrote:
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
It is compiled and passes the tests. There is the documentation and it is
built too without an error.
It seems that consensus about the returned type was reached and I marked the
patch
On Fri, Jan 24, 2020 at 6:56 AM Michael Paquier wrote:
>
> On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> > It is compiled and passes the tests. There is the documentation and it is
> > built too without an error.
> >
> > It seems that consensus about the returned type was
On Fri, Jan 24, 2020 at 01:28:29PM +0900, Arthur Zakirov wrote:
> It is compiled and passes the tests. There is the documentation and it is
> built too without an error.
>
> It seems that consensus about the returned type was reached and I marked the
> patch as "Ready for Commiter".
+
On Wed, Nov 13, 2019 at 11:39:04AM +0100, Julien Rouhaud wrote:
> (moved to -hackers)
>
> On Tue, Nov 12, 2019 at 9:55 PM Andres Freund wrote:
> >
> > This last point is more oriented towards other PG developers: I wonder
> > if we ought to display buffer statistics for plan time, for EXPLAIN
>
On Wed, Jan 22, 2020 at 12:55:30AM +0300, Alexander Korotkov wrote:
> Thank you for your review!
> The revised patch is attached.
Thanks for the new version.
> On Sun, Jan 19, 2020 at 1:24 PM Michael Paquier wrote:
>> +static int
>> +RestoreArchivedWALFile(const char *path, const char
On Thu, Jan 23, 2020 at 5:51 PM Mahendra Singh Thalor
wrote:
>
> I fixed above comment and updated expected .out files. Attaching
> updated patches.
>
LGTM. I have combined them into the single patch. What do we think
about backpatching this? As there are quite a few changes in the
regression
st 22. 1. 2020 v 0:41 odesílatel Tomas Vondra
napsal:
> Hi,
>
> I did a quick review of this patch today, so let me share a couple of
> comments.
>
> Firstly, the patch is pretty large - it has ~270kB. Not the largest
> patch ever, but large. I think breaking the patch into smaller pieces
>
On 2020/01/17 16:05, Fujii Masao wrote:
On 2020/01/17 13:36, Michael Paquier wrote:
Yeah, that should be either ERROR and return a void result, or issue a
WARNING/ERROR (depending on the code path, maybe PANIC?) with a
boolean status returned if there is a WARNING. Mixing both concepts
with an
On Thu, Jan 23, 2020 at 5:40 PM Peter Geoghegan wrote:
> I suppose the alternative is to get the high key of the parent's left
> sibling, rather than going to the parent's parent (i.e. our
> grandparent). That would probably be the best way to get a separator
> key to compare against the high key
On Thu, Jan 23, 2020 at 5:31 PM Peter Geoghegan wrote:
> In summary: I suppose that we can also solve "the cousin problem"
> quite easily, but only for rightmost cousins within a subtree --
> leftmost cousins might be too messy to verify for it to be worth it.
> We don't want to have to jump two
On Wed, Jan 22, 2020 at 6:41 PM Alexander Korotkov
wrote:
> Rebased patch is attached. Sorry for so huge delay.
I really like this patch. Your interest in amcheck is something that
makes me feel good about having put so much work into it myself.
Here are some review comments:
> + /*
> +
On Wed, Jan 22, 2020 at 01:53:32PM +0900, Michael Paquier wrote:
>> @@ -714,9 +714,7 @@ WITH ( MODULUS > class="parameter">numeric_literal, REM
>>
>>SHARE UPDATE EXCLUSIVE lock will be taken for
>>fillfactor, toast and autovacuum storage parameters, as well as the
>> -
On Fri, Jan 24, 2020 at 7:35 AM Mark Dilger
wrote:
>
>
> > On Jan 22, 2020, at 7:00 PM, Mark Dilger
> > wrote:
> >
> > I have this done in my local repo to the point that I can build frontend
> > tools against the json parser that is now in src/common and also run all
> > the check-world
On Fri, Jan 24, 2020 at 11:12 AM Tom Lane wrote:
> I happened to notice this comment in the logic in
> ATAddForeignKeyConstraint that tries to decide if it can skip
> revalidating a foreign-key constraint after a DDL change:
>
> * Since we require that all collations share the same
I happened to notice this comment in the logic in
ATAddForeignKeyConstraint that tries to decide if it can skip
revalidating a foreign-key constraint after a DDL change:
* Since we require that all collations share the same notion of
* equality (which they do, because
Here's a v7 patch, rebased over my recent hacking, and addressing
most of the complaints I raised in <31691.1579648...@sss.pgh.pa.us>.
However, I've got some new complaints now that I've looked harder
at the code:
* It's not exactly apparent to me why this code should be concerned
about
On 2020-Jan-22, Tatsuro Yamada wrote:
> Thanks for reviewing and committing the patch!
> Hope this helps DBA. :-D
I'm sure it does!
> P.S.
> Next up is progress reporting for query execution?!
Actually, I think it's ALTER TABLE.
Also, things like VACUUM could report the progress of the index
On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra
wrote:
> I proposed just ignoring those new indexes because it seems much simpler
> than alternative solutions that I can think of, and it's not like those
> other solutions don't have other issues.
+1.
> For example, I've looked at the "on demand"
Greetings,
Enclosed find a documentation patch that clarifies the behavior of ALTER
SUBSCRIPTION … REFRESH PUBLICATION with new tables; I ran into a situation
today where the docs were not clear that existing tables would not be
re-copied, so remedying this situation.
Should apply back to Pg
On 2020-Jan-23, Bruce Momjian wrote:
> Yes, good point. I think my one concern is that someone might specify
> both keys in the JSON, which would be very odd.
Just make that a reason to raise an error. I think it's even possible
to specify that as a JSON Schema constraint, using a "oneOf"
On Thu, Jan 23, 2020 at 2:08 PM Daniel Verite wrote:
> It could be CSV, which has this problem already solved,
> is easier to parse than JSON, certainly no less popular,
> and is not bound to a specific encoding.
Sure. I don't think that would look quite as nice visually as what I
proposed when
Robert Haas wrote:
> With the format I proposed, you only have to worry that the
> file name might contain a tab character, because in that format, tab
> is the delimiter
It could be CSV, which has this problem already solved,
is easier to parse than JSON, certainly no less popular,
and
On Thu, Jan 23, 2020 at 1:22 PM Bruce Momjian wrote:
> Yes, good point. I think my one concern is that someone might specify
> both keys in the JSON, which would be very odd.
I think that if a tool other than PostgreSQL chooses to generate a
PostreSQL backup manifest, it must take care to do it
On Thu, Jan 23, 2020 at 02:00:23PM -0500, Robert Haas wrote:
> Incidentally, some research seems to suggest that the problem of
> filenames which don't form a valid UTF-8 sequence cannot occur on
> Windows. This blog post may be helpful in understanding the issues:
>
>
Pavel Stehule writes:
> čt 23. 1. 2020 v 17:26 odesílatel Sergiu Velescu
> napsal:
>> I would like to propose a new feature which is missing in PgSQL but quite
>> useful and nice to have (and exists in Oracle and probably in some other
>> RDBMS), I speak about “Database Level” triggers:
On Thu, Jan 23, 2020 at 03:20:27PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Bruce Momjian wrote:
>
> > On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > > Another
> > > > problem, though, is how do you _flag_ file names as being
> > > > base64-encoded? Use another JSON
On 2020-Jan-23, Bruce Momjian wrote:
> On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > > Another
> > > problem, though, is how do you _flag_ file names as being
> > > base64-encoded? Use another JSON field to specify that?
> >
> > Alvaro's proposed solution in the message to
On Thu, Jan 23, 2020 at 01:05:50PM -0500, Robert Haas wrote:
> > Another
> > problem, though, is how do you _flag_ file names as being
> > base64-encoded? Use another JSON field to specify that?
>
> Alvaro's proposed solution in the message to which you replied was to
> call the field either
On Thu, Jan 23, 2020 at 12:49 PM Bruce Momjian wrote:
> Another idea is to use base64 for all non-ASCII file names, so we don't
> need to check if the file name is valid UTF8 before outputting --- we
> just need to check for non-ASCII, which is much easier.
I think that we have the
On Thu, Jan 23, 2020 at 12:24 PM Alvaro Herrera
wrote:
> I do have files with Latin-1-encoded names in my filesystem, even though
> my system is UTF-8, so I understand the problem. I was wondering if it
> would work to encode any non-UTF8-valid name using something like
> base64; the encoded
Alvaro Herrera writes:
> Even whitespace is problematic for some languages, such as Afan,
> mon "Qunxa Garablu";/
> "Naharsi Kudo";/
> "Ciggilta Kudo";/
> (etc) but I think whitespace-splitting is going to be more comprehensible
> in the vast majority of cases, even if
On Thu, Jan 23, 2020 at 02:23:14PM -0300, Alvaro Herrera wrote:
> On 2020-Jan-23, Robert Haas wrote:
>
> > No, that's not it. Suppose that Álvaro Herrera has some custom
> > settings he likes to put on all the PostgreSQL clusters that he uses,
> > so he creates a file álvaro.conf and uses an
On Thu, Nov 14, 2019 at 8:54 AM Sehrope Sarkuni wrote:
> Has the idea of using environment variables (rather than command line
> args) for external commands been brought up before? I couldn't find
> anything in the mailing list archives.
Passing data through environment variables isn't secure.
On 2020-Jan-23, Robert Haas wrote:
> No, that's not it. Suppose that Álvaro Herrera has some custom
> settings he likes to put on all the PostgreSQL clusters that he uses,
> so he creates a file álvaro.conf and uses an "include" directive in
> postgresql.conf to suck in those settings. If he also
On Thu, Jan 23, 2020 at 6:19 AM Daniel Gustafsson wrote:
> A bigger question is how to handle the offline capabilities. pg_checksums can
> enable or disable checksums in an offline cluster, which will put the cluster
> in a state where the pg_control file and the catalog don't match at startup.
čt 23. 1. 2020 v 17:28 odesílatel 曾文旌(义从)
napsal:
>
>
> 2020年1月22日 下午1:29，曾文旌(义从) 写道：
>
>
>
> 2020年1月21日 下午1:43，Pavel Stehule 写道：
>
> Hi
>
> I have a free time this evening, so I will check this patch
>
> I have a one question
>
> + /* global temp table get relstats from localhash */
> + if
On 2020-Jan-14, Alvaro Herrera wrote:
> On 2020-Jan-13, Tom Lane wrote:
>
> > That seems fundamentally wrong. By the time we've queued an object for
> > deletion in dependency.c, we have a lock on it, and we've verified that
> > the object is still there (cf. systable_recheck_tuple calls).
> >
On Wed, Jan 22, 2020 at 10:00 PM Mark Dilger
wrote:
> Hopefully, this addresses Robert’s concern upthread about the filesystem name
> not necessarily being in utf8 format, though I might be misunderstanding the
> exact thrust of his concern. I can think of other possible interpretations
> of
On Tue, 07 Jan 2020 15:57:29 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 23 Dec 2019 15:38:16 +0100, Jehan-Guillaume de Rorthais
> wrote in
> > 1. we could decide to remove this filter to expose the data even when no
> > wal receiver is active. It's the same behavior than
On 2020-Jan-23, Tom Lane wrote:
> That particular case could be improved by stopping at a dash ... but
> since this code is also used to match strings like "A.M.", we can't
> just exclude punctuation in general. Breaking at whitespace seems
> like a reasonable compromise.
Yeah, and there are
čt 23. 1. 2020 v 17:26 odesílatel Sergiu Velescu
napsal:
> Dear PgSQL-Hackers,
>
>
>
> I would like to propose a new feature which is missing in PgSQL but quite
> useful and nice to have (and exists in Oracle and probably in some other
> RDBMS), I speak about “Database Level” triggers:
Dear PgSQL-Hackers,
I would like to propose a new feature which is missing in PgSQL but quite
useful and nice to have (and exists in Oracle and probably in some other
RDBMS), I speak about "Database Level" triggers: BeforePgStart, AfterPgStarted,
OnLogin, OnSuccessfulLogin, BeforePGshutdown,
Alvaro Herrera writes:
> On 2020-Jan-22, Tom Lane wrote:
>> Arthur Zakirov writes:
>>> Shouldn't we just show all remaining string instead of truncating it?
>> That would avoid a bunch of arbitrary decisions, for sure.
>> Anybody have an objection?
> I think it would be clearer to search for
Peter Eisentraut writes:
> On 2020-01-14 02:38, Tom Lane wrote:
>> On reflection, it seems like the best bet for the moment is to
>> remove double-quote from the rl_completer_quote_characters string,
>> which should restore all behavior around double-quoted strings to
>> what it was before. (We
On 2020-Jan-22, Tom Lane wrote:
> Arthur Zakirov writes:
> > On 2020/01/23 7:11, Tom Lane wrote:
> >> Closer examination shows that the "max" argument is pretty bogus as
> >> well. It doesn't do anything except confuse the reader, because there
> >> are no cases where the value passed is less
Re: Tom Lane 2020-01-21 <6994.1579567...@sss.pgh.pa.us>
> > (Putting in support for pkg-config still makes sense, though.)
>
> Perhaps. Are there any platforms where libxml2 doesn't install a
> pkg-config file? What are we supposed to do if there's no pkg-config?
I can't comment on the libxml2
On 2020-01-14 02:38, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
I have found a weird behavior with identifier quoting, which is not the
subject of this patch, but it appears to be affected by it.
I'll think about how to improve this. Given that we're dequoting
filenames explicitly
On 2020/01/22 16:54, Amit Langote wrote:
Fujii-san,
Thanks for taking a look.
On Fri, Jan 10, 2020 at 10:29 AM Fujii Masao wrote:
On Tue, Jan 7, 2020 at 5:15 PM Amit Langote wrote:
I tend to agree that TRUNCATE's permission model for inheritance
should be consistent with that for the
Hi all,
While reviewing one patch, I found that if we give any non-integer string
to atoi (say aa), then it is returning zero(0) as output so we are not
giving any error(assuming 0 as valid argument) and continuing our
operations.
Ex:
Let say, we gave "-P aa" (patch is in review[1]), then it will
At Thu, 23 Jan 2020 21:28:54 +0900 (JST), Kyotaro Horiguchi
wrote in
> > In the same function, I think that setting restBytes to -1 when
> > "useless" is bad style. I would just leave that variable alone when the
> > returned status is not one that receives the number of bytes. So the
> >
Hello, Jehan.
At Wed, 22 Jan 2020 17:47:23 +0100, Jehan-Guillaume de Rorthais
wrote in
> Hi,
>
> First, it seems you did not reply to Alvaro's concerns in your new set of
> patch. See:
>
> https://www.postgresql.org/message-id/20190917195800.GA16694%40alvherre.pgsql
Mmmm. Thank you very
On Thu, 23 Jan 2020 at 10:20, Amit Kapila wrote:
>
> On Wed, Jan 22, 2020 at 8:48 PM Tom Lane wrote:
> >
> > Alvaro Herrera writes:
> > > I wonder if we shouldn't be using errtablecol() here instead of (in
> > > addition to?) patching the errmsg() to include the table name.
> >
> > >
> On 22 Jan 2020, at 23:07, Robert Haas wrote:
>
> On Wed, Jan 22, 2020 at 3:28 PM Magnus Hagander wrote:
>>> I think the argument about adding catalog flags adding overhead is
>>> pretty much bogus. Fixed-width fields in catalogs are pretty cheap.
>>
>> If that's the general view, then yeah
On Sun, Jan 19, 2020 at 2:23 PM Richard Guo wrote:
>
> I realized that there are two patches in this thread that are
> implemented according to different methods, which causes confusion.
>
Both the idea seems to be different. Is the second approach [1]
inferior for any case as compared to the
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
> Ah, I see. I think I got that from ExplainPrintSettings. I've
> corrected
On Wed, 22 Jan 2020 at 12:48, Masahiko Sawada
wrote:
>
> On Wed, 22 Jan 2020 at 11:23, Amit Kapila wrote:
> >
> > On Wed, Jan 22, 2020 at 7:14 AM Masahiko Sawada
> > wrote:
> > >
> > > Thank you for updating the patch. Yeah MAXDEADTUPLES is better than
> > > what I did in the previous version
On Thu, Jan 16, 2020 at 9:41 AM Bruce Momjian wrote:
> On Tue, Jan 14, 2020 at 02:37:48PM +0500, Ahsan Hadi wrote:
> > Summary
> > The patch is pretty good, it works well when there were little data back to
> > the parent node. The patch doesn’t provide parallel FDW scan, it ensures
> > that
On Wed, Jan 22, 2020 at 9:37 AM Georgios Kokolatos wrote:
> My bad, I should have been more clear. I meant that it is preferable to use
> the C99 standard which calls for declaring variables in the scope that you
> need them.
Ah, I see. I think I got that from ExplainPrintSettings. I've
On Wed, Jan 22, 2020 at 03:06:52PM +0900, Amit Langote wrote:
> Oops, really attached this time.
Thanks, applied. There were clearly two grammar mistakes in the first
patch sent by Justin. And your suggestions look fine to me. On top
of that, I have noticed that the indentation of the two
64 matches
Mail list logo
