Re: race condition when writing pg_control

On Sat, May 23, 2020 at 01:00:17AM +0900, Fujii Masao wrote: > Per my quick check, XLogReportParameters() seems to have the similar issue, > i.e., it updates the control file without taking ControlFileLock. > Maybe we should fix this at the same time? Yeah. It also checks the control file

Re: Adding missing object access hook invocations

On Thu, May 21, 2020 at 09:32:55AM +0900, Michael Paquier wrote: > Thanks for the input, Robert. So, even if we are post-beta1 it looks > like there are more upsides than downsides to get that stuff done > sooner than later. I propose to get that applied in the next couple > of days, please let

Re: Parallel Seq Scan vs kernel read ahead

On Sat, May 23, 2020 at 12:00 AM Robert Haas wrote: > > On Tue, May 19, 2020 at 10:23 PM Amit Kapila wrote: > > Good experiment. IIRC, we have discussed a similar idea during the > > development of this feature but we haven't seen any better results by > > allocating in ranges on the systems we

Re: xid wraparound danger due to INDEX_CLEANUP false

On Fri, May 22, 2020 at 1:40 PM Peter Geoghegan wrote: > It. seems like the right direction to me. Robert? BTW, this is an interesting report of somebody using the INDEX_CLEANUP feature when they had to deal with a difficult production issue:

Re: segmentation fault using currtid and partitioned tables

On 2020-Apr-09, Michael Paquier wrote: > Playing more with this stuff, it happens that we have zero code > coverage for currtid() and currtid2(), and the main user of those > functions I can find around is the ODBC driver: > https://coverage.postgresql.org/src/backend/utils/adt/tid.c.gcov.html

Re: password_encryption default

On 5/22/20 5:21 PM, Tom Lane wrote: > Vik Fearing writes: >> On 5/22/20 9:09 PM, Jonathan S. Katz wrote: >>> As someone who is an unabashed SCRAM fan and was hoping the default >>> would be up'd for v13, I would actually +1 making it the default in v14, >>> i.e. because 9.5 will be EOL at that

Re: password_encryption default

Vik Fearing writes: > On 5/22/20 9:09 PM, Jonathan S. Katz wrote: >> As someone who is an unabashed SCRAM fan and was hoping the default >> would be up'd for v13, I would actually +1 making it the default in v14, >> i.e. because 9.5 will be EOL at that point, and as such we both have >> every*

Re: xid wraparound danger due to INDEX_CLEANUP false

On Mon, May 18, 2020 at 7:32 PM Masahiko Sawada wrote: > I've attached WIP patch for HEAD. With this patch, the core pass > index_cleanup to bulkdelete and vacuumcleanup callbacks so that they > can make decision whether run vacuum or not. > > If the direction of this patch seems good, I'll

Re: password_encryption default

On 5/22/20 9:09 PM, Jonathan S. Katz wrote: > As someone who is an unabashed SCRAM fan and was hoping the default > would be up'd for v13, I would actually +1 making it the default in v14, > i.e. because 9.5 will be EOL at that point, and as such we both have > every* driver supporting SCRAM AND

Re: Planning counters in pg_stat_statements (using pgss_store)

>> If we can store the plan for each statement, e.g., like pg_store_plans >> extension [1] does, rather than such partial information, which would >> be enough for your cases? > That'd definitely address way more use cases. Do you know if some > benchmark were done to see how much overhead such

Re: password_encryption default

On 5/22/20 11:34 AM, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> As far as that last goes, we *did* get the buildfarm fixed to be all >>> v11 scripts, so I thought we were ready to move forward on trying >>> 09f08930f again. It's too late to consider

Re: Parallel Seq Scan vs kernel read ahead

On Thu, May 21, 2020 at 6:28 PM Thomas Munro wrote: > Right, I think it's safe. I think you were probably right that > ramp-up isn't actually useful though, it's only the end of the scan > that requires special treatment so we don't get unfair allocation as > the work runs out, due to course

Re: Parallel Seq Scan vs kernel read ahead

On Tue, May 19, 2020 at 10:23 PM Amit Kapila wrote: > Good experiment. IIRC, we have discussed a similar idea during the > development of this feature but we haven't seen any better results by > allocating in ranges on the systems we have tried. So, we want with > the current approach which is

