Re: Choosing values for multivariate MCV lists

On Tue, 18 Jun 2019 at 21:59, Tomas Vondra wrote: > > The current implementation of multi-column MCV lists (added in this > cycle) uses a fairly simple algorithm to pick combinations to include in > the MCV list. We just compute a minimum number of occurences, and then > include all entries

Re: Inconsistent error message wording for REINDEX CONCURRENTLY

On Wed, Jun 19, 2019 at 11:29:37PM -0400, Alvaro Herrera wrote: > Looks good. Thanks for the review, and reminding me about it :) While on it, I have removed some comments around the error messages because they actually don't bring more information. -- Michael signature.asc Description: PGP

Re: doc: update "relam" description in pg_class catalog reference

On 6/20/19 1:07 PM, Michael Paquier wrote: On Thu, Jun 20, 2019 at 11:20:46AM +0900, Ian Barwick wrote: Whoops, correct version attached. Sorry about the noise. v2 looks fine to me, committed. Thanks! Thanks! Regards Ian Barwick -- Ian Barwick

Re: doc: update "relam" description in pg_class catalog reference

On Thu, Jun 20, 2019 at 11:20:46AM +0900, Ian Barwick wrote: > Whoops, correct version attached. Sorry about the noise. v2 looks fine to me, committed. Thanks! -- Michael signature.asc Description: PGP signature

Re: Inconsistent error message wording for REINDEX CONCURRENTLY

