Re: min_safe_lsn column in pg_replication_slots view

On 2020/06/19 10:39, Michael Paquier wrote: On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote: At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila wrote in It is a little unclear to me how this or any proposed patch will solve the original problem reported by Fujii-San? Basica

Re: min_safe_lsn column in pg_replication_slots view

On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote: > Agreed. But isn't it too late to remove the columns (i.e., change > the catalog) for v13? Because v13 beta1 was already released. > IIUC the catalog should not be changed since beta1 release so that > users can upgrade PostgreSQL withou

Re: min_safe_lsn column in pg_replication_slots view

At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote in > On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote: > > Agreed. But isn't it too late to remove the columns (i.e., change > > the catalog) for v13? Because v13 beta1 was already released. > > IIUC the catalog should not be c

doing something about the broken dynloader.h symlink

When you switch a built REL_11_STABLE or earlier to REL_12_STABLE or later, you get during make install (or, therefore, make check) an error cp ./*.h 'PREFIX/include/server'/ cp: cannot stat './dynloader.h': No such file or directory This is because version 11 and earlier created src/include/dy

Re: More tzdb fun: POSIXRULES is being deprecated upstream

On 2020-06-17 20:08, Tom Lane wrote: I would definitely be in favor of "nuke it now" with respect to HEAD. It's a bit more debatable for the back branches. However, all branches are going to be equally exposed to updated system tzdata trees, so we've typically felt that changes in the tz-related

Re: Global snapshots

On 6/19/20 11:48 AM, Amit Kapila wrote: On Wed, Jun 10, 2020 at 8:36 AM Andrey V. Lepikhov wrote: On 09.06.2020 11:41, Fujii Masao wrote: The patches seem not to be registered in CommitFest yet. Are you planning to do that? Not now. It is a sharding-related feature. I'm not sure that this app

Re: Review for GetWALAvailability()

On 2020/06/18 16:36, Kyotaro Horiguchi wrote: Mmm. I hurried too much.. At Thu, 18 Jun 2020 16:32:59 +0900 (JST), Kyotaro Horiguchi wrote in If name is specified (so slot is NULL) to ReplicationSlotAcquireInternal and the slot is not found, the ereport in following code dereferences NULL.

hash as an search key and hash collision

I want to maintain an internal table which the primary key is sql_text and planstmt::text, it is efficient since it both may be very long. So a general idea is to use sql_hash_value and plan_hash_value. Then we have to handle the hash collision case. However I checked the codes both in sr_plans[1

Re: min_safe_lsn column in pg_replication_slots view

On 2020/06/19 16:43, Kyotaro Horiguchi wrote: At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote in On Fri, Jun 19, 2020 at 04:13:27PM +0900, Fujii Masao wrote: Agreed. But isn't it too late to remove the columns (i.e., change the catalog) for v13? Because v13 beta1 was already rele

Re: Global snapshots

>> would like to know if the patch related to CSN based snapshot [2] is a >> precursor for this, if not, then is it any way related to this patch >> because I see the latest reply on that thread [2] which says it is an >> infrastructure of sharding feature but I don't understand completely >> whet

update substring pattern matching syntax

At it is described that the substring pattern matching syntax in PostgreSQL does not conform to the current standard. PostgreSQL implements SUBSTRING(text FROM pattern FOR escapechar) wherea

Re: snowball ASCII stemmer configuration

On 2020-06-16 16:37, Tom Lane wrote: After further reflection, I think these are indeed mistakes and we should change them all. The argument for the Russian/English case, AIUI, is "if we come across an all-ASCII word, it is most certainly not Russian, and the most likely Latin-based language is

Re: Transactions involving multiple postgres foreign servers, take 2

On Thu, Jun 18, 2020 at 6:49 PM Bruce Momjian wrote: > > On Thu, Jun 18, 2020 at 04:09:56PM +0530, Amit Kapila wrote: > > You are right and we are not going to claim that after this feature is > > committed. This feature has independent use cases like it can allow > > parallel copy when foreign t

Re: doing something about the broken dynloader.h symlink

On Fri, Jun 19, 2020 at 8:02 PM Peter Eisentraut wrote: > +[# Remove links created by old versions of configure, so that there > +# are no broken symlinks in the tree > +rm -f src/include/dynloader.h]) +1

Re: doing something about the broken dynloader.h symlink

On Fri, Jun 19, 2020 at 10:08:05PM +1200, Thomas Munro wrote: > On Fri, Jun 19, 2020 at 8:02 PM Peter Eisentraut > wrote: >> +[# Remove links created by old versions of configure, so that there >> +# are no broken symlinks in the tree >> +rm -f src/include/dynloader.h]) > > +1 Not sure about you

Re: update substring pattern matching syntax

pá 19. 6. 2020 v 11:42 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > At > < > https://wiki.postgresql.org/wiki/PostgreSQL_vs_SQL_Standard#Obsolete_syntax_for_substring.28.29> > > it is described that the substring pattern matching syntax in PostgreSQL > does not conform

Re: doing something about the broken dynloader.h symlink

On Fri, Jun 19, 2020 at 12:08 PM Thomas Munro wrote: > > On Fri, Jun 19, 2020 at 8:02 PM Peter Eisentraut > wrote: > > +[# Remove links created by old versions of configure, so that there > > +# are no broken symlinks in the tree > > +rm -f src/include/dynloader.h]) > > +1 +1

Re: Parallel copy

Hi, I just got some time to review the first patch in the list i.e. 0001-Copy-code-readjustment-to-support-parallel-copy.patch. As the patch name suggests, it is just trying to reshuffle the existing code for COPY command here and there. There is no extra changes added in the patch as such, but st

Re: missing support for Microsoft VSS Writer

On Fri, Jun 19, 2020 at 7:20 AM Pavel Stehule wrote: > some czech user reported a broken database when he used a repair point on > Microsoft Windows. > > The reply from Microsoft was, so it is not a Microsoft issue, but Postgres > issue, because Postgres doesn't handle VSS process correctly, and

Re: min_safe_lsn column in pg_replication_slots view

On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote: > On 2020/06/19 16:43, Kyotaro Horiguchi wrote: >> At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier >> wrote in >>> So we usually avoid to do that between betas, but my take here is that >>> a catalog bump is better than regretting a

Re: min_safe_lsn column in pg_replication_slots view

At Fri, 19 Jun 2020 21:15:52 +0900, Michael Paquier wrote in > On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote: > > On 2020/06/19 16:43, Kyotaro Horiguchi wrote: > >> At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier > >> wrote in > >>> So we usually avoid to do that between beta

Re: Global snapshots

On Fri, Jun 19, 2020 at 05:03:20PM +0800, movead...@highgo.ca wrote: > > >> would like to know if the patch related to CSN based snapshot [2] is a > >> precursor for this, if not, then is it any way related to this patch > >> because I see the latest reply on that thread [2] which says it is an >

Re: snowball ASCII stemmer configuration

Peter Eisentraut writes: > Do we *have* to have an ASCII stemmer that corresponds to an actual > language? Couldn't we use the simple stemmer or no stemmer at all? > In my experience, ASCII text in, say, Russian or Greek will typically be > acronyms or brand names or the like, and there doesn't

Re: doing something about the broken dynloader.h symlink

Peter Eisentraut writes: > When you switch a built REL_11_STABLE or earlier to REL_12_STABLE or > later, you get during make install (or, therefore, make check) an error While I don't necessarily object to the hack you propose here, it seems to me that really we need to caution people more stron

RE: archive status ".ready" files may be created too early

> On 5/28/20, 11:42 PM, "matsumura@fujitsu.com" > wrote: > > I'm preparing a patch that backend inserting segment-crossboundary > > WAL record leaves its EndRecPtr and someone flushing it checks > > the EndRecPtr and notifies.. I'm sorry for my slow work. I attach a patch. I also attach a s

Re: [PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()

On 2020-06-19 03:59, Michael Paquier wrote: On Thu, Jun 18, 2020 at 03:39:09PM +0300, Vyacheslav Makarov wrote: If the WAL segment for the specified restart_lsn (STOP_LSN of the backup) exists, then the function will create a physical replication slot and will keep all the WAL segments require

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On Tue, Jun 2, 2020 at 2:51 PM Andrey Lepikhov wrote: > 02.06.2020 05:02, Etsuro Fujita пишет: > > I think I also thought something similar to this before [1]. Will take a > > look. I'm still reviewing the patch, but let me comment on it. > > [1] > > https://www.postgresql.org/message-id/2399

Re: More tzdb fun: POSIXRULES is being deprecated upstream

I wrote: > I experimented with removing the posixrules support, and was quite glad > I did, because guess what: our regression tests fall over. If we do > nothing we can expect that they'll start failing on various random systems > come this fall. To clarify, you can produce this failure without

Re: Add A Glossary

On 2020-06-19 01:51, Alvaro Herrera wrote: On 2020-Jun-16, Justin Pryzby wrote: On Tue, Jun 16, 2020 at 08:09:26PM -0400, Alvaro Herrera wrote: I noticed one typo: 'aggregates functions' should be 'aggregate functions' And one thing that I am not sure of (but strikes me as a bit odd): ther

Re: hash as an search key and hash collision

On Fri, Jun 19, 2020 at 04:24:01PM +0800, Andy Fan wrote: I want to maintain an internal table which the primary key is sql_text and planstmt::text, it is efficient since it both may be very long. So a general idea is to use sql_hash_value and plan_hash_value. Then we have to handle the hash col

Re: Re: [HACKERS] Custom compression methods

On Thu, Mar 7, 2019 at 2:51 AM Alexander Korotkov wrote: > Yes. I took a look at code of this patch. I think it's in pretty good > shape. But high level review/discussion is required. I agree that the code of this patch is in pretty good shape, although there is a lot of rebasing needed at th

Re: Failures with installcheck and low work_mem value in 13~

On Tue, Jun 16, 2020 at 02:39:47PM +0900, Michael Paquier wrote: On Mon, Jun 15, 2020 at 10:29:41PM +0900, Michael Paquier wrote: Attempting to run installcheck with 13~ and a value of work_mem lower than the default causes two failures, both related to incremental sorts (here work_mem = 1MB): 1

Re: Failures with installcheck and low work_mem value in 13~

On Mon, Jun 15, 2020 at 10:29:41PM +0900, Michael Paquier wrote: Hi all, Attempting to run installcheck with 13~ and a value of work_mem lower than the default causes two failures, both related to incremental sorts (here work_mem = 1MB): 1) Test incremental_sort: @@ -4,12 +4,13 @@ select * from

Re: Add A Glossary

Thanks for these fixes! I included all of these. On 2020-Jun-19, Erik Rijkers wrote: > And one thing that I am not sure of (but strikes me as a bit odd): > there are several cases of > 'are enforced unique'. Should that not be > 'are enforced to be unique' ? I included this change too; I am no

Re: Failures with installcheck and low work_mem value in 13~

Tomas Vondra writes: > I don't think the tests can be made not to depend on work_mem, because > it costing of sort / incremental sort depends on the value. I agree > setting the work_mem at the beginning of the test script is the right > solution. I'm a bit skeptical about changing anything here.

Re: Failures with installcheck and low work_mem value in 13~

On Fri, Jun 19, 2020 at 10:27 AM Tom Lane wrote: > Tomas Vondra writes: > > I don't think the tests can be made not to depend on work_mem, because > > it costing of sort / incremental sort depends on the value. I agree > > setting the work_mem at the beginning of the test script is the right > >

Re: compile cube extension with float4 precision storing

On Fri, Jun 12, 2020 at 02:41:08PM +0300, Siarhei D wrote: Is it possible to make cube extension with float(4bytes) precision instead of double(8bytes)? I use cube extension for storing embedding vectors and calculation distance on them. During comparing vectors, a 4byte float precision is enoug

Re: Creating a function for exposing memory usage of backend process

On Wed, Jun 17, 2020 at 11:56 PM Fujii Masao wrote: > > As a first step, to deal with (3) I'd like to add > > pg_stat_get_backend_memory_context() which target is limited to the > > local backend process. > > +1 +1 from me, too. Something that exposed this via shared memory would be quite useful,

Re: [PATCH] Allow to specify restart_lsn in pg_create_physical_replication_slot()

On 2020/06/19 23:20, Alexey Kondratov wrote: On 2020-06-19 03:59, Michael Paquier wrote: On Thu, Jun 18, 2020 at 03:39:09PM +0300, Vyacheslav Makarov wrote: If the WAL segment for the specified restart_lsn (STOP_LSN of the backup) exists, then the function will create a physical replication

Re: Missing HashAgg EXPLAIN ANALYZE details for parallel plans

On 2020-Jun-19, David Rowley wrote: > > + size = offsetof(SharedAggInfo, sinstrument) > > + + pcxt->nworkers * sizeof(AggregateInstrumentation); > > > > => There's a couple places where I'd prefer to see "+" at the end of the > > preceding line (but YMMV). > > I pretty much just copied t

Re: Fast DSM segments

Hi, On 2020-06-19 17:42:41 +1200, Thomas Munro wrote: > On Thu, Jun 18, 2020 at 6:05 PM Thomas Munro wrote: > > Here's a version that adds some documentation. > > I jumped on a dual socket machine with 36 cores/72 threads and 144GB > of RAM (Azure F72s_v2) running Linux, configured with 50GB of

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Peter Eisentraut writes: > On 2020-06-17 20:08, Tom Lane wrote: >> I would definitely be in favor of "nuke it now" with respect to HEAD. >> It's a bit more debatable for the back branches. However, all branches >> are going to be equally exposed to updated system tzdata trees, so >> we've typical

Re: Failures with wal_consistency_checking and 13~

On 2020-Jun-15, Michael Paquier wrote: > I have begun my annual study of WAL consistency across replays, and > wal_consistency_checking = 'all' is pointing out at some issues with > at least VACUUM and SPGist: > FATAL: inconsistent page found, rel 1663/16385/22133, forknum 0, > blkno 15 > CONTEXT

Re: More tzdb fun: POSIXRULES is being deprecated upstream

On Fri, Jun 19, 2020 at 3:27 PM Tom Lane wrote: > Anyway, as I write this I'm kind of talking myself into the position > that we should indeed back-patch this. The apparent stability > benefits of not doing so may be illusory, and if we back-patch then > at least we get to document that there's a

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Robert Haas writes: > It's really unclear to me why we should back-patch this into > already-released branches. I grant your point that perhaps few people > will notice, and also that this might happen at some point the change > will be forced upon us. Nonetheless, we bill our back-branches as > b

Re: Parallel Seq Scan vs kernel read ahead

On Thu, Jun 18, 2020 at 10:10 PM David Rowley wrote: > Here's a patch which caps the maximum chunk size to 131072. If > someone doubles the page size then that'll be 2GB instead of 1GB. I'm > not personally worried about that. Maybe use RELSEG_SIZE? > I tested the performance on a Windows 10 la

Re: More tzdb fun: POSIXRULES is being deprecated upstream

On Fri, Jun 19, 2020 at 3:55 PM Tom Lane wrote: > The code delta is small enough that I don't foresee any real maintenance > problem if we let the back branches differ from HEAD/v13 on this point. > What I'm concerned about is that people depending on the existing > behavior are likely to wake up

Re: More tzdb fun: POSIXRULES is being deprecated upstream

Robert Haas writes: > On Fri, Jun 19, 2020 at 3:55 PM Tom Lane wrote: >> What I'm concerned about is that people depending on the existing >> behavior are likely to wake up one fine morning and discover that it's >> broken after a routine tzdata update. I think that it'd be a better >> user expe

Re: More tzdb fun: POSIXRULES is being deprecated upstream

I wrote: > Robert Haas writes: >> It might be nice to know what >> Debian, RHEL, etc. plan to do about this, but I'm not sure how >> practical it is to find out. > There's probably no way to know until it happens :-(. On the other hand, for the open-source players, it might be easier to guess.

Re: pg_dump, gzwrite, and errno

On 2020-Jun-18, Tom Lane wrote: > Surely it's insufficient as-is, because there is no reason to suppose > that errno is zero at entry. You'd need to set errno = 0 first. Oh, right. > Also it's fairly customary in our sources to include a comment about > this machination; so the full ritual is u

Re: pg_regress cleans up tablespace twice.

On Thu, Jun 18, 2020 at 1:42 PM Michael Paquier wrote: > Thanks, applied this part to HEAD then after more testing. Hmm, somehow this (well I guess it's this commit based on timing and the area it touches, not sure exactly why) made cfbot's Windows build fail, like this: --- C:/projects/postgres

Re: update substring pattern matching syntax

On 6/19/20 11:42 AM, Peter Eisentraut wrote: > At > > it is described that the substring pattern matching syntax in PostgreSQL > does not conform to the current standard.  PostgreSQL implements > >   

Re: Review for GetWALAvailability()

On 2020-Jun-17, Kyotaro Horiguchi wrote: > @@ -9524,7 +9533,7 @@ GetWALAvailability(XLogRecPtr targetLSN) >* the first WAL segment file since startup, which causes the status > being >* wrong under certain abnormal conditions but that doesn't actually > harm. >*/ > -