Re: some grammar refactoring

> On May 18, 2020, at 11:43 PM, Peter Eisentraut > wrote: > > Here is a series of patches to do some refactoring in the grammar around the > commands COMMENT, DROP, SECURITY LABEL, and ALTER EXTENSION ... ADD/DROP. In > the grammar, these commands (with some exceptions) basically just

Re: Planning counters in pg_stat_statements (using pgss_store)

On Fri, May 22, 2020 at 3:51 PM Fujii Masao wrote: > > On 2020/05/22 15:10, Andy Fan wrote: > > > > > > On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud > > wrote: > > > > Le jeu. 21 mai 2020 à 09:17, Michael Paquier > > a écrit : > > > >

Re: pg_bsd_indent and -Wimplicit-fallthrough

On Thu, May 21, 2020 at 7:39 PM Piotr Stefaniak wrote: > > On 18/05/2020 11.22, Julien Rouhaud wrote: > > On Sun, May 17, 2020 at 2:32 AM Michael Paquier wrote: > >> > >> On Sat, May 16, 2020 at 11:56:28AM -0400, Tom Lane wrote: > >>> In the meantime, I went ahead and pushed this to our

Re: race condition when writing pg_control

On 2020/05/22 13:51, Thomas Munro wrote: On Tue, May 5, 2020 at 9:51 AM Thomas Munro wrote: On Tue, May 5, 2020 at 5:53 AM Bossart, Nathan wrote: I believe I've discovered a race condition between the startup and checkpointer processes that can cause a CRC mismatch in the pg_control file.

Re: password_encryption default

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> I'm +1 for changing both of these things as soon as we branch for v14, > >> but I feel like it's a bit late for v13. If we aren't feature-frozen > >> now, when will we be? >

Re: password_encryption default

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I'm +1 for changing both of these things as soon as we branch for v14, >> but I feel like it's a bit late for v13. If we aren't feature-frozen >> now, when will we be? > I really don't consider changing of defaults to be on the

Re: password_encryption default

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> As far as that last goes, we *did* get the buildfarm fixed to be all > >> v11 scripts, so I thought we were ready to move forward on trying > >> 09f08930f again. It's too

Re: password_encryption default

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> As far as that last goes, we *did* get the buildfarm fixed to be all >> v11 scripts, so I thought we were ready to move forward on trying >> 09f08930f again. It's too late to consider that for v13, but >> perhaps it'd be

Re: password_encryption default

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote: > >>> Peter Eisentraut writes: > We didn't get anywhere with making the default authentication method in >

Re: password_encryption default

Stephen Frost writes: > * Magnus Hagander (mag...@hagander.net) wrote: >> On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote: >>> Peter Eisentraut writes: We didn't get anywhere with making the default authentication method in a source build anything other than trust. > I'm +1 on moving

Re: About reducing EXISTS sublink

On Friday, May 22, 2020, Richard Guo wrote: > Hi hackers, > > For EXISTS SubLink, in some cases the subquery can be reduced to > constant TRUE or FALSE, based on the knowledge that it's being used in > EXISTS(). One such case is when the subquery has aggregates without > GROUP BY or HAVING, and

Re: password_encryption default

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote: > > Peter Eisentraut writes: > > > We didn't get anywhere with making the default authentication method in > > > a source build anything other than trust. But perhaps we should change >

Re: Add explanations which are influenced by track_io_timing

On 2020/05/15 9:50, Atsushi Torikoshi wrote: Thanks for reviewing! On Wed, May 13, 2020 at 11:27 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote: What about the attached patch based on yours? It looks better. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing

Re: password_encryption default

On Fri, May 22, 2020 at 4:13 PM Tom Lane wrote: > Peter Eisentraut writes: > > We didn't get anywhere with making the default authentication method in > > a source build anything other than trust. But perhaps we should change > > the default for password_encryption to nudge people to adopt

Re: password_encryption default

Peter Eisentraut writes: > We didn't get anywhere with making the default authentication method in > a source build anything other than trust. But perhaps we should change > the default for password_encryption to nudge people to adopt SCRAM? > Right now, passwords are still hashed using MD5

