On 2019-09-05 22:27, Jonathan S. Katz wrote:
> PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure
> that fixes for bugs and other open items[1] are committed by the end of
> the weekend.
Could we get the list of major items in the release notes done by then?
--
Peter
On Wed, Sep 04, 2019 at 09:22:33PM -0700, Jeff Davis wrote:
> New patch attached.
Thanks for the new version, Jeff.
+with PostgreSQL 11 or later servers using
+the scram-sha-256 authentication method.
Nit here: "scram-sha-256" refers to the HBA entry. I would
just use "SCRAM"
Hello Richard,
On Wed, Sep 4, 2019 at 4:30 PM Richard Guo wrote:
>
> Hi Amit,
>
> On Wed, Sep 4, 2019 at 10:01 AM Amit Langote wrote:
>>
>> Fujita-san,
>>
>> To avoid losing track of this, I've added this to November CF.
>>
>> https://commitfest.postgresql.org/25/2278/
>>
>> I know there is one
On Fri, Sep 6, 2019 at 12:53 AM Tom Lane wrote:
>
> Amit Langote writes:
> > On Thu, Sep 5, 2019 at 6:18 PM Dilip Kumar wrote:
> >> Instead of falling back to the child, isn't it make more sense to
> >> check the permissions on the parent upto which we could translate (it
> >> may not be the
On Thu, Sep 5, 2019 at 11:40 PM Robert Haas wrote:
> On Fri, Aug 30, 2019 at 7:05 AM Jeevan Ladhe
> wrote:
> >> Fixed both comments in the attached patch.
> >
> > Thanks, the patch looks good to me.
>
> Here's a version of the patch with a further change to the wording of
> the comment. I hope
Hi!
> 4 сент. 2019 г., в 2:13, Alvaro Herrera написал(а):
>
> On 2019-Mar-29, Andrey Borodin wrote:
>
>> Here's updated patch with AccessShareLock.
>> I've tried to stress this with combination of random inserts, vaccuums and
>> checks. This process neither failed, nor deadlocked.
>> The
-Original Message-
From: Masahiko Sawada Sent: Thursday, 15 August 2019
7:10 PM
> BTW I've created PoC patch for cluster encryption feature. Attached patch set
> has done some items of TODO list and some of them can be used even for finer
> granularity encryption. Anyway, the
From: Michael Paquier [mailto:mich...@paquier.xyz]
> The last patch submitted is here:
> https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D
> 1F8ECF73@G01JPEXMBYT05
> And based on the code paths it touches I would recommend to not play with
> REL_12_STABLE at this stage.
I'm
On Wed, Jul 17, 2019 at 01:31:05PM +0200, Daniel Verite wrote:
> The tab width should be 4. Please have a look at
> https://www.postgresql.org/docs/current/source-format.html
> It also explains why opportunistic reformatting is futile, anyway:
- char *schema,
-
At Thu, 22 Aug 2019 10:43:52 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190822.104352.26342272.horikyota@gmail.com>
> I think you diff is intelligible enough for me. I'll take this if
> you haven't done. Anyway I'm staring on this.
- Reducing state variables
It was a
On Thu, Sep 05, 2019 at 02:11:35PM -0700, Andres Freund wrote:
> On 2019-09-05 14:16:11 +0200, Peter Eisentraut wrote:
>> I'm content with this patch.
>
> Would need tests.
The latest patch sends adds coverage for all the new code paths
added. Do you have something else in mind?
>> Better
On Fri, Sep 6, 2019 at 1:44 AM Michael Paquier wrote:
> One idea I got was to pass the command ID as an extra argument of the
> update routine. I am not completely sure either if we need this level
> of complication.
I still don't think that's the right approach.
> > Those are just weaknesses
On Tue, Aug 27, 2019 at 6:57 PM Asim R P wrote:
>
> On Tue, Aug 27, 2019 at 12:35 PM Michael Paquier
wrote:
> >
> > Things like exec_fault_injector_command() need to be more documented.
> > It is hard to guess what it is being used for.
>
> Added a comment to explain things a bit. Hope that
On 2019-Sep-06, Andrey Borodin wrote:
> Here's rebased version. Changes in v9:
> * adjust to usage of table_open
> * update new extension version
> * check for main fork presence in GiST check too
Cool. On a quick eyeball, your new amcheck.h does not conform to our
conventions: it should not
On 2019-Sep-06, Surafel Temesgen wrote:
> > ... yet this doesn't appear to have resulted in any change in the code,
> > or I just missed it. Are you going to update the patch per that?
>
> Its already done in v9 of the patch attached by Tomas
Oh, I missed that. Great, so we're expecting some
I confirm the update statement with new value distinct from old value causes
taking FOR UPDATE lock.
In my original example, the `set detail_id=null` clause is actually generated
by Hibernate and was preserved during example minification.
So I'll have to either find a way how to stop generating
On Fri, Sep 6, 2019 at 2:08 AM Jeevan Chalke
wrote:
> Attached patch for v10 and pre. The same v10 patch applies cleanly.
>
> Changes related to the page checksum verification is not present on v10 and
> pre, and thus those changes are not applicable, so removed those. Also,
> wal_segment_size
On 2019-Sep-05, Tom Lane wrote:
> Alvaro Herrera from 2ndQuadrant writes:
> > Tsunakawa-san, there's been some discussion downthread. Could you
> > please submit an updated version of the patch? I would like to get it
> > pushed before beta4 next week, if possible.
>
> [ confused... ] I
On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
>
> Greetings,
>
> * Kohei KaiGai (kai...@heterodb.com) wrote:
> > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy :
> > > Since all DAC checks should have corresponding MAC, this patch adds a
> > > hook to allow extensions to implement a MAC check on
Peter Eisentraut writes:
> On 2019-09-05 22:27, Jonathan S. Katz wrote:
>> PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure
>> that fixes for bugs and other open items[1] are committed by the end of
>> the weekend.
> Could we get the list of major items in the release notes
On 9/6/19 2:18 PM, Tom Lane wrote:
> Yuli Khodorkovskiy writes:
>> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>>> Well, the larger question, independent of the regression tests, is
>>> will the new policy work at all on older SELinux? If not, that
>>> doesn't seem very acceptable.
>
>>
Hi,
On 2019-08-19 08:51:43 -0700, Andres Freund wrote:
> On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
> wrote:
> >On 2019-Aug-19, Masahiko Sawada wrote:
> >
> >> On Tue, Aug 13, 2019 at 6:36 AM Alvaro Herrera
> > wrote:
> >
> >> > BTW I wrote the code as suggested and it passes all the
On Thu, Sep 5, 2019 at 10:35 PM Thomas Munro wrote:
> Seems like a good time for me to try to summarise what I think the
> main problems are here:
>
> 1. The match-bit storage problem already discussed. The tuples that
> each process receives while reading from SharedTupleStore are
>
On 2019-07-19 14:41, Andrew Dunstan wrote:
> On 7/19/19 1:08 AM, Michael Paquier wrote:
>> Just browsing through the logs of the buildfarm, I have noticed that
>> some buildfarm animals complain with warnings (jacana uses MinGW):
>>
Alvaro Herrera from 2ndQuadrant wrote:
> Okay, so who is submitting a new version here? Surafel, Joe?
Sure, I'll look into it over the weekend.
On Sat, Sep 7, 2019 at 5:25 AM Robert Haas wrote:
> (I apologize if any of the above sounds like I'm talking credit for
> work actually done by Thomas, who I see is listed as the primary
> author of the commit in question. I feel like I invented
> MultiXactMemberFreezeThreshold and the big
On Fri, Sep 6, 2019 at 4:31 PM Joe Conway wrote:
>
> On 9/6/19 2:13 PM, Yuli Khodorkovskiy wrote:
> > As Joe Conway pointed out to me out of band, the build animal for RHEL
> > 7 has handle_unknown set to `0`. Are there any other concerns with
> > this approach?
>
>
> You mean deny_unknown I
Alvaro Herrera from 2ndQuadrant writes:
> This discussion seems to have died down. Apparently we have three
> directions here, from three different people. Are we doing anything?
I don't really want to do anything beyond the patch I submitted in
this thread (at
On 2019-Sep-06, Peter Geoghegan wrote:
> On Fri, Sep 6, 2019 at 7:02 AM Alvaro Herrera from 2ndQuadrant
> wrote:
> > Peter, Heikki, are you going to do [at least] one more round of
> > design/functional review?
>
> I didn't plan on it, but somebody probably should. Are you offering to
> commit
Yuli Khodorkovskiy writes:
> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>> Well, the larger question, independent of the regression tests, is
>> will the new policy work at all on older SELinux? If not, that
>> doesn't seem very acceptable.
> The default SELinux policy on Fedora ships
On 2019-May-23, Tom Lane wrote:
> +
> +Another nonstandard extension is that following the escape character
> +with a letter or digit provides access to the same escape sequences
> +defined for POSIX regular expressions, below (see
> +,
> +, and
> +).
>
I think
On Fri, Sep 6, 2019 at 7:02 AM Alvaro Herrera from 2ndQuadrant
wrote:
> Peter, Heikki, are you going to do [at least] one more round of
> design/functional review?
I didn't plan on it, but somebody probably should. Are you offering to
commit the patch? If not, I can take care of it.
--
Peter
On Fri, Sep 6, 2019 at 2:35 PM Alvaro Herrera from 2ndQuadrant
wrote:
> I'd welcome it more if you did it; thanks.
I'll take care of it, then.
--
Peter Geoghegan
On Thu, Sep 5, 2019 at 4:08 PM Bossart, Nathan wrote:
> Right, the v2 patch will effectively ramp-down the freezemin as your
> freeze_max_age gets smaller, while the v1 patch will set the effective
> freezemin to zero as soon as your multixact age passes the threshold.
> I think what is unclear
As Joe Conway pointed out to me out of band, the build animal for RHEL
7 has handle_unknown set to `0`. Are there any other concerns with
this approach?
On Fri, Sep 6, 2019 at 1:00 PM Yuli Khodorkovskiy
wrote:
>
> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
> >
> > Stephen Frost writes:
>
On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote:
>
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Yuli Khodorkovskiy writes:
> >>> 1) Get the sepgsql changes in without policy/regressions
> >>> 2) Send a patch to refpolicy for the new permission
> >>> 3) Once Redhat
> "Tom" == Tom Lane writes:
> Alvaro Herrera from 2ndQuadrant writes:
>> This discussion seems to have died down. Apparently we have three
>> directions here, from three different people. Are we doing anything?
Tom> I don't really want to do anything beyond the patch I submitted in
On 9/6/19 2:13 PM, Yuli Khodorkovskiy wrote:
> As Joe Conway pointed out to me out of band, the build animal for RHEL
> 7 has handle_unknown set to `0`. Are there any other concerns with
> this approach?
You mean deny_unknown I believe.
"Allow unknown object class / permissions. This will set
On Fri, Sep 06, 2019 at 11:55:43AM -0500, Jeremy Finzel wrote:
> I am using the basic extension building infrastructure with sql and
> expected files, but what I want to test is changing a config setting and
> then restarting the cluster with shared_preload_libraries in place. Is
> there a
On Sat, Sep 07, 2019 at 12:11:25AM +0200, Peter Eisentraut wrote:
> I'm not sure exactly what the upstream of mingw is these days, but I
> think the original issue that led to 811be893 has long been fixed [0],
> and the other stuff in mingwcompat.c is also no longer relevant [1]. I
> think
Joe Conway writes:
> On 9/6/19 2:18 PM, Tom Lane wrote:
>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires
>> a newer version of libselinux than what ships in RHEL6. So I'm not
>> concerned about that. We do need to worry about RHEL7, and whatever
>> is the oldest version of
On 9/6/19 8:07 PM, Tom Lane wrote:
> Joe Conway writes:
>> On 9/6/19 2:18 PM, Tom Lane wrote:
>>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires
>>> a newer version of libselinux than what ships in RHEL6. So I'm not
>>> concerned about that. We do need to worry about RHEL7,
On Thu, Sep 5, 2019 at 4:07 PM Andres Freund wrote:
> Yea, makes sense to me.
OK, done. Here's the remaining patches again, with a slight update to
the renaming patch (now 0002). In the last version, I renamed
toast_insert_or_update to heap_toast_insert_or_update but did not
rename
On Fri, Sep 6, 2019 at 3:22 PM Peter Geoghegan wrote:
> I'll take care of it, then.
Attached is v10, which has some comment and style fix-ups, including
the stuff Alvaro mentioned. It also adds line pointer sanitization to
match what I added to verify_nbtree.c in commit a9ce839a (we use a
custom
On 2019-08-14 20:17, Andres Freund wrote:
> On 2019-05-22 16:40:28 +0200, Peter Eisentraut wrote:
>> On 2019-04-29 19:52, Andres Freund wrote:
>>> Hm. It appears that gettext supports expanding PRId64 PRIu64 etc in
>>> translated strings.
>>
>> That won't work in non-GNU gettext.
>
> Which of
Dear Tom
Many thanks for your quick reply. Indeed both solutions you proposed can be
combined together in order to solve all the problems. However changes in
the code are needed. Let me now elaborate on the solution concerning the
combination of stakind/staop first and I will elaborate on adding
Hi Tom,
On Fri, Sep 6, 2019 at 1:26 AM Tom Lane wrote:
> Surafel Temesgen writes:
> > [ percent-incremental-v8.patch ]
>
> I took a quick look through this.
>
> * Why is this adding new functionality in tuplestore.c? Especially
> functionality to get out a different tuple representation than
Hi Alvaro,
On Fri, Sep 6, 2019 at 1:52 AM Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> wrote:
> As Tom just said in the thread for PERCENT, the gram.y changes need a
> better representation. Also, rename EXACT_NUMBER, per that thread.
>
> As far as I can tell, this concerns feature
On 06.09.2019 1:01, Jaime Casanova wrote:
On Thu, 15 Aug 2019 at 06:01, Konstantin Knizhnik
wrote:
I have implemented one more trick reducing number of tainted backends:
now it is possible to use session variables in pooled backends.
How it works?
Proxy determines "SET var=" statements and
Hello!
I am using the basic extension building infrastructure with sql and
expected files, but what I want to test is changing a config setting and
then restarting the cluster with shared_preload_libraries in place. Is
there a canonical way to do this or does anyone have any examples of this?
I
On 2019-Jul-24, Michael Paquier wrote:
> The conclusion that we are reaching on the thread is to remove more
> dependencies on strtol that we have in the code, and replace it with
> our own, more performant wrappers. This thread makes me wondering
> that we had better wait before doing this
This discussion seems to have died down. Apparently we have three
directions here, from three different people. Are we doing anything?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Sep 5, 2019 at 5:32 PM Andres Freund wrote:
> On 2019-09-05 14:50:50 -0400, Robert Haas wrote:
> > The best way that I've been able to come up with to enforce this rule
> > after a little bit of thought is to add Assert(IsTransactionState())
> > to a bunch of functions in snapmgr.c, most
On 9/6/19 9:56 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 2019-09-05 22:27, Jonathan S. Katz wrote:
>>> PostgreSQL 12 Beta 4 will be released on 2019-09-12. Please make sure
>>> that fixes for bugs and other open items[1] are committed by the end of
>>> the weekend.
>
>> Could we get
On 2019-Sep-03, Peter Eisentraut wrote:
> On 2019-09-03 01:45, Thomas Munro wrote:
> > fe-connect.obj : error LNK2019: unresolved external symbol getpeereid
> > referenced in function PQconnectPoll
> > [C:\projects\postgresql\libpq.vcxproj]
>
> This should be fixed in the attached patches.
On Wed, 4 Sep 2019 00:32:03 +0900
Fujii Masao wrote:
> On Mon, Jul 29, 2019 at 7:26 PM Jehan-Guillaume de Rorthais
> wrote:
> >
> > On Fri, 26 Jul 2019 18:22:25 +0200
> > Jehan-Guillaume de Rorthais wrote:
> >
> > > On Fri, 26 Jul 2019 10:02:58 +0200
> > > Jehan-Guillaume de Rorthais wrote:
Michael Paquier wrote:
> Sure. However do we need to introduce this much complication as a
> goal for this patch though whose goal is just to provide hints about
> the progress of the work done by vacuumlo?
Yeah, I went off on a tangent when realizing that ~500 lines of C
client-side
On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
>
> Greetings,
Hello Stephen,
>
> * Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> > On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > > * Kohei KaiGai (kai...@heterodb.com) wrote:
> > > > 2019年7月25日(木) 3:52 Yuli
On Fri, Sep 6, 2019 at 11:26 AM Yuli Khodorkovskiy
wrote:
>
> On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
> >
> > Greetings,
>
> Hello Stephen,
>
> >
> > * Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> > > On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > > > *
Yuli Khodorkovskiy writes:
> Ah, now I remember why I didn't add regressions to the original patch.
> As stated at the top of the thread, the "db_table: { truncate }"
> permission does not currently exist in refpolicy. A workaround would
> be to add the policy with CIL, but that adds unneeded
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yuli Khodorkovskiy writes:
> > Ah, now I remember why I didn't add regressions to the original patch.
> > As stated at the top of the thread, the "db_table: { truncate }"
> > permission does not currently exist in refpolicy. A workaround would
On Fri, Sep 6, 2019 at 11:47 AM Tom Lane wrote:
>
> Yuli Khodorkovskiy writes:
> > Ah, now I remember why I didn't add regressions to the original patch.
> > As stated at the top of the thread, the "db_table: { truncate }"
> > permission does not currently exist in refpolicy. A workaround would
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yuli Khodorkovskiy writes:
>>> 1) Get the sepgsql changes in without policy/regressions
>>> 2) Send a patch to refpolicy for the new permission
>>> 3) Once Redhat updates the selinux-policy-targeted RPM to include the
>>> new
On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote:
...
Results:
test | mode | average_tps | degradation_perc
--+--+-+--
head_no_pgss | extended | 13816 |1.000
patch_not_loaded
On Fri, Sep 06, 2019 at 04:19:16PM +0200, Tomas Vondra wrote:
FWIW I've done some benchmarking on this too, with a single pgbench client
running select-only test on a tiny database, in different modes (simple,
extended, prepared). I've done that on two systems with different CPUs
(spreadsheet
On 2019-Sep-06, Michael Paquier wrote:
> Finally comes the question of what do we do for v12? I am adding in
> CC Peter, Alvaro being already present, who have been involved in the
> commits with CREATE INDEX and REINDEX. It would be sad to revert a
> this feature, but well I'd rather do that
Alvaro Herrera from 2ndQuadrant writes:
> On 2019-Sep-05, Tom Lane wrote:
>> [ confused... ] I haven't been paying attention to this thread,
>> but is it really something we'd push into v12 at this point?
> Well, IMV this is a backpatchable, localized bug fix.
I dunno. This thread is
Greetings,
* Yuli Khodorkovskiy (yuli.khodorkovs...@crunchydata.com) wrote:
> On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost wrote:
> > * Kohei KaiGai (kai...@heterodb.com) wrote:
> > > 2019年7月25日(木) 3:52 Yuli Khodorkovskiy
> > > :
> > > > Since all DAC checks should have corresponding MAC, this
On Mon, Sep 2, 2019 at 9:28 AM Heikki Linnakangas wrote:
> On 02/09/2019 07:54, Alexander Korotkov wrote:
> > NULL and '(NaN,NaN)' are swapped. It happens so, because we assume
> > distance to NULL to be Inf, while float8_cmp_internal() assumes NaN to
> > be greater than NULL. If even we would
On 2019-Sep-05, Jamison, Kirk wrote:
> I also mentioned it from my first post if we can just remove this dead code.
> If not, it would require to modify the function because it would also
> need nforks as input argument when calling DropRelFileNodeBuffers. I kept my
> changes in the latest patch.
Also: this patch no longer applies. Please rebase.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-Sep-06, Alvaro Herrera from 2ndQuadrant wrote:
> I think you should get 0001 (+0002?) pushed and see what the buildfarm
> thinks; move forward from there.
... but of course this goes counter to what you said earlier about 0001
needing to be pushed last.
--
Álvaro Herrera
On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
> There are actual reasons why the 'DELETE' privilege is *not* the same as
> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should
> just be tossing that distinction out the window for users of SELinux.
+1.
--
Robert Haas
On 9/6/19 11:26 AM, Yuli Khodorkovskiy wrote:
> On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote:
>> There are actual reasons why the 'DELETE' privilege is *not* the same as
>> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should
>> just be tossing that distinction out the
74 matches
Mail list logo