On 2019-May-27, Michael Paquier wrote: > On Mon, May 27, 2019 at 12:20:58AM -0400, Alvaro Herrera wrote: > > I notice your patch changes "catalog relations" to "system catalogs". > > I think we predominantly prefer the latter, so that part of your change > > seems OK. (In passing, I noticed we

JOIN_SEMI planning question

Hello, While looking at bug #15857[1], I wondered why the following two queries get different plans, given the schema and data from the bug report: (1) SELECT COUNT (*) FROM a JOIN b ON a.id=b.base_id WHERE EXISTS ( SELECT 1 FROM c

Re: doc: update "relam" description in pg_class catalog reference

On 6/20/19 11:17 AM, Ian Barwick wrote: Hi Here:   https://www.postgresql.org/docs/devel/catalog-pg-class.html the description for "relam" has not been updated to take into account table access methods; patch attached. Whoops, correct version attached. Sorry about the noise. Regards

doc: update "relam" description in pg_class catalog reference

Hi Here: https://www.postgresql.org/docs/devel/catalog-pg-class.html the description for "relam" has not been updated to take into account table access methods; patch attached. Regards Ian Barwick -- Ian Barwick https://www.2ndQuadrant.com/ PostgreSQL Development,

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

I wrote: > So I'm toying with the idea of extending Andrew's patch to put a negative > preference on "localtime", ensuring we'll use some other name for the zone > if one is available. Oh ... after further review it seems like "posixrules" should be de-preferred on the same basis: it's

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

On Thu, Jun 20, 2019 at 10:48 AM Tom Lane wrote: > As of now, six of the seven UCT-reporting members have switched to UTC; > the lone holdout is elver which hasn't run in ten days. (Perhaps it > zneeds unwedged.) There are no other changes, so it seems like Andrew's > patch is doing what it

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

BTW ... now that that patch has been in long enough to collect some actual data on what it's doing, I set out to scrape the buildfarm logs to see what is happening in the farm. Here are the popularities of various timezone settings, as of the end of May: 3 America/Los_Angeles 9

Re: more Unicode data updates

On Thu, Jun 20, 2019 at 8:35 AM Peter Eisentraut wrote: > src/include/common/unicode_norm_table.h also should be updated to the > latest Unicode tables, as described in src/common/unicode. See attached > patches. This also passes the tests described in > src/common/unicode/README. (That is,

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Robert Haas writes: > On Mon, Jun 17, 2019 at 2:41 PM Stephen Frost wrote: >> Ah, ok, I agree that would have been good to do. Of course, hindsight >> being 20/20 and all that. Something to keep in mind for the future >> though. > I think it was inappropriate to commit this at all. You can't

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

On Mon, Jun 17, 2019 at 2:41 PM Stephen Frost wrote: > Ah, ok, I agree that would have been good to do. Of course, hindsight > being 20/20 and all that. Something to keep in mind for the future > though. I think it was inappropriate to commit this at all. You can't just say "some other

Re: pg_upgrade: Improve invalid option handling

> On 19 Jun 2019, at 21:51, Peter Eisentraut > wrote: > > On 2019-06-19 04:24, Michael Paquier wrote: >> On Tue, Jun 18, 2019 at 10:25:44AM +0200, Daniel Gustafsson wrote: >>> Correct, that matches how pg_basebackup and psql does it. >> >> Perhaps you have a patch at hand? I can see four

Re: Race conditions with TAP test for syncrep

On 2019-Jun-18, Michael Paquier wrote: > On Mon, Jun 17, 2019 at 10:50:39AM -0400, Alvaro Herrera wrote: > > Hmm, this introduces a bit of latency: it waits for each standby to be > > fully up before initializing the next standby. Maybe it would be more > > convenient to split the primitives:

Re: Update list of combining characters

Peter Eisentraut writes: >> Indeed. Here is an updated script and patch. > committed (to master) Cool, but should we also put your recalculation script into git, to help the next time we decide that we need to update this list? It's demonstrated to be nontrivial to get it right ;-)

Re: New vacuum option to do only freezing

On Tue, Jun 18, 2019 at 10:39 PM Michael Paquier wrote: > +INSERT INTO no_index_cleanup(i, t) VALUES(1, repeat('1234567890',3)); > Do we really need a string as long as that? Specifying EXTERNAL storage might make things easier. I have used PLAIN storage to test the 1/3 of a page restriction

Re: pg_upgrade: Improve invalid option handling

On 2019-06-19 04:24, Michael Paquier wrote: > On Tue, Jun 18, 2019 at 10:25:44AM +0200, Daniel Gustafsson wrote: >> Correct, that matches how pg_basebackup and psql does it. > > Perhaps you have a patch at hand? I can see four strings in > pg_upgrade, two in exec.c and two in option.c, which

Re: Update list of combining characters

On 2019-06-14 11:36, Peter Eisentraut wrote: > On 2019-06-13 15:52, Alvaro Herrera wrote: >> I think there's an off-by-one bug in your script. > > Indeed. Here is an updated script and patch. committed (to master) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: SQL/JSON path issues/questions

Hi, Liudmila! > While I have no objections to the proposed fixes, I think we can further > improve patch 0003 and the text it refers to. > In attempt to clarify jsonpath docs and address the concern that ? is > hard to trace in the current text, I'd also like to propose patch 0004. > Please see

Re: SQL/JSON path issues/questions

On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote: > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote: > > > > Hi, > > > > I've been reading through the documentation regarding jsonpath and > > jsonb_path_query etc., and I have found it lacking explanation for > > some functionality, and I've also

Re: Minimal logical decoding on standbys

Hi, On 2019-06-12 17:30:02 +0530, Amit Khandekar wrote: > On Tue, 11 Jun 2019 at 12:24, Amit Khandekar wrote: > > On Mon, 10 Jun 2019 at 10:37, Amit Khandekar wrote: > > > Since this requires the test to handle the > > > fire-create-slot-and-then-fire-checkpoint-from-master actions, I was > > >

Re: SQL/JSON path issues/questions

On Mon, Jun 17, 2019 at 8:40 PM Thom Brown wrote: > On Fri, 14 Jun 2019 at 08:16, Kyotaro Horiguchi > wrote: > > > > Hi, Thom. > > > > At Thu, 13 Jun 2019 14:59:51 +0100, Thom Brown wrote > > in > > > Hi, > > > > > > I've been reading through the documentation regarding jsonpath and > > >

Re: POC: Cleaning up orphaned files using undo logs

On Wed, Jun 19, 2019 at 9:13 AM Dilip Kumar wrote: > I think it's a fair point. We can keep pointer to > UndoRecordTransaction(urec_progress, dbid, uur_next) and > UndoRecordLogSwitch(urec_prevurp, urec_prevlogstart) in > UnpackedUndoRecord and include them whenever undo record contain these >

Re: POC: Cleaning up orphaned files using undo logs

On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote: > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote: > > [ new patches ] > > I tried writing some code [ to use these patches ]. I spent some more time experimenting with this patch set today and I think that the UndoFetchRecord interface is

Re: idea: log_statement_sample_rate - bottom limit for sampling

st 19. 6. 2019 v 10:49 odesílatel Adrien Nayrat napsal: > On 6/18/19 8:29 PM, Pavel Stehule wrote: > > > > > > út 18. 6. 2019 v 14:03 odesílatel Adrien Nayrat < > adrien.nay...@anayrat.info > > > napsal: > > > > Hi, > > > > I tried the patch, here my

Re: Remove one last occurrence of "replication slave" in comments

Daniel Gustafsson writes: > A Twitter thread today regarding the use of master/slave [1] made me curious > and so I had a look. It seems that commit a1ef920e27ba6ab3602aaf6d6751d8628 > replaced most instances but missed at least one which is fixed in the > attached. > > cheers ./daniel There

Re: SQL/JSON path issues/questions

On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote: > > Hi, > > I've been reading through the documentation regarding jsonpath and > jsonb_path_query etc., and I have found it lacking explanation for > some functionality, and I've also had some confusion when using the > feature. > > ? operator >

Re: POC: Cleaning up orphaned files using undo logs

On Wed, Jun 19, 2019 at 2:45 AM Amit Kapila wrote: > The reason for the same is that currently, the undo worker keep on > executing the requests if there are any. I think this is good when > there are different requests, but getting the same request from error > queue and doing it, again and

Re: New EXPLAIN option: ALL

On Wed, Jun 19, 2019 at 02:08:21PM +0200, Daniel Gustafsson wrote: > > On 19 Jun 2019, at 08:15, Peter Eisentraut > > wrote: > > > > On 2019-06-18 23:15, David Fetter wrote: > >> Are you proposing something along the lines of this? > >> > >> PROFILE [statement]; /* Shows the plan */ > >>

Re: psql UPDATE field [tab] expands to DEFAULT?

[ moving thread to -hackers ] So I propose the attached patch for fixing the clear bugs that have emerged in this discussion: don't confuse UPDATE ... SET ... with GUC-setting commands, and don't offer just DEFAULT in contexts where that's unlikely to be the only valid completion. Nosing around

Re: How to produce a Soft Block case of Deadlock Detection?

I finally found this. https://www.postgresql.org/message-id/29104.1182785028%40sss.pgh.pa.us This is very useful to understand the Soft Block. On Wed, Jun 19, 2019 at 7:18 PM Rui Hai Jiang wrote: > Hello, hackers. > > Any body know how to produce a Soft Block case of Deadlock Detection? > I

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera wrote: > On 2019-Jun-18, Oleksii Kliukin wrote: > >> Sorry, I was confused, as I was looking only at >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de87a084c0a5ac927017cd0834b33a932651cfc9 >> >> without taking your subsequent commit that silences compiler

Re: Index Skip Scan

> On Sun, Jun 16, 2019 at 5:03 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > I also agree with James that this should not be limited to Index Only > > Scans. From testing the patch, the following seems pretty strange to > > me: > > ... > > explain analyze select distinct on (a) a,b from

[proposal] de-TOAST'ing using a iterator

Hi hackers! This proposal aims to provide the ability to de-TOAST a fully TOAST'd and compressed field using an iterator and then update the appropriate parts of the code to use the iterator where possible instead of de-TOAST'ing and de-compressing the entire value. Examples where this can be

Re: POC: Cleaning up orphaned files using undo logs

On Wed, Jun 19, 2019 at 2:40 AM Robert Haas wrote: > > On Tue, Jun 18, 2019 at 2:07 PM Robert Haas wrote: > > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote: > > > [ new patches ] > > > > I tried writing some code that throws an error from an undo log > > handler and the results were not

Re: Typo in tableamapi.c

On Wed, Jun 19, 2019 at 2:57 PM Daniel Gustafsson wrote: > s/hte/the/ fixed in the attached. > Might as well keep being a commit-pipeline for you today :) applied, thanks! -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/

Typo in tableamapi.c

s/hte/the/ fixed in the attached. cheers ./daniel tableamapi_typo.patch Description: Binary data

Re: Remove one last occurrence of "replication slave" in comments

On Wed, Jun 19, 2019 at 2:35 PM Daniel Gustafsson wrote: > A Twitter thread today regarding the use of master/slave [1] made me > curious > and so I had a look. It seems that commit > a1ef920e27ba6ab3602aaf6d6751d8628 > replaced most instances but missed at least one which is fixed in the >

Remove one last occurrence of "replication slave" in comments

A Twitter thread today regarding the use of master/slave [1] made me curious and so I had a look. It seems that commit a1ef920e27ba6ab3602aaf6d6751d8628 replaced most instances but missed at least one which is fixed in the attached. cheers ./daniel [1]

Re: New EXPLAIN option: ALL

> On 19 Jun 2019, at 08:15, Peter Eisentraut > wrote: > > On 2019-06-18 23:15, David Fetter wrote: >> Are you proposing something along the lines of this? >> >> PROFILE [statement]; /* Shows the plan */ >> PROFILE RUN [statement]; /* Actually executes the query */ > > No, it would be > >

How to produce a Soft Block case of Deadlock Detection?

Hello, hackers. Any body know how to produce a Soft Block case of Deadlock Detection? I have produced the Hard Block case, but can't produce the Soft Block case. I read the design: src/backend/storage/lmgr/README. It reads, "If a process A is behind a process B in some lock's wait queue, and

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

On Wed, Jun 19, 2019 at 10:27 AM Ian Barwick wrote: > > n 6/18/19 12:41 AM, Stephen Frost wrote: > > Greetings, > > > > * Ian Barwick (ian.barw...@2ndquadrant.com) wrote > (...) > > >> I suggest explicitly documenting postgresql.auto.conf behaviour (and the > circumstances > >> where it's

Re: PG 12 beta 1 segfault during analyze

Andres Freund writes: > Hi, > > On 2019-06-17 21:46:02 -0400, Steve Singer wrote: >> On 6/15/19 10:18 PM, Tom Lane wrote: >> > Steve Singer writes: >> > > I encountered the following segfault when running against a PG 12 beta1 >> > > during a analyze against a table. >> > Nobody else has

Re: idea: log_statement_sample_rate - bottom limit for sampling

On 6/18/19 8:29 PM, Pavel Stehule wrote: > > > út 18. 6. 2019 v 14:03 odesílatel Adrien Nayrat > napsal: > > Hi, > > I tried the patch, here my comment: > > > gettext_noop("Zero effective disables sampling. " > >                          "-1

Re: New EXPLAIN option: ALL

On 19/06/2019 18:15, Peter Eisentraut wrote: On 2019-06-18 23:15, David Fetter wrote: Are you proposing something along the lines of this? PROFILE [statement]; /* Shows the plan */ PROFILE RUN [statement]; /* Actually executes the query */ No, it would be EXPLAIN statement; /* Shows the plan

Re: Some reloptions non-initialized when loaded

Hello, On Wed, Jun 19, 2019 at 10:23 AM Michael Paquier wrote: > > Hi all, > > While looking at this code, I have noticed that a couple of reloptions > which are not toast-specific don't get properly initialized. > toast_tuple_target and parallel_workers are the ones standing out. > Do we also

Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On Mon, May 27, 2019 at 9:39 PM Paul Guo wrote: > > > On Tue, May 14, 2019 at 11:06 AM Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> wrote: > >> Hello. >> >> At Mon, 13 May 2019 17:37:50 +0800, Paul Guo wrote in < >> caeet0zf9yn4daxyuflzocayyxuff1ms_oqwea+rwv3gha5q...@mail.gmail.com>

Re: POC: Cleaning up orphaned files using undo logs

On Tue, Jun 18, 2019 at 11:37 PM Robert Haas wrote: > > On Tue, Jun 18, 2019 at 7:31 AM Amit Kapila wrote: > > [ new patches ] > > I tried writing some code that throws an error from an undo log > handler and the results were not good. It appears that the code will > retry in a tight loop: > >

Re: New EXPLAIN option: ALL

On 2019-06-18 23:15, David Fetter wrote: > Are you proposing something along the lines of this? > > PROFILE [statement]; /* Shows the plan */ > PROFILE RUN [statement]; /* Actually executes the query */ No, it would be EXPLAIN statement; /* Shows the plan */ PROFILE statement; /* Actually