Re: snowball release

Peter Eisentraut writes: > Snowball has made a release! With a tag! > I have prepared a patch to update PostgreSQL's copy. Yeah, this was on my to-do list as well. Thanks for doing it. > I think some consideration could be given for including this into PG13. > Otherwise, I'll park it for

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/05/22 15:10, Andy Fan wrote: On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud mailto:rjuju...@gmail.com>> wrote: Le jeu. 21 mai 2020 à 09:17, Michael Paquier mailto:mich...@paquier.xyz>> a écrit : On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: >

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 19, 2020 at 5:34 PM Amit Kapila wrote: > > On Fri, May 15, 2020 at 2:47 PM Dilip Kumar wrote: > > > > On Tue, May 12, 2020 at 4:39 PM Amit Kapila wrote: > > > > > > > > 4. > > > +static void > > > +stream_start_cb_wrapper(ReorderBuffer *cache, ReorderBufferTXN *txn) > > > +{ > > > +

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 19, 2020 at 6:01 PM Amit Kapila wrote: > > On Fri, May 15, 2020 at 2:48 PM Dilip Kumar wrote: > > > > On Wed, May 13, 2020 at 4:50 PM Amit Kapila wrote: > > > > > > > > 3. > > > And, during catalog scan we can check the status of the xid and > > > + * if it is aborted we will report

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 19, 2020 at 4:33 PM Amit Kapila wrote: > > On Tue, May 19, 2020 at 3:31 PM Dilip Kumar wrote: > > > > On Tue, May 19, 2020 at 2:34 PM Amit Kapila wrote: > > > > > > On Mon, May 18, 2020 at 5:57 PM Amit Kapila > > > wrote: > > > > > > > > > > > > 3. > > > > + /* > > > > + * If

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Mon, May 18, 2020 at 4:10 PM Amit Kapila wrote: > > On Sun, May 17, 2020 at 12:41 PM Dilip Kumar wrote: > > > > On Fri, May 15, 2020 at 4:04 PM Amit Kapila wrote: > > > > > > > > > Review comments: > > > -- > > > 1. > > > @@ -1762,10 +1952,16 @@

password_encryption default

We didn't get anywhere with making the default authentication method in a source build anything other than trust. But perhaps we should change the default for password_encryption to nudge people to adopt SCRAM? Right now, passwords are still hashed using MD5 by default, unless you specify

snowball release

Snowball has made a release! With a tag! I have prepared a patch to update PostgreSQL's copy. (not attached here, 566230 bytes, but see https://github.com/petere/postgresql/commit/52a6133b58c77ada4210a96e5155cbe4da5e5583) Since we last updated our copy from their commit date 2019-06-24 and

Re: SEARCH and CYCLE clauses

On 2020-05-22 12:40, Vik Fearing wrote: If you specify null, then the cycle check expression will always fail, so it will abort after the first row.  (We should perhaps prohibit specifying null, but see below.) I would rather make the cycle check expression work with null. It works correctly

Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

On Fri, May 22, 2020 at 5:00 PM Rajkumar Raghuwanshi < rajkumar.raghuwan...@enterprisedb.com> wrote: > Hi All, > > I am getting ERROR when using the "FOR UPDATE" clause for the partitioned > table. below is a reproducible test case for the same. > > CREATE TABLE tbl (c1 INT,c2 TEXT) PARTITION BY

Getting ERROR with FOR UPDATE/SHARE for partitioned table.

Hi All, I am getting ERROR when using the "FOR UPDATE" clause for the partitioned table. below is a reproducible test case for the same. CREATE TABLE tbl (c1 INT,c2 TEXT) PARTITION BY LIST (c1); CREATE TABLE tbl_null PARTITION OF tbl FOR VALUES IN (NULL); CREATE TABLE tbl_1 PARTITION OF tbl FOR

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Fri, May 22, 2020 at 11:54 AM Amit Kapila wrote: > > v22-0006-Add-support-for-streaming-to-built-in-replicatio > > Few more comments on v22-0006 patch: 1. +stream_cleanup_files(Oid subid, TransactionId xid, bool

Re: SEARCH and CYCLE clauses

On 5/22/20 11:24 AM, Peter Eisentraut wrote: > On 2020-05-20 21:28, Vik Fearing wrote: >> 1) >> There are some smart quotes in the comments that should be converted to >> single quotes. > > ok, fixing that > >> 2) >> This query is an infinite loop, as expected: >> >>    with recursive a as

Re: SEARCH and CYCLE clauses

pá 22. 5. 2020 v 11:25 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > On 2020-05-20 21:28, Vik Fearing wrote: > > 1) > > There are some smart quotes in the comments that should be converted to > > single quotes. > > ok, fixing that > > > 2) > > This query is an infinite

Re: pgindent vs dtrace on macos

On 2020-05-20 15:56, Tom Lane wrote: On a closely related point: I was confused for awhile on Monday afternoon, wondering why the built tarballs didn't match my local tree. I eventually realized that when I'd run pgindent on Saturday, it had reformatted some generated files such as

Re: SEARCH and CYCLE clauses

On 2020-05-20 21:28, Vik Fearing wrote: 1) There are some smart quotes in the comments that should be converted to single quotes. ok, fixing that 2) This query is an infinite loop, as expected: with recursive a as (select 1 as b union all select b from a) table a; But it becomes an

Re: some grammar refactoring

On 2020-05-19 08:43, Peter Eisentraut wrote: Here is a series of patches to do some refactoring in the grammar around the commands COMMENT, DROP, SECURITY LABEL, and ALTER EXTENSION ... ADD/DROP. In the grammar, these commands (with some exceptions) basically just take a reference to an object

Re: Optimizer docs typos

On Fri, May 22, 2020 at 2:53 PM Etsuro Fujita wrote: > > Done. > Thanks! Thanks Richard

About reducing EXISTS sublink

Hi hackers, For EXISTS SubLink, in some cases the subquery can be reduced to constant TRUE or FALSE, based on the knowledge that it's being used in EXISTS(). One such case is when the subquery has aggregates without GROUP BY or HAVING, and we know its result is exactly one row, unless that row is

Re: Optimizer docs typos

On Wed, May 20, 2020 at 7:17 PM Etsuro Fujita wrote: > On Tue, May 19, 2020 at 7:35 PM Etsuro Fujita wrote: > > On Mon, May 18, 2020 at 7:45 PM Richard Guo wrote: > > > In this same README doc, another suspicious typo to me, which happens in > > > section "Optimizer Functions", is in the prefix

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On Tue, May 19, 2020 at 6:01 PM Amit Kapila wrote: > > On Fri, May 15, 2020 at 2:48 PM Dilip Kumar wrote: > > I have further reviewed v22 and below are my comments: v22-0005-Implement-streaming-mode-in-ReorderBuffer -- 1.

Re: Problem with pg_atomic_compare_exchange_u64 at 32-bit platforms

On Wed, May 20, 2020 at 10:59:44AM +0300, Konstantin Knizhnik wrote: > On 20.05.2020 10:36, Noah Misch wrote: > >On Wed, May 20, 2020 at 10:23:37AM +0300, Konstantin Knizhnik wrote: > >>On 20.05.2020 06:05, Noah Misch wrote: > >>>On Tue, May 19, 2020 at 04:07:29PM +0300, Konstantin Knizhnik wrote:

Re: [Proposal] Page Compression for OLTP

Sorry, There may be a problem with the display format of the previous mail. So resend it At 2020-05-21 15:04:55, "Fabien COELHO" wrote: > >Hello, > >My 0.02, some of which may just show some

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, May 21, 2020 at 3:49 PM Julien Rouhaud wrote: > Le jeu. 21 mai 2020 à 09:17, Michael Paquier a > écrit : > >> On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: >> > On Tue, May 19, 2020 at 4:29 AM Andy Fan >> wrote: >> >> Thanks for the excellent extension. I want to add

Re: Planning counters in pg_stat_statements (using pgss_store)

On Thu, May 21, 2020 at 3:17 PM Michael Paquier wrote: > On Thu, May 21, 2020 at 08:49:53AM +0200, Julien Rouhaud wrote: > > On Tue, May 19, 2020 at 4:29 AM Andy Fan > wrote: > >> Thanks for the excellent extension. I want to add 5 more fields to > satisfy the > >> following requirements. > >>