Re: Cache relation sizes?

On Sat, Apr 11, 2020 at 4:10 PM Thomas Munro wrote: > I received a report off-list from someone who experimented with the > patch I shared earlier on this thread[1], using a crash recovery test > similar to one I showed on the WAL prefetching thread[2] (which he was > also testing, separately). R

Re: hash as an search key and hash collision

On Sat, Jun 20, 2020 at 12:34 AM Tomas Vondra wrote: > On Fri, Jun 19, 2020 at 04:24:01PM +0800, Andy Fan wrote: > >I want to maintain an internal table which the primary key is sql_text and > >planstmt::text, it is efficient since it both may be very long. So a > >general > >idea is to use sql_

Re: min_safe_lsn column in pg_replication_slots view

On 2020/06/19 21:15, Michael Paquier wrote: On Fri, Jun 19, 2020 at 05:34:01PM +0900, Fujii Masao wrote: On 2020/06/19 16:43, Kyotaro Horiguchi wrote: At Fri, 19 Jun 2020 16:36:09 +0900, Michael Paquier wrote in So we usually avoid to do that between betas, but my take here is that a cata

Re: min_safe_lsn column in pg_replication_slots view

On 2020-Jun-20, Fujii Masao wrote: > It's better if we can do that. But I think that we should hear Alvaro's > opinion > about this before rushing to push the patch. Even if we miss beta2 as the > result > of that, I'm ok. We would be able to push something better into beta3. > So, CC Alvaro. U

