After sending below to pgsql-docs, I noticed if I follow the step
described in the doc[1], generated root.crt lacks below.
X509v3 extensions:
X509v3 Subject Key Identifier:
3B:16:EA:86:0B:7C:E4:7A:16:F2:4E:54:F5:9C:0E:0F:38:02:8C:CF
X509v3 Authority
On Wed, 3 Oct 2018 at 15:58, Madeleine Thompson wrote:
> This diff looks good to me. Also, it applies cleanly against
> abd9ca377d669a6e0560e854d7e987438d0e612e and passes `make
> check-world`.
>
> I agree that this is not suitable for a patch release.
>
Pushed to master. Thanks for the review.
On Fri, Sep 28, 2018 at 5:16 PM Amit Kapila wrote:
>
> On Fri, Sep 28, 2018 at 4:23 AM Michael Paquier wrote:
> >
> > On Thu, Sep 27, 2018 at 07:38:31PM +0530, Amit Kapila wrote:
> > > Okay, I am planning to commit the attached patch tomorrow unless you
> > > or anybody else has any objections to
On Fri, Oct 05, 2018 at 01:38:05PM +0200, Michael Banck wrote:
> It's too late for v11 though at this point I guess?
Unfortunately yes.
> I think it would be easy to also test the -r command-line option, as we
> already create a table.
Good idea. Let's add this test.
> That comment should read
On Sat, Oct 6, 2018 at 2:55 AM Tom Lane wrote:
>
> My initial thought was that we should just re-mark transaction_timestamp()
> as parallel-restricted and call it a day, but we'd then have to do the
> same for SQLValueFunction, which is not much fun because it does have
> variants that are paralle
so 6. 10. 2018 v 13:47 odesílatel Amit Kapila
napsal:
> On Sat, Oct 6, 2018 at 2:55 AM Tom Lane wrote:
> >
> > My initial thought was that we should just re-mark
> transaction_timestamp()
> > as parallel-restricted and call it a day, but we'd then have to do the
> > same for SQLValueFunction, wh
On 06.10.2018 00:25, Tom Lane wrote:
I wrote:
Konstantin Knizhnik writes:
Postgres documentation says that |"now()| is a traditional PostgreSQL
equivalent to |transaction_timestamp()|".
Also both use the same implementation.
Right.
But them have different parallel safety property:
That se
On 10/05/2018 08:35 PM, Thomas Munro wrote:
On Sat, Oct 6, 2018 at 2:31 AM Andrew Dunstan
wrote:
On Wed, Oct 3, 2018 at 2:24 PM Thomas Munro
wrote:
Over the thread for bug #14825 I posted some draft code to show one
way to save/restore the enum blacklist for parallel workers. Here's a
bet
Find below various fixes to release notes for v11, for discussion purposes.
Note: I changed these:
"B-tree indexes can now be built in parallel with"
"Allow btree indexes to be built in parallel"
..since they could be construed to mean building multiple indexes
simultaneously (perhaps like what
I like broccoli
On 10/06/2018 05:46 AM, Tatsuo Ishii wrote:
After sending below to pgsql-docs, I noticed if I follow the step
described in the doc[1], generated root.crt lacks below.
X509v3 extensions:
X509v3 Subject Key Identifier:
3B:16:EA:86:0B:7C:E4:7A:16:F2:4E:54:F
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Yeah, one would hope. But I wonder whether it always produces the
> Tom> same low-order digits, and if not, whether people will complain.
> It won't produce the same low-order digits in general, since it has a
> different objective: rath
Konstantin Knizhnik writes:
> On 06.10.2018 00:25, Tom Lane wrote:
>> So maybe the right answer is to change the parallel mode infrastructure
>> so it transmits xactStartTimestamp, making transaction_timestamp()
>> retroactively safe, and then in HEAD only we could re-mark now() as
>> safe. We mi
here's my proposed patch.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 50f049f30875fd6fa9b8b3346c9da176725f37ff Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Sat, 6 Oct 2018 12:53:01 -0300
Subject:
Thomas Munro writes:
> Thanks. Here is a version squashed into one commit, with a decent
> commit message and a small improvement: the code to create the hash
> table is moved into a static function, to avoid repetition. I will
> push this to master early next week, unless there is more feedback
Amit Langote writes:
> On 2018/10/05 5:59, Tom Lane wrote:
>> So I'm inclined to just omit 0003. AFAICS this would only mean that
>> we couldn't drop the global PlanRowMarks list from PlannedStmt, which
>> does not bother me much.
> To be honest, I too had begun to fail to see the point of this
Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 09:45:09PM +0200, Laurenz Albe wrote:
> > That message is wrong, because "rel" and not "pkrel" is the partitioned
> > table.
> > I think it should be
> >
> > ereport(ERROR,
> > (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> >
> It will in fact be in the certificate:
Oh, ok. That makes sense. Thanks for the explanation.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
On 2018-Oct-06, Alvaro Herrera wrote:
> here's my proposed patch.
Pushed a few hours ago.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Oct 06, 2018 at 09:32:02PM -0300, Alvaro Herrera wrote:
> On 2018-Oct-06, Alvaro Herrera wrote:
>> here's my proposed patch.
>
> Pushed a few hours ago.
Thanks, Alvaro.
--
Michael
signature.asc
Description: PGP signature
On 2018-Oct-05, Amit Langote wrote:
> On 2018/10/05 16:05, Michael Paquier wrote:
> >> As of commit 2fbdf1b38bc [1], which has been applied in 11 and HEAD
> >> branches, RelationBuildPartitionDesc emits an error if we don't find
> >> relpartbound set for a child found by scanning pg_inherits, inst
On Sun, Oct 7, 2018 at 5:53 AM Tom Lane wrote:
> Thomas Munro writes:
> > Thanks. Here is a version squashed into one commit, with a decent
> > commit message and a small improvement: the code to create the hash
> > table is moved into a static function, to avoid repetition. I will
> > push thi
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
>
> Konstantin Knizhnik writes:
> > On 06.10.2018 00:25, Tom Lane wrote:
> >> So maybe the right answer is to change the parallel mode infrastructure
> >> so it transmits xactStartTimestamp, making transaction_timestamp()
> >> retroactively safe, and
Amit Kapila writes:
> On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
>> That's a bit too small ;-) ... one demonstrable problem with it is
>> that the parallel worker will report the wrong xactStartTimestamp
>> to pgstat_report_xact_timestamp(), since you aren't jamming the
>> transmitted value i
On Sun, Oct 7, 2018 at 10:36 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
> >> That's a bit too small ;-) ... one demonstrable problem with it is
> >> that the parallel worker will report the wrong xactStartTimestamp
> >> to pgstat_report_xact_tim
On 07.10.2018 07:58, Amit Kapila wrote:
On Sat, Oct 6, 2018 at 9:40 PM Tom Lane wrote:
Konstantin Knizhnik writes:
On 06.10.2018 00:25, Tom Lane wrote:
So maybe the right answer is to change the parallel mode infrastructure
so it transmits xactStartTimestamp, making transaction_timestamp(
Amit Kapila writes:
> On Sun, Oct 7, 2018 at 10:36 AM Tom Lane wrote:
>> That state is restored at least two transactions too late.
> That is right, but I think we can perform shm_toc_lookup for
> PARALLEL_KEY_TRANSACTION_STATE at some earlier point and then use the
> variables from it to restor
Hi,
Now that we probably have shaken the worst issues out of scram,
shouldn't we change the default password_encryption to something that
doesn't scare people? The only reason I could think of not wanting to
do that for is that we don't necessarily guarantee that we have a strong
random generato
28 matches
Mail list logo
