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.
--
Peter Eisentraut http://
On Tue, Jan 28, 2020 at 11:58 AM Dilip Kumar wrote:
>
> On Tue, Jan 28, 2020 at 11:43 AM Amit Kapila wrote:
> >
> > > > It seems to me that we need to add all of this new handling because
> > > > while taking the decision whether to stream or not we don't know
> > > > whether the txn has changes
On Tue, Jan 21, 2020 at 02:07:30PM +0900, Michael Paquier wrote:
> On Mon, Jan 20, 2020 at 11:00:14AM -0800, Andres Freund wrote:
>> Hm. I'm think testing this with real LSNs is a better idea. What if the
>> node actually already is past FF/ at this point? Quite unlikely,
>> I know, but sti
On 2020-01-28 03:11, Tom Lane wrote:
The other question your example raises is whether we should be trying
to de-accent before comparison, ie was it right for 'Ιανουάριος' to
be treated differently from 'Ιανουαριος'. I don't know enough Greek
to say, but it kind of feels like that should be outs
On Tue, Jan 28, 2020 at 1:30 PM Amit Kapila wrote:
>
> On Tue, Jan 28, 2020 at 11:58 AM Dilip Kumar wrote:
> >
> > On Tue, Jan 28, 2020 at 11:43 AM Amit Kapila
> > wrote:
> > >
> > > > > It seems to me that we need to add all of this new handling because
> > > > > while taking the decision whet
Hello Robert,
I think our concerns are roughly classified into two:
(1) Performance
(2) Consistency
And your "different concern" is rather into (2), I think.
I'm also worried about it, but I have no good answer for now. I suppose
mmap(flags|=MAP_SHARED) called by multiple backend processes
Hello,
On Fri, Dec 27, 2019 at 2:02 PM Masahiko Sawada
wrote:
> On Fri, 27 Dec 2019 at 12:37, yuzuko wrote:
> > As Laurenz commented in this thread, I tried adding option
> > to update parent's statistics during Autovacuum. To do that,
> > I propose supporting 'autovacuum_enabled' option already
Thanks Tom.
I’ll look at it. Probably won’t be able to until after the commitfest closes
though.
d.
> On 28 Jan 2020, at 02:58, Tom Lane wrote:
>
> Dent John writes:
>> I’ve updated the patch, addressed the rescan issue, and restructured the
>> tests.
>> [ pipeline-functionscan-v4.patch
On Tue, Jan 28, 2020 at 1:55 PM Dilip Kumar wrote:
>
> On Tue, Jan 28, 2020 at 1:30 PM Amit Kapila wrote:
> >
> > On Tue, Jan 28, 2020 at 11:58 AM Dilip Kumar wrote:
> > >
> > > On Tue, Jan 28, 2020 at 11:43 AM Amit Kapila
> > > wrote:
> > > >
> > > > > > It seems to me that we need to add all
On 2020-01-23 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_publication.c: GetPublicationRelations() so that any
published partitioned tables are expanded as needed
* Since
Hello.
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 a better job this way too.
Agreed. Anyway
On Tue, 28 Jan 2020 at 16:01, Michael Paquier wrote:
>
> On Tue, Jan 21, 2020 at 02:07:30PM +0900, Michael Paquier wrote:
> > On Mon, Jan 20, 2020 at 11:00:14AM -0800, Andres Freund wrote:
> >> Hm. I'm think testing this with real LSNs is a better idea. What if the
> >> node actually already is pa
On Tue, Jan 28, 2020 at 12:53 PM Mahendra Singh Thalor
wrote:
>
> > > > > 1.
> > > > > -P, --parallel=PARALLEL_DEGREE do parallel vacuum
> > > > >
> > > > > I think, "do parallel vacuum" should be modified. Without specifying
> > > > > -P, we are still doing parallel vacuum so we can use like "d
On Tue, Jan 28, 2020 at 8:56 AM Masahiko Sawada
wrote:
>
> On Sat, 25 Jan 2020 at 15:41, Amit Kapila wrote:
> >
> >
> > I have made few modifications in the patch.
> >
> > 1. I think we should try to block the usage of 'full' and 'parallel'
> > option in the utility rather than allowing the serve
Peter Eisentraut wrote:
> Here is an updated patch set that now also implements the "quick check"
> algorithm from UTR #15 for making IS NORMALIZED very fast in many cases,
> which I had mentioned earlier in the thread.
I found a bug in unicode_is_normalized_quickcheck() which is
trigge
On Tue, Jan 28, 2020 at 9:59 PM Dent John wrote:
> I’ll look at it. Probably won’t be able to until after the commitfest closes
> though.
(We've seen that hidden attachment problem from Apple Mail before,
discussion of the MIME details in the archives somewhere. I have no
idea what GUI interact
> On 28 Jan 2020, at 04:53, Michael Paquier wrote:
> Now, we already mention in the docs which values the min and max
> bounds support, and that the version of OpenSSL used by the backend
> and the frontend are impacted by that depending on what version of
> OpenSSL one or the other link to. The
Hello.
While rebasing a patch, I found that after the commit 38a957316d
(Sorry for overlooking that.), ReadRecord sets randAccess reverse
way. That is, it sets randAccess to false just after a XLogBeginRead()
call. The attached fixes that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software
> On 28 Jan 2020, at 06:36, Michael Paquier wrote:
> I was reviewing the libpq code for the recent SSL protocol patch, and
> noticed two mistakes with dispsize for the following parameters:
> - channel_binding should be at 8, the largest value being "require".
> - gssencmode should be at 8.
>
>
On 28/01/2020 12:44, Kyotaro Horiguchi wrote:
While rebasing a patch, I found that after the commit 38a957316d
(Sorry for overlooking that.), ReadRecord sets randAccess reverse
way. That is, it sets randAccess to false just after a XLogBeginRead()
call. The attached fixes that.
Thanks, applied!
On Tue, 28 Jan 2020 at 17:52, Amit Langote wrote:
>
> Hello,
>
> On Fri, Dec 27, 2019 at 2:02 PM Masahiko Sawada
> wrote:
> > On Fri, 27 Dec 2019 at 12:37, yuzuko wrote:
> > > As Laurenz commented in this thread, I tried adding option
> > > to update parent's statistics during Autovacuum. To do
On Sat, Jan 18, 2020 at 3:51 AM Michael Paquier wrote:
>
> On Fri, Jan 17, 2020 at 05:07:55PM +0100, Julien Rouhaud wrote:
> > Oh indeed. But unless we hold some LWLock during the whole function
> > execution, we cannot guarantee a consistent view right?
>
> Yep. That's possible.
>
> > And isn't
On 2020/01/28 14:05, Thomas Munro wrote:
On Tue, Dec 3, 2019 at 6:56 AM Mark Dilger wrote:
On 11/30/19 5:14 PM, Thomas Munro wrote:
On Sun, Dec 1, 2019 at 12:22 PM Mark Dilger wrote:
These two patches (v3) no longer apply cleanly. Could you please
rebase?
Hi Mark,
Thanks. Here's v4.
At Tue, 28 Jan 2020 13:12:05 +0200, Heikki Linnakangas wrote
in
> On 28/01/2020 12:44, Kyotaro Horiguchi wrote:
> > While rebasing a patch, I found that after the commit 38a957316d
> > (Sorry for overlooking that.), ReadRecord sets randAccess reverse
> > way. That is, it sets randAccess to false
On 2019-12-17 14:25, Julien Rouhaud wrote:
PFA rebased v6, with the following changes:
Some thoughts on this patch set.
I think we are all agreed on the general idea.
0001-0003 seem pretty much OK. Why is pg_depend.refobjversion of type
"name" whereas the previous pg_collation.collversion w
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 putc and puts.
> Will that be a better solut
At Tue, 28 Jan 2020 17:45:47 +0800, Craig Ringer wrote
in
> On Tue, 28 Jan 2020 at 16:01, Michael Paquier wrote:
> >
> > On Tue, Jan 21, 2020 at 02:07:30PM +0900, Michael Paquier wrote:
> > > On Mon, Jan 20, 2020 at 11:00:14AM -0800, Andres Freund wrote:
> > >> Hm. I'm think testing this with r
At Tue, 21 Jan 2020 19:45:10 +0900 (JST), Kyotaro Horiguchi
wrote in
> Hello.
>
> At Mon, 20 Jan 2020 17:24:07 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Separating XLogBeginRead seems reasonable. The annoying recptr trick
> > is no longer needed. In particular some logical-decoding stuf
On Sat, Jan 25, 2020 at 10:16 AM Amit Kapila wrote:
>
> On Fri, Jan 24, 2020 at 9:37 PM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > LGTM. I have combined them into the single patch. What do we think
> > > about backpatching this?
> >
> > No objection to the patch for HEAD, but it does no
On Tue, Jan 28, 2020 at 12:36:41PM +0100, Julien Rouhaud wrote:
On Sat, Jan 18, 2020 at 3:51 AM Michael Paquier wrote:
On Fri, Jan 17, 2020 at 05:07:55PM +0100, Julien Rouhaud wrote:
> Oh indeed. But unless we hold some LWLock during the whole function
> execution, we cannot guarantee a consi
On Tue, Jan 28, 2020 at 2:09 PM Tomas Vondra
wrote:
>
> I agree a separate "leader_id" column is easier to work with, as it does
> not require unnesting and so on.
>
> As for the consistency, I agree we probably can't make this perfect, as
> we're fetching and processing the PGPROC records one by
I made these casual comments. If there's any agreement on their merit, it'd be
nice to implement at least the first for v13.
In <20190818193533.gl11...@telsasoft.com>, I wrote:
> . What do you think about pg_restore --no-tableam; similar to
>--no-tablespaces, it would allow restoring a tab
Oh, interesting, thank you. I believe I know what happened, there is
one unnecessary locking part that eventually gives only problems, plus
one direct access to a page items without _bt_readpage. Will post a
new version soon.
On Mon, Jan 27, 2020 at 3:00 PM Floris Van Nee wrote:
>
> Hi Dmitry,
>
On Tue, Jan 28, 2020 at 02:26:34PM +0100, Julien Rouhaud wrote:
On Tue, Jan 28, 2020 at 2:09 PM Tomas Vondra
wrote:
I agree a separate "leader_id" column is easier to work with, as it does
not require unnesting and so on.
As for the consistency, I agree we probably can't make this perfect, as
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) || \
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
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
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'
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
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 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 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 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
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 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
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 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 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 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 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
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
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
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: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
ú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
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
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:
ú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
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
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
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
ú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
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.
>
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
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
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
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
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 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
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 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 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) || \
>
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
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
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
> 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
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
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
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
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
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 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
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
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 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
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 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 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
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-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
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 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
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
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
>
> 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
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
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
1 - 100 of 134 matches
Mail list logo