Re: min_safe_lsn column in pg_replication_slots view

On 2020-Jun-19, Michael Paquier wrote: > If we want to make this happen, I am afraid that the time is short as > beta2 is planned for next week. As the version will be likely tagged > by Monday US time, it would be good to get this addressed within 48 > hours to give some room to the buildfarm to

Re: pg_regress cleans up tablespace twice.

On Sat, Jun 20, 2020 at 09:33:26AM +1200, Thomas Munro wrote: > Hmm, somehow this (well I guess it's this commit based on timing and > the area it touches, not sure exactly why) made cfbot's Windows build > fail, like this: > > --- C:/projects/postgresql/src/test/regress/expected/tablespace.out >

Re: pg_regress cleans up tablespace twice.

On Sat, Jun 20, 2020 at 2:42 PM Michael Paquier wrote: > > +ERROR: could not set permissions on directory > > "C:/projects/postgresql/src/test/regress/testtablespace": Permission > > denied > > > > Any ideas? Here's what it does: > > > > https://github.com/macdice/cfbot/tree/master/appveyor > > I

Re: Failures with installcheck and low work_mem value in 13~

On Fri, Jun 19, 2020 at 10:28:56AM -0700, Peter Geoghegan wrote: > On Fri, Jun 19, 2020 at 10:27 AM Tom Lane wrote: >> I'm a bit skeptical about changing anything here. There are quite >> a large number of GUCs that can affect the regression results, and >> it wouldn't be sane to try to force the

Re: min_safe_lsn column in pg_replication_slots view

On Sat, Jun 20, 2020 at 7:12 AM Alvaro Herrera wrote: > > On 2020-Jun-19, Michael Paquier wrote: > > > If we want to make this happen, I am afraid that the time is short as > > beta2 is planned for next week. As the version will be likely tagged > > by Monday US time, it would be good to get this

Re: pg_regress cleans up tablespace twice.

On Sat, Jun 20, 2020 at 03:01:36PM +1200, Thomas Munro wrote: > Thanks for the clue. Appveyor runs your build script as a privileged > user (unlike, I assume, the build farm animals), and that has caused a > problem with this test in the past, though I don't know the details. > I might go and teac

Re: min_safe_lsn column in pg_replication_slots view

On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote: > On Sat, Jun 20, 2020 at 7:12 AM Alvaro Herrera > wrote: >> I don't disagree with removing the LSN column, but at the same time we >> need to provide *some* way for users to monitor this, so let's add a >> function to extract the value