On Tue, Jan 28, 2020 at 6:11 PM Peter Eisentraut
wrote:
> This structure looks good now.
Thanks for taking a look.
> However, it does seem unfortunate that in pg_get_publication_tables() we
> need to postprocess the result of GetPublicationRelations(). Since
> we're already changing the API of
Hello Vik,
Isn't there examples in the documentation which use the default prompts?
If so, should they be updated accordingly?
Good catch!
I thought about the documentation but not the examples therein.
Updated patch attached.
Ok.
Only one transaction prompt example in the whole document
On Tue, Jan 28, 2020 at 04:11:47PM -0500, Robert Haas wrote:
> On Tue, Jan 28, 2020 at 4:06 PM Alvaro Herrera
> wrote:
>> I don't think we have ever expressed it as such, but certainly we prefer
>> postmaster to be super robust ... rather live with a some hundred bytes
>> leak rather than have it
Hi Amit,
Once again I went through this patch set and here are my few comments,
On Thu, 23 Jan 2020 at 11:10, Amit Langote wrote:
>
> On Wed, Jan 22, 2020 at 2:38 PM Amit Langote wrote:
> > Other than that, the updated patch contains following significant changes:
> >
> > * Changed pg_publicati
On Tue, Jan 28, 2020 at 06:06:06PM +0300, Alexey Kondratov wrote:
> On 28.01.2020 15:14, Kyotaro Horiguchi wrote:
>> I agree not to save slots immediately. The code is wrtten as described
>> above. The TAP test is correct.
>
> +1, removing this broken saving code path from pg_replication_slot_adva
Hello Kyotaro,
>"Parallel scan" at the moment means multiple workers fetch unique
>blocks from *one* table in an arbitrated manner. In this sense
>"parallel FDW scan" means multiple local workers fetch unique bundles
>of tuples from *one* foreign table, which means it is running on a
>si
On Tue, Jan 28, 2020 at 03:51:54PM -0500, Robert Haas wrote:
> I quickly reread that thread and I don't see that there's any firm
> consensus there in favor of "read %d of %zu" over "read only %d of %zu
> bytes". Now, if most people prefer the former, so be it, but I don't
> think that's clear from
On Tue, Jan 28, 2020 at 11:29:39AM +0100, Daniel Gustafsson wrote:
> You don't really qualify as the target audience for basic, yet not always
> universally known/understood, sections in the documentation though =)
Likely I don't.
> I've heard enough complaints that it's complicated to set up tha
On Tue, Jan 28, 2020 at 11:57:19AM +0100, Daniel Gustafsson wrote:
> Nice catch! +1 on the attached patch.
Thanks, fixed and backpatched down to 12, where gssencmode has been
added.
--
Michael
signature.asc
Description: PGP signature
On 1/28/20 5:28 PM, Mark Dilger wrote:
>
>
>> +# There doesn't seem to be any easy way to get TestLib to use the binaries
>> from
>> +# our directory, so we hack up a path to our binary and run that
>> directly. This
>> +# seems brittle enough that some other solution should be found, if
>> pos
At Tue, 28 Jan 2020 11:18:14 -0300, Alvaro Herrera
wrote in
> > xlog.c:7329: (similar code exists at line 9332)
> > >ereport(LOG,
> > > (errmsg("redo done at %X/%X",
> > > (uint32) (ReadRecPtr >> 32), (uint32)
> > > ReadRecPtr)));
> > >
At Tue, 28 Jan 2020 11:18:50 -0300, Alvaro Herrera
wrote in
> On 2020-Jan-27, Alvaro Herrera wrote:
>
> > Actually looking again, getRecordTimestamp is looking pretty strange.
> > It looks much more natural by using nested switch/case blocks, as with
> > this diff. I think the compiler does a
2020年1月29日(水) 11:06 Thomas Munro :
>
> On Wed, Jan 29, 2020 at 2:49 PM Kohei KaiGai wrote:
> > 2020年1月29日(水) 4:27 Thomas Munro :
> > > On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai wrote:
> > > FWIW the code in https://commitfest.postgresql.org/26/2325/ ran into
> > > exactly the same problem whil
> On Jan 28, 2020, at 7:38 PM, Mark Dilger wrote:
>
>
>
>> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> While reviewing the partition-wise join patch, I ran into an issue that
>>> exists in master, so rather than responding to that patch, I’m starting
>>> t
> On Jan 28, 2020, at 6:46 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> While reviewing the partition-wise join patch, I ran into an issue that
>> exists in master, so rather than responding to that patch, I’m starting this
>> new thread.
>> I noticed that this seems similar to the proble
On Tue, Jan 28, 2020 at 6:53 PM Tom Lane wrote:
> > FWIW, I noticed that GDB becomes much better at this when you add "set
> > print symbol on" to your .gdbinit dot file about a year ago.
>
> Interesting. But I bet there are platform and version dependencies
> in the mix, too. I'd still not wish
Hello, I added (moved to) -hackers.
At Tue, 28 Jan 2020 19:13:32 +0300, Pavel Suderevsky
wrote in
> But for me it still seems that PostgreSQL has enough information to check
> that no WALs exist for the new timeline to omit searching all the
> possibly-existing WALs.
>
> It can just look throu
Peter Geoghegan writes:
> On Tue, Jan 28, 2020 at 10:09 AM Tom Lane wrote:
>> No. No. Just NO. (A) that's overly complex for developers to use,
>> and (B) you have far too much faith in the debugger producing something
>> useful. (My experience is that it'll fail to render function pointers
>
Mark Dilger writes:
> While reviewing the partition-wise join patch, I ran into an issue that
> exists in master, so rather than responding to that patch, I’m starting this
> new thread.
> I noticed that this seems similar to the problem that was supposed to have
> been fixed in the "Re: COLLAT
Hello,
> Besides the complexity of
> getting that infrastructure in place, an important question is whether
> the current system of applying threshold and scale factor to
> changes_since_analyze should be used as-is for inheritance parents
> (partitioned tables), because if users set those paramet
On Tue, Jan 28, 2020 at 10:09 AM Tom Lane wrote:
> No. No. Just NO. (A) that's overly complex for developers to use,
> and (B) you have far too much faith in the debugger producing something
> useful. (My experience is that it'll fail to render function pointers
> legibly on an awful lot of pl
On Wed, Jan 29, 2020 at 2:49 PM Kohei KaiGai wrote:
> 2020年1月29日(水) 4:27 Thomas Munro :
> > On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai wrote:
> > FWIW the code in https://commitfest.postgresql.org/26/2325/ ran into
> > exactly the same problem while making nearly exactly the same kind of
> > th
2020年1月29日(水) 4:27 Thomas Munro :
>
> On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai wrote:
> > I noticed MemoryContextIsValid() called by various kinds of memory context
> > routines checks its node-tag as follows:
> >
> > #define MemoryContextIsValid(context) \
> > ((context) != NULL && \
> >
On Thu, Jan 16, 2020 at 12:05 PM Peter Geoghegan wrote:
> > It does seem odd to me to treat them differently, but it's possible
> > that this is a reflection of my own lack of understanding. What do
> > other database systems do?
>
> Other database systems treat unique indexes very differently, al
2020年1月29日(水) 2:18 Robert Haas :
>
> On Tue, Jan 28, 2020 at 11:24 AM Tom Lane wrote:
> > I strongly object to having the subtype field be just "char".
> > I want it to be declared "MemoryContextType", so that gdb will
> > still be telling me explicitly what struct type this really is.
> > I reali
On Wednesday, January 29, 2020 3:56 AM (GMT+9), Mike Lissner wrote:
> Hi all, I didn't get any replies to this. Is this the right way to send in a
> patch to the
> docs?
Hello,
Yes, although your current patch does not apply as I tried it in my machine.
But you can still rebase it.
For the revie
2020年1月29日(水) 0:56 Tomas Vondra :
>
> On Tue, Jan 28, 2020 at 11:32:49PM +0900, Kohei KaiGai wrote:
> >2020年1月28日(火) 23:09 Tomas Vondra :
> >>
> >> On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
> >> >Hello,
> >> >
> >> >I noticed MemoryContextIsValid() called by various kinds of mem
While reviewing the partition-wise join patch, I ran into an issue that exists
in master, so rather than responding to that patch, I’m starting this new
thread.
I noticed that this seems similar to the problem that was supposed to have been
fixed in the "Re: COLLATE: Hash partition vs UPDATE” t
On Tue, Jan 28, 2020 at 02:34:07PM -0500, Stephen Frost wrote:
Greetings,
* asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
From: Stephen Frost
> * asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> > This feature erases data area just before it is returned to the
On Tue, Jan 28, 2020 at 1:34 PM Floris Van Nee wrote:
> With Andres' instructions I ran a couple of tests. With your patches I can
> reproduce a speedup of ~3% on single core tests reliably on a dual-socket
> 36-core machine for the pgbench select-only test case.
Thanks for testing!
Attached i
On Sat, Jan 25, 2020 at 11:29 AM Thomas Munro wrote:
> On Thu, Jan 23, 2020 at 9:38 AM Rui DeSousa wrote:
> > Here is two charts comparing a patched and unpatched system.
> > These systems are very large and have just shy of thousand
> > connections each with averages of 20 to 30 active queries c
Thanks for your review. I considered all of this along with your review
comments in another email prior to sending v7 in response to that other email a
few minutes ago.
> On Jan 28, 2020, at 7:17 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> wrote:
>> I’m attaching
Stephen Frost writes:
> On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
>> On the other hand, there's the point that lots of people have probably
>> given out schema-CREATE privilege to users whom they wouldn't necessarily
>> wish to trust with INSTALL privilege. Schema-CREATE is a pretty harmless
> On Jan 28, 2020, at 8:32 AM, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
> wrote:
>> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
>> based on a fresh copy of master.
>
> I think the first question for 0005 is whether want this at all.
>
On Tue, Jan 28, 2020 at 5:21 PM Alvaro Herrera
wrote:
> On 2020-Jan-28, Peter Eisentraut wrote:
>
> > On 2020-01-28 04:05, Mark Dilger wrote:
> > > German uses both Sonnabend and Samstag for Saturday, so don’t you have
> to compare to a list of values anyway?
> >
> > Yeah, good point. If it does
Greetings,
On Tue, Jan 28, 2020 at 16:17 Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
> >> I continue to think that allowing DB owners to decide this is, if not
> >> fundamentally the wrong thing, at least not a feature that anybody has
> >> asked f
>
> I could do some tests with the patch on some larger machines. What exact
> tests do you propose? Are there some specific postgresql.conf settings and
> pgbench initialization you recommend for this? And was the test above just
> running 'pgbench -S' select-only with specific -T, -j and -c par
Em ter., 28 de jan. de 2020 às 18:06, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Jan-28, Robert Haas wrote:
>
> > On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier
> wrote:
> > > No, that's not right. I think that it is possible to loop over
> > > ShmemProtectiveRegion in some
Robert Haas writes:
> On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
>> I continue to think that allowing DB owners to decide this is, if not
>> fundamentally the wrong thing, at least not a feature that anybody has
>> asked for in the past. The feature *I* want in this area is for the
>> super
On Tue, Jan 28, 2020 at 4:06 PM Alvaro Herrera wrote:
> I don't think we have ever expressed it as such, but certainly we prefer
> postmaster to be super robust ... rather live with a some hundred bytes
> leak rather than have it die and take the whole database service down
> for what's essentiall
Em ter., 28 de jan. de 2020 às 17:54, Robert Haas
escreveu:
> On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier
> wrote:
> > No, that's not right. I think that it is possible to loop over
> > ShmemProtectiveRegion in some cases. And actually, your patch is dead
> > wrong because this is some cod
On 2020-Jan-28, Robert Haas wrote:
> On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier wrote:
> > No, that's not right. I think that it is possible to loop over
> > ShmemProtectiveRegion in some cases. And actually, your patch is dead
> > wrong because this is some code called by the postmaster a
Markus Winand writes:
> PostgreSQL does not accept the following standard conforming statement:
>VALUES ROW(1,2), ROW(3,4)
> There is a comment about this in the source code [0]:
> /*
> * We should allow ROW '(' expr_list ')' too, but that seems to require
> * making VALUES a fully reserved w
On 2020-01-28 4:14 a.m., Daniel Verite wrote:
David Zhang wrote:
The error "No space left on device" can be logged by fprintf() which is
redefined as pg_fprintf() when print_aligned_text() is called
Are you sure? I don't find that redefinition. Besides
print_aligned_text() also calls
On Tue, Jan 28, 2020 at 3:28 AM Takashi Menjo
wrote:
> I think our concerns are roughly classified into two:
>
> (1) Performance
> (2) Consistency
>
> And your "different concern" is rather into (2), I think.
Actually, I think it was mostly a performance concern (writes
triggering lots of readi
On Tue, Jan 28, 2020 at 3:52 PM Tom Lane wrote:
> I continue to think that allowing DB owners to decide this is, if not
> fundamentally the wrong thing, at least not a feature that anybody has
> asked for in the past. The feature *I* want in this area is for the
> superuser to be able to decide w
On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier wrote:
> No, that's not right. I think that it is possible to loop over
> ShmemProtectiveRegion in some cases. And actually, your patch is dead
> wrong because this is some code called by the postmaster and it cannot
> use FATAL.
Uh, really? I am
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The minimum committable patch seems like it would just grant the
>> "can install trusted extensions" ability to DB owners, full stop.
> If you're alright with making it something a DB owner can do, what is
> the issue with making i
On Mon, Jan 27, 2020 at 9:03 PM Michael Paquier wrote:
> That's actually not the best fit, because this does not take care of
> the pluralization of the second message if you have only 1 byte to
> read ;)
But ... if you have only one byte to read, you cannot have a short read.
> A second point t
On Tue, Jan 28, 2020 at 3:29 PM Stephen Frost wrote:
> I get that you want to push forward with making this part of the DB
> owner, and I said up-thread that I'd be able to live with that, but I
> still don't understand what the argument is against making it part of
> CREATE instead.
It's a chang
Robert Haas writes:
> On Tue, Jan 28, 2020 at 2:29 PM Tom Lane wrote:
>> Well, yeah, that's exactly my point. But in my book, "refuse to do
>> anything" should be "elog(ERROR)", not "invoke undefined behavior".
>> An actual abort() call might be all right here, in that at least
>> we'd know what
On 2020-01-28 16:47, Juan José Santamaría Flecha wrote:
This patch targets to do something symmetrical to to_char(), which will
just return a single value.
I didn't fully realize while reading this thread that to_char() already
supports localized output and this patch indeed just wants to do t
Hi!
PostgreSQL does not accept the following standard conforming statement:
VALUES ROW(1,2), ROW(3,4)
There is a comment about this in the source code [0]:
/*
* We should allow ROW '(' expr_list ')' too, but that seems to require
* making VALUES a fully reserved word, which will probably bre
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> The patch as I'm proposing it has nothing to do with "CREATE" rights.
> >> You're attacking something different from what I actually want to do.
>
> > Yes, as an aside, I'm a
On Tue, Jan 28, 2020 at 2:29 PM Tom Lane wrote:
> Well, yeah, that's exactly my point. But in my book, "refuse to do
> anything" should be "elog(ERROR)", not "invoke undefined behavior".
> An actual abort() call might be all right here, in that at least
> we'd know what would happen and we could
> On Jan 28, 2020, at 10:55 AM, Mike Lissner
> wrote:
>
> Hi all, I didn't get any replies to this. Is this the right way to send in a
> patch to the docs?
>
Yes, your patch has been received, thanks. I don’t know if anybody is
reviewing it, but typically you don’t hear back on a patch u
Mark Dilger writes:
>> On Jan 28, 2020, at 9:30 AM, Tom Lane wrote:
>> A brute-force answer, if there are few enough cases, is to recognize
>> them regardless of the specific value of LC_TIME. Do we think
>> anybody would notice or care if to_date('Sonnabend', 'TMDay') works
>> even when in a no
Greetings,
* asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> From: Stephen Frost
> > * asaba.takan...@fujitsu.com (asaba.takan...@fujitsu.com) wrote:
> > > This feature erases data area just before it is returned to the OS
> > > (“erase”
> > means that overwrite data area to hid
Robert Haas writes:
> On Tue, Jan 28, 2020 at 1:32 PM Tom Lane wrote:
>> BTW, now that I think about it, CreateDestReceiver is not up to project
>> standards anyway, in that it fails to provide reasonable behavior in
>> the case where what's passed is not a legal value of the enum.
> Well, I mig
On Tue, Jan 28, 2020 at 2:55 PM Kohei KaiGai wrote:
> I noticed MemoryContextIsValid() called by various kinds of memory context
> routines checks its node-tag as follows:
>
> #define MemoryContextIsValid(context) \
> ((context) != NULL && \
> (IsA((context), AllocSetContext) || \
>
> On Jan 28, 2020, at 9:30 AM, Tom Lane wrote:
>
> A brute-force answer, if there are few enough cases, is to recognize
> them regardless of the specific value of LC_TIME. Do we think
> anybody would notice or care if to_date('Sonnabend', 'TMDay') works
> even when in a non-German locale?
I
On Tue, Jan 28, 2020 at 1:32 PM Tom Lane wrote:
> BTW, now that I think about it, CreateDestReceiver is not up to project
> standards anyway, in that it fails to provide reasonable behavior in
> the case where what's passed is not a legal value of the enum.
> What you'll get, if you're lucky, is a
On Tue, Jan 28, 2020 at 1:08 PM Tom Lane wrote:
> > That's because the thing
> > that really matters is the 'methods' array. So what I propose is that
> > we nuke the type field from orbit. If a developer wants to figure out
> > what type of context they've got, they should print
> > context->meth
Hi all, I didn't get any replies to this. Is this the right way to send in
a patch to the docs?
Thanks,
Mike
On Thu, Jan 23, 2020 at 11:01 PM Mike Lissner <
mliss...@michaeljaylissner.com> wrote:
> Hi, first patch here and first post to pgsql-hackers. Here goes.
>
> Enclosed please find a patc
On Wed, Jan 22, 2020 at 11:17 AM k.jami...@fujitsu.com <
k.jami...@fujitsu.com> wrote:
> Hi Ibrar,
>
>
>
> Are you still working on this patch?
>
> Currently the patch does not apply mainly because of
>
> recent commits for parallel vacuum have updated the files in this patch.
>
> Kindly rebase it
I wrote:
> Robert Haas writes:
>> Is the example of CreateDestReceiver() sufficient to show that this is
>> not a problem in practice?
> Dunno. I don't see any warnings about that in the buildfarm, but
> that's not a very large sample of non-gcc compilers.
BTW, now that I think about it, Create
Robert Haas writes:
> On Tue, Jan 28, 2020 at 11:35 AM Tom Lane wrote:
>> 3. Some compilers still don't understand that elog(ERROR) doesn't
>> return, so you need a dummy return. Perhaps pg_unreachable()
>> would do as well, but project style has been the dummy return for
>> a long time ... and
Robert Haas writes:
> On Tue, Jan 28, 2020 at 11:24 AM Tom Lane wrote:
>> I strongly object to having the subtype field be just "char".
>> I want it to be declared "MemoryContextType", so that gdb will
>> still be telling me explicitly what struct type this really is.
>> I realize that you probab
On Mon, Jan 27, 2020 at 4:18 PM Tom Lane wrote:
> Robert Haas writes:
> >>> I do not think that the readability-vs-usefulness tradeoff is going
> >>> to be all that good there, anyway. Certainly for testing purposes
> >>> it's going to be more useful to examine portions of a structured output.
>
út 28. 1. 2020 v 18:13 odesílatel Pavel Stehule
napsal:
>
>
> út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从)
> napsal:
>
>>
>>
>> 2020年1月29日 上午12:40，Pavel Stehule 写道：
>>
>>
>>
>> út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从)
>> napsal:
>>
>>>
>>>
>>> 2020年1月24日 上午4:47，Robert Haas 写道：
>>>
>>> On Sat, J
Mark Dilger writes:
> But then the manual page goes on to say:
>> %E* %O*
>> POSIX locale extensions. The sequences %Ec %EC %Ex %EX %Ey %EY %Od %Oe %OH
>> %OI %Om %OM %OS %Ou %OU %OV %Ow %OW %Oy are supposed to provide alternate
>> representations.
>>
>> Additionally %OB implemented to repres
On Tue, Jan 28, 2020 at 11:35 AM Tom Lane wrote:
> 3. Some compilers still don't understand that elog(ERROR) doesn't
> return, so you need a dummy return. Perhaps pg_unreachable()
> would do as well, but project style has been the dummy return for
> a long time ... and I'm not entirely convinced
On Tue, Jan 28, 2020 at 11:24 AM Tom Lane wrote:
> I strongly object to having the subtype field be just "char".
> I want it to be declared "MemoryContextType", so that gdb will
> still be telling me explicitly what struct type this really is.
> I realize that you probably did that for alignment r
út 28. 1. 2020 v 18:12 odesílatel 曾文旌(义从)
napsal:
>
>
> 2020年1月29日 上午12:40，Pavel Stehule 写道：
>
>
>
> út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从)
> napsal:
>
>>
>>
>> 2020年1月24日 上午4:47，Robert Haas 写道：
>>
>> On Sat, Jan 11, 2020 at 8:51 PM Tomas Vondra
>> wrote:
>>
>> I proposed just ignoring tho
Great job with the patch Peter, it has been even cleaner than before after you
moved the check.
> "Peter Eisentraut" skrev 27. januar 2020
> kl. 12:16:
On Tue, Jan 28, 2020 at 5:26 PM Tom Lane wrote:
>
> Robert Haas writes:
> > On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
> >> FTR this has unfortunately the same result on Thomas' automatic patch
> >> tester, e.g.
> >> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195
út 28. 1. 2020 v 17:01 odesílatel 曾文旌(义从)
napsal:
>
>
> 2020年1月24日 上午4:47，Robert Haas 写道：
>
> 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 th
Robert Haas writes:
> On Tue, Jan 28, 2020 at 10:30 AM Mahendra Singh Thalor
> wrote:
>> Tom Lane already fixed this and committed
>> yesterday(4589c6a2a30faba53d0655a8e).
> Oops. OK, thanks.
Yeah, there were multiple issues here:
1. If a switch is expected to cover all values of an enum type
On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
wrote:
> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
> based on a fresh copy of master.
I think the first question for 0005 is whether want this at all.
Initially, you proposed NOT committing it, but then Andrew reviewed
Robert Haas writes:
> On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
>> FTR this has unfortunately the same result on Thomas' automatic patch
>> tester, e.g.
>> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195#L1968
> That's unfortunate ... but presumably Tom's changes
Robert Haas writes:
> On Tue, Jan 28, 2020 at 10:35 AM Tom Lane wrote:
>> I don't actually believe that private context types in extensions is
>> a very likely use-case, so on the whole I'd just as soon leave this
>> alone. If we did want to do something, I'd vote for one NodeTag
>> code T_Memor
On 2020-Jan-28, Peter Eisentraut wrote:
> On 2020-01-28 04:05, Mark Dilger wrote:
> > German uses both Sonnabend and Samstag for Saturday, so don’t you have to
> > compare to a list of values anyway?
>
> Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag", then
> it's not real
On Tue, Jan 28, 2020 at 10:19 AM Julien Rouhaud wrote:
> FTR this has unfortunately the same result on Thomas' automatic patch
> tester, e.g.
> https://travis-ci.org/postgresql-cfbot/postgresql/builds/642634195#L1968
That's unfortunate ... but presumably Tom's changes took care of this?
--
Rob
On Tue, Jan 28, 2020 at 10:35 AM Tom Lane wrote:
> I don't actually believe that private context types in extensions is
> a very likely use-case, so on the whole I'd just as soon leave this
> alone. If we did want to do something, I'd vote for one NodeTag
> code T_MemoryContext and then a seconda
> On Jan 28, 2020, at 7:47 AM, Juan José Santamaría Flecha
> wrote:
>
> This looks like a POSIX feature that some systems might not like (Windows
> [1]). But if this is something that the patch should aim to, I am fine with a
> RWF and give it another try in the future.
As long as this imp
On Tue, Jan 28, 2020 at 11:32:49PM +0900, Kohei KaiGai wrote:
2020年1月28日(火) 23:09 Tomas Vondra :
On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
>Hello,
>
>I noticed MemoryContextIsValid() called by various kinds of memory context
>routines checks its node-tag as follows:
>
>#defi
On Tue, Jan 28, 2020 at 4:06 PM Mark Dilger
wrote:
>
> I’m not insisting, just asking about the design. If it only works with
> one name supported per weekday per language, and per month per language,
> I’m not going to object. I was just curious if you were going to support
> multiple names an
Tomas Vondra writes:
> On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
>> I noticed MemoryContextIsValid() called by various kinds of memory context
>> routines checks its node-tag as follows:
>> #define MemoryContextIsValid(context) \
>> ((context) != NULL && \
>> (IsA((context), Al
On Tue, Jan 28, 2020 at 10:30 AM Mahendra Singh Thalor
wrote:
> Tom Lane already fixed this and committed
> yesterday(4589c6a2a30faba53d0655a8e).
Oops. OK, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, 28 Jan 2020 at 20:36, Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
> wrote:
> > I can see one warning on HEAD.
> >
> > jsonapi.c: In function ‘json_errdetail’:
> > jsonapi.c:1068:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
On Tue, Jan 28, 2020 at 4:06 PM Robert Haas wrote:
>
> On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
> wrote:
> > I can see one warning on HEAD.
> >
> > jsonapi.c: In function ‘json_errdetail’:
> > jsonapi.c:1068:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
On Mon, Jan 27, 2020 at 3:05 PM Mark Dilger
wrote:
> I’m attaching a new patch set with these three changes including Mahendra’s
> patch posted elsewhere on this thread.
>
> Since you’ve committed your 0004 and 0005 patches, this v6 patch set is now
> based on a fresh copy of master.
OK, so I t
On 28.01.2020 15:14, Kyotaro Horiguchi wrote:
At Tue, 28 Jan 2020 17:45:47 +0800, Craig Ringer wrote
in
On Tue, 28 Jan 2020 at 16:01, Michael Paquier wrote:
So attached is an updated patch which addresses the problem just by
marking a physical slot as dirty if any advancing is done. Some
do
On Mon, Jan 27, 2020 at 2:02 PM Mahendra Singh Thalor
wrote:
> I can see one warning on HEAD.
>
> jsonapi.c: In function ‘json_errdetail’:
> jsonapi.c:1068:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> }
> ^
>
> Attaching a patch to fix warning.
Hmm, I don't get a war
> On Jan 28, 2020, at 6:51 AM, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 2020-01-28 04:05, Mark Dilger wrote:
>>> German uses both Sonnabend and Samstag for Saturday, so don’t you have to
>>> compare to a list of values anyway?
>
>> Yeah, good point. If it doesn't accept both "Son
Peter Eisentraut writes:
> On 2020-01-28 04:05, Mark Dilger wrote:
>> German uses both Sonnabend and Samstag for Saturday, so don’t you have to
>> compare to a list of values anyway?
> Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag",
> then it's not really usable.
If we'
2020年1月28日(火) 23:09 Tomas Vondra :
>
> On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
> >Hello,
> >
> >I noticed MemoryContextIsValid() called by various kinds of memory context
> >routines checks its node-tag as follows:
> >
> >#define MemoryContextIsValid(context) \
> >((contex
On 2020-Jan-27, Alvaro Herrera wrote:
> Actually looking again, getRecordTimestamp is looking pretty strange.
> It looks much more natural by using nested switch/case blocks, as with
> this diff. I think the compiler does a better job this way too.
I hadn't noticed I forgot to attach the diff he
On 2020-Jan-28, Kyotaro Horiguchi wrote:
> At Mon, 27 Jan 2020 18:06:27 -0300, Alvaro Herrera
> wrote in
> > Actually looking again, getRecordTimestamp is looking pretty strange.
> > It looks much more natural by using nested switch/case blocks, as with
> > this diff. I think the compiler does
On Tue, Jan 28, 2020 at 10:55:11AM +0900, Kohei KaiGai wrote:
Hello,
I noticed MemoryContextIsValid() called by various kinds of memory context
routines checks its node-tag as follows:
#define MemoryContextIsValid(context) \
((context) != NULL && \
(IsA((context), AllocSetContext) || \
1 - 100 of 134 matches
Mail list logo
