Re: doc review for v13

On Wed, Sep 09, 2020 at 09:37:42AM -0500, Justin Pryzby wrote: > I've added a few more. I have done an extra round of review on this patch series, and applied what looked obvious to me (basically the points already discussed upthread). Some parts applied down to 9.6 for the docs. -- Michael sig

Re: Implement UNLOGGED clause for COPY FROM

Hi. I expect I have some basic misunderstanding because IMO now this thread seems to have come full circle. Earlier, Osumi-san was rejecting the idea of using ALTER TABLE tbl SET UNLOGGED on basis that it is too time consuming for large data to switch the table modes [1]. Now the latest idea is

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:53 AM Dilip Kumar wrote: > On Thu, Sep 10, 2020 at 11:47 AM Amit Kapila > wrote: > >> On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar >> wrote: >> > >> > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila >> wrote: >> >> >> >> Hi, >> >> >> >> There is a recent build farm fail

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:47 AM Amit Kapila wrote: > On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar > wrote: > > > > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila > wrote: > >> > >> Hi, > >> > >> There is a recent build farm failure [1] in one of the test_decoding > >> tests as pointed by Tom Lan

Re: Inconsistency in determining the timestamp of the db statfile.

On Thu, 10 Sep 2020 at 14:24, Amit Kapila wrote: > > On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao > wrote: > > > > On 2020/09/09 22:57, Magnus Hagander wrote: > > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > > wrote: > > > > > > On Wed, Sep 09, 2020 a

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:42 AM Dilip Kumar wrote: > > On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila wrote: >> >> Hi, >> >> There is a recent build farm failure [1] in one of the test_decoding >> tests as pointed by Tom Lane [2]. The failure report is shown below: >> >> @@ -71,6 +71,8 @@ >>

Re: Bug in logical decoding of in-progress transactions

On Thu, Sep 10, 2020 at 11:29 AM Amit Kapila wrote: > Hi, > > There is a recent build farm failure [1] in one of the test_decoding > tests as pointed by Tom Lane [2]. The failure report is shown below: > > @@ -71,6 +71,8 @@ > data > --

Bug in logical decoding of in-progress transactions

Hi, There is a recent build farm failure [1] in one of the test_decoding tests as pointed by Tom Lane [2]. The failure report is shown below: @@ -71,6 +71,8 @@ data -- opening a streamed block for transaction + closing a streamed bloc

Proposal of new PostgreSQL Extension - PGSpiderExt

I would like to propose new PostgreSQL Extension - PGSpiderExt. * What is PGSpiderExt This extension makes it possible to treat multiple tables having the same schema as a single virtual table. We call this table as a multi-tenant table. If a foreign table has a key column identifying a table, y

Re: PATCH: Attempt to make dbsize a bit more consistent

On 2020-09-09 12:41 a.m., gkokola...@pm.me wrote: ‐‐‐ Original Message ‐‐‐ On Tuesday, 8 September 2020 22:26, David Zhang wrote: I found the function "table_relation_size" is only used by buffer manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and "RELKIND_MATVIEW", i.e.    

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 9:37 PM Fujii Masao wrote: > > On 2020/09/09 22:57, Magnus Hagander wrote: > > On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra > > wrote: > > > > On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: > > >On Wed, Sep 9, 2020

Re: extension patch of CREATE OR REPLACE TRIGGER

On Thu, Sep 10, 2020 at 12:34 PM osumi.takami...@fujitsu.com wrote: > I attached the v11 patch. The v11 patch looked OK to me. Since I have no more review comments I am marking this as "ready for committer". Kind Regards, Peter Smith. Fujitsu Australia

Re: please update ps display for recovery checkpoint

On Wed, Sep 09, 2020 at 09:00:50PM -0500, Justin Pryzby wrote: > What would you want the checkpointer's ps to say ? > > Normally it just says: > postgres 3468 3151 0 Aug27 ?00:20:57 postgres: checkpointer > Note that CreateCheckPoint() can also be calle

Re: Fix for parallel BTree initialization bug

On Tue, Sep 08, 2020 at 06:25:03PM +, Jameson, Hunter 'James' wrote: > Hi, I ran across a small (but annoying) bug in initializing parallel BTree > scans, which causes the parallel-scan state machine to get confused. The fix > is one line; the description is a bit longer— What postgres versi

Re: Proposals for making it easier to write correct bgworkers

čt 10. 9. 2020 v 5:02 odesílatel Craig Ringer napsal: > Hi all > > As I've gained experience working on background workers, it's become > increasingly clear that they're a bit too different to normal backends for > many nontrivial uses. > > I thought I'd take a moment to note some of it here, alo

Re: Resetting spilled txn statistics in pg_stat_replication

On Wed, Sep 9, 2020 at 3:20 PM Amit Kapila wrote: > > On Tue, Sep 8, 2020 at 7:02 PM Amit Kapila wrote: > > > > Comments on the latest patch: > > = > > > > Apart from the comments I gave yesterday, another thing I was > wondering is how to write some tests for this pat

Proposals for making it easier to write correct bgworkers

Hi all As I've gained experience working on background workers, it's become increasingly clear that they're a bit too different to normal backends for many nontrivial uses. I thought I'd take a moment to note some of it here, along with some proposals for things we could potentially do to make it

RE: SIGQUIT handling, redux

From: Tom Lane > This is straying a bit from the stated topic of this thread, but ... > I did some further looking around to see whether there were any > unsafe signal handlers besides SIGQUIT ones. The situation is not > too awful, but I did find several issues not already mentioned > in this th

Re: Division in dynahash.c due to HASH_FFACTOR

On Tue, Sep 8, 2020 at 11:17 PM Jakub Wartak wrote: > I agree with both, I just thought it might be interesting finding as this > idiv might be (?) present in other common paths like ReadBuffer*() / > PinBuffer() (some recent discussions, maybe on NUMA boxes), not just WAL > recovery as it seem

RE: extension patch of CREATE OR REPLACE TRIGGER

Hello, Peter-San > > That's a great idea. I've applied this idea to the latest patch v10. > > > > COMMENT create_trigger.sgml (typo/wording) > > "vise versa" -> "vice versa" Sorry and thank you for all your pointing out. > BEFORE > You cannot replace triggers with a different type of tri

Re: SIGQUIT handling, redux

I wrote: > Of course, this is only safe if the SIGQUIT handler is safe to be invoked > anywhere, so I did a quick survey of backend signal handlers to see if > that is true. This is straying a bit from the stated topic of this thread, but ... I did some further looking around to see whether there

Re: please update ps display for recovery checkpoint

On Mon, Aug 31, 2020 at 03:52:44PM +0900, Michael Paquier wrote: > On Thu, Aug 20, 2020 at 05:09:05PM +0900, Michael Paquier wrote: > > That could be helpful. Wouldn't it be better to use "end-of-recovery > > checkpoint" instead? That's the common wording in the code comments. > > > > I don't se

RE: Global snapshots

Hi Andrey san, From: Andrey V. Lepikhov > > From: tsunakawa.ta...@fujitsu.com > >> While Clock-SI seems to be considered the best promising for global > >>> > Could you take a look at this patent? I'm afraid this is the Clock-SI > >>> > for MVCC. > Microsoft holds this until 2031. I couldn't

Re: extension patch of CREATE OR REPLACE TRIGGER

On Wed, Sep 9, 2020 at 11:28 PM osumi.takami...@fujitsu.com wrote: > That's a great idea. I've applied this idea to the latest patch v10. COMMENT create_trigger.sgml (typo/wording) "vise versa" -> "vice versa" BEFORE You cannot replace triggers with a different type of trigger, that means

RE: Transactions involving multiple postgres foreign servers, take 2

Alexey-san, Sawada-san, cc: Fujii-san, From: Fujii Masao > But if we > implement 2PC as the improvement on FDW independently from PostgreSQL > sharding, I think that it's necessary to support other FDW. And this is our > direction, isn't it? I understand the same way as Fujii san. 2PC FDW is i

Re: SIGQUIT handling, redux

Here's a draft patch that I think would be reasonable to back-patch. (Before v13, we'd need a bespoke SIGQUIT handler to substitute for SignalHandlerForCrashExit, but that's easy enough.) Aside from comment updates, this * uses SignalHandlerForCrashExit for SIGQUIT * renames startup_die per your

Re: v13: show extended stats target in \d

On Wed, Sep 09, 2020 at 07:22:30PM -0300, Alvaro Herrera wrote: > On 2020-Sep-09, Justin Pryzby wrote: > > > As for the discussion about a separator, I think maybe a comma is enough. I > > doubt anyone is going to think that you can get a valid command by prefixing > > this by "CREATE STATISTICS"

Re: Optimising compactify_tuples()

On Thu, Sep 10, 2020 at 2:34 AM David Rowley wrote: > I think you were adequately caffeinated. You're right that this is > fairly simple to do, but it looks even more simple than looping twice > of the array. I think it's just a matter of looping over the > itemidbase backwards and putting the h

Re: v13: show extended stats target in \d

On 2020-Sep-09, Justin Pryzby wrote: > As for the discussion about a separator, I think maybe a comma is enough. I > doubt anyone is going to think that you can get a valid command by prefixing > this by "CREATE STATISTICS". Actually, it didn't even occur to me it was > valid > command without

Re: v13: show extended stats target in \d

On 2020-Sep-09, Justin Pryzby wrote: > As for the discussion about a separator, I think maybe a comma is enough. I > doubt anyone is going to think that you can get a valid command by prefixing > this by "CREATE STATISTICS". Actually, it didn't even occur to me it was > valid > command without

Re: SIGQUIT handling, redux

I wrote: >> Not only DNS, but all the various auth libraries would have to be >> contended with. Lots of work there compared to the likely rewards. > Wait a minute. The entire authentication cycle happens inside > InitPostgres, using the backend's normal signal handlers. So > maybe we are overt

Re: v13: show extended stats target in \d

On Tue, Sep 01, 2020 at 12:35:19PM +, Georgios Kokolatos wrote: > I will humbly disagree with the current review. I shall refrain from changing > the status though because I do not have very strong feeling about it. Sorry but this was in my spam, and didn't see until now. > > However the pa

Re: SIGQUIT handling, redux

Hi, On 2020-09-09 16:30:37 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2020-09-09 16:09:00 -0400, Tom Lane wrote: > >> We could call it startup_packet_die or something? > > > Yea, I think that'd be good. > > I'll make it so. Thanks! > >> We see backends going through this code on a

Re: [HACKERS] [PATCH] Generic type subscripting

On Wed, Aug 05, 2020 at 04:04:22PM +0200, Dmitry Dolgov wrote: > > On Sun, Aug 02, 2020 at 12:50:12PM +0200, Pavel Stehule wrote: > > > > > > > Maybe this could be salvaged by flushing 0005 in its current form and > > > > having the jsonb subscript executor do something like "if the current > > > >

Re: [Patch] ALTER SYSTEM READ ONLY

Hi, Thomas, there's one point below that could be relevant for you. You can search for your name and/or checkpoint... On 2020-09-01 16:43:10 +0530, Amul Sul wrote: > diff --git a/src/backend/nodes/readfuncs.c b/src/backend/nodes/readfuncs.c > index 42050ab7195..0ac826d3c2f 100644 > --- a/src/bac

Re: PG 13 release notes, first draft

Hi, On 5/4/20 11:16 PM, Bruce Momjian wrote: > I have committed the first draft of the PG 13 release notes. You can > see them here: > > https://momjian.us/pgsql_docs/release-13.html > > It still needs markup, word wrap, and indenting. The community doc > build should happen in a few hou

Re: SIGQUIT handling, redux

I wrote: > Not only DNS, but all the various auth libraries would have to be > contended with. Lots of work there compared to the likely rewards. Wait a minute. The entire authentication cycle happens inside InitPostgres, using the backend's normal signal handlers. So maybe we are overthinking

Re: SIGQUIT handling, redux

Andres Freund writes: > On 2020-09-09 16:09:00 -0400, Tom Lane wrote: >> We could call it startup_packet_die or something? > Yea, I think that'd be good. I'll make it so. >> We see backends going through this code on a very regular basis in the >> buildfarm, but complete hangs are rare as can b

Re: WIP: BRIN multi-range indexes

On Wed, Sep 09, 2020 at 04:53:30PM -0300, Alvaro Herrera wrote: On 2020-Sep-09, Tomas Vondra wrote: There are some minor optimizations possible - for example I noticed we call minmax_multi_get_strategy_procinfo often because it happens in a loop, and we could easily do it just once. But that sa

Re: SIGQUIT handling, redux

Hi, On 2020-09-09 16:09:00 -0400, Tom Lane wrote: > Andres Freund writes: > > I wish startup_die() weren't named startup_ - every single time I see > > the name I think it's about the startup process... > > We could call it startup_packet_die or something? Yea, I think that'd be good. > > I t

Re: SIGQUIT handling, redux

Andres Freund writes: > I wish startup_die() weren't named startup_ - every single time I see > the name I think it's about the startup process... We could call it startup_packet_die or something? > I think StartupPacketTimeoutHandler is another case? Yeah. Although it's a lot less risky, sinc

Re: WIP: BRIN multi-range indexes

On 2020-Sep-09, Tomas Vondra wrote: > There are some minor optimizations possible - for example I noticed we > call minmax_multi_get_strategy_procinfo often because it happens in a > loop, and we could easily do it just once. But that saves only about 10% > or so, it's not a ground-breaking optimi

Re: WIP: BRIN multi-range indexes

On Wed, Sep 09, 2020 at 03:40:41PM -0300, Alvaro Herrera wrote: On 2020-Sep-09, John Naylor wrote: create index on t using brin (a); CREATE INDEX Time: 1631.452 ms (00:01.631) create index on t using brin (a int8_minmax_multi_ops); CREATE INDEX Time: 6521.026 ms (00:06.521) It seems strang

Re: SIGQUIT handling, redux

Hi, On 2020-09-08 17:39:24 -0400, Tom Lane wrote: > Of course, this is only safe if the SIGQUIT handler is safe to be invoked > anywhere, so I did a quick survey of backend signal handlers to see if > that is true. I immediately found pgarch_exit() which surely is not. It > turns out that Horigu

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 2020-09-09 15:38, Tom Lane wrote: and a few more calls of int8_numeric that could be converted. I think the attached updated version is committable, and I'd recommend going ahead with that regardless of the rest of this. I hadn't realized how many random calls of int8_numeric and int4_numeri

Re: Inconsistent Japanese name order in v13 contributors list

Alvaro Herrera writes: > On 2020-Sep-09, Fujii Masao wrote: >> Using given-name-first order is our consensus? > That's indeed our historical practice. See previous thread where we've > discussed this at length, > https://www.postgresql.org/message-id/flat/20150613231826.GY133018%40postgresql.org

Re: WIP: BRIN multi-range indexes

On 2020-Sep-09, John Naylor wrote: > create index on t using brin (a); > CREATE INDEX > Time: 1631.452 ms (00:01.631) > create index on t using brin (a int8_minmax_multi_ops); > CREATE INDEX > Time: 6521.026 ms (00:06.521) It seems strange that the multi-minmax index takes so much longer to buil

Re: Remove line length restriction in passwordFromFile()

Fujii Masao writes: > On 2020/09/10 2:16, Tom Lane wrote: >> Hm, in a quick search I only see 2eb3bc588 which was not back-patched >> ... which commits are you thinking of? > I thought your commit b55b4dad99 included the improvement on comment > detection and was back-patched Oh, right, I d

Re: Inconsistent Japanese name order in v13 contributors list

On 2020-Sep-09, Fujii Masao wrote: > On 2020/09/09 14:15, Etsuro Fujita wrote: > > Hi, > > > > Attached is a patch to standardize Japanese names as given-name-first > > in the v13 contributors list as before. > > Using given-name-first order is our consensus? I was thinking we have not > reached

Re: Remove line length restriction in passwordFromFile()

On 2020/09/10 2:16, Tom Lane wrote: Fujii Masao writes: On 2020/09/10 1:48, Tom Lane wrote: We could adjust the release-note entry for your patch to say "Improve comment detection for .pgpass files", or we could decide it's not worth documenting that part and just drop the entry. "Improv

Re: shared-memory based stats collector

Stephen Frost writes: > Just FYI, Tom's started a thread which includes this over here- > https://postgr.es/m/1850884.1599601...@sss.pgh.pa.us Per that discussion, I'm about to go and commit the 0001 patch from this thread, which will cause the cfbot to not be able to apply the patchset anymore t

Re: Transactions involving multiple postgres foreign servers, take 2

On 2020/09/08 12:03, Amit Kapila wrote: On Tue, Sep 8, 2020 at 8:05 AM Fujii Masao wrote: On 2020/09/08 10:34, Amit Kapila wrote: On Mon, Sep 7, 2020 at 2:29 PM Fujii Masao wrote: IMO it's not easy to commit this 2PC patch at once because it's still large and complicated. So I'm thinkin

Re: WIP: BRIN multi-range indexes

On Wed, Sep 09, 2020 at 12:04:28PM -0400, John Naylor wrote: On Sat, Sep 5, 2020 at 7:21 PM Tomas Vondra wrote: OK, here is a rebased version. Most of the breakage was due to changes to the BRIN sgml docs. Hi Tomas, I plan on trying some different queries on different data distributions to

Re: More aggressive vacuuming of temporary tables

Hi, On 2020-09-09 10:14:04 -0400, Stephen Frost wrote: > > I've been toying with a patch that introduces more smarts about when a > > row is removable, by looking more closely whether a specific row > > versions are visible (e.g. in the common case of one old snapshot and > > lots of newer rows).

Re: Global snapshots

On 2020/09/09 2:00, Alexey Kondratov wrote: On 2020-09-08 14:48, Fujii Masao wrote: On 2020/09/08 19:36, Alexey Kondratov wrote: On 2020-09-08 05:49, Fujii Masao wrote: On 2020/09/05 3:31, Alexey Kondratov wrote: Attached is a patch, which implements a plain 2PC in the postgres_fdw and ad

Re: Remove line length restriction in passwordFromFile()

Fujii Masao writes: > On 2020/09/10 1:48, Tom Lane wrote: >> We could adjust the release-note entry for your patch to say >> "Improve comment detection for .pgpass files", or we could decide >> it's not worth documenting that part and just drop the entry. > "Improve comment detection for .pgpass

Re: Minor cleanup of partbounds.c

On 2020-Sep-09, Etsuro Fujita wrote: > Here is a patch for minor cleanup of the partbounds.c changes made by > commit c8434d64c: 1) removes a useless assignment (in normal builds) LGTM. > and 2) improves comments a little. No objection to changing "bounds" to "range bounds". I think the point

Re: Remove line length restriction in passwordFromFile()

On 2020/09/10 1:48, Tom Lane wrote: Fujii Masao writes: The patch was back-patched to v13, but v13 release note still has the following item. Tighten libpq's overlength-line handling and comment detection for .pgpass files (Fujii Masao) This should be changed to the following o

Re: Yet another fast GiST build

> 9 сент. 2020 г., в 20:39, Heikki Linnakangas написал(а): > > On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: >> On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: >>> Come to think of it, the point z-order comparator could benefit a lot >>> from key abbreviation, too. You c

Re: Remove line length restriction in passwordFromFile()

Fujii Masao writes: > The patch was back-patched to v13, but v13 release note still has the > following item. > Tighten libpq's overlength-line handling and comment detection for > .pgpass files (Fujii Masao) > This should be changed to the following or something? > Teach libpq to h

Re: Inconsistent Japanese name order in v13 contributors list

On 2020/09/09 21:15, Peter Eisentraut wrote: On 2020-09-09 07:40, Fujii Masao wrote: Attached is a patch to standardize Japanese names as given-name-first in the v13 contributors list as before. Using given-name-first order is our consensus? I was thinking we have not reached that yet and o

Re: Remove line length restriction in passwordFromFile()

On 2020/09/02 0:14, Tom Lane wrote: Fujii Masao writes: The patch looks good to me, except the following minor thing. + if (fgets(buf.data + buf.len, buf.maxlen - buf.len - 1, fp) == NULL) IIUC fgets() reads the data with the specified size - 1, so ISTM that -1 of "buf.maxlen

Re: Minor fixes for upcoming version 13

John Naylor writes: > On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin wrote: >> 09.09.2020 18:29, Tom Lane wrote: >>> But it's not user-visible is it? That should surely be a can't-happen >>> case. >> I've encountered this while translating NLS messages in postgres.po and >> ecpg.po. So I thin

Re: Minor fixes for upcoming version 13

On Wed, Sep 9, 2020 at 12:16 PM Alexander Lakhin wrote: > > Hello Tom, > > 09.09.2020 18:29, Tom Lane wrote: > > But it's not user-visible is it? That should surely be a can't-happen > > case. > I've encountered this while translating NLS messages in postgres.po and > ecpg.po. So I think it shoul

Re: Minor fixes for upcoming version 13

Hello Tom, 09.09.2020 18:29, Tom Lane wrote: > Alexander Lakhin writes: >> Please consider fixing minor defects in the source code and documentation. > I agree with all of these, except the markup fixes in bgworker.sgml > still seem not right; it should be more like > > RegisterBackgroundWorker

Re: VACUUM (INTERRUPTIBLE)?

On Wed, Sep 9, 2020 at 12:58 AM Andres Freund wrote: > Hi, > > On 2020-09-08 22:30:40 +0200, Magnus Hagander wrote: > > One thing I've been wanting many times but never properly got around to > > investigating how much work it would be to make happen, was to be able to > > trigger an autovacuum m

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020/09/09 22:57, Magnus Hagander wrote: On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote: On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: >On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander mailto:mag...@hagander.net>> wrote: >

Re: WIP: BRIN multi-range indexes

On Sat, Sep 5, 2020 at 7:21 PM Tomas Vondra wrote: > > OK, here is a rebased version. Most of the breakage was due to changes > to the BRIN sgml docs. Hi Tomas, I plan on trying some different queries on different data distributions to get a sense of when the planner chooses a multi-minmax index

Re: Inconsistency in determining the timestamp of the db statfile.

On 2020-Sep-09, Amit Kapila wrote: > I have included Alvaro as he is a committer for 187492b6, so he might > remember something and let us know if this is a mistake or there is > some reason for doing so (return true even when the db entry we are > trying to read is corrupt). Thanks -- I have to

Re: Yet another fast GiST build

On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: Come to think of it, the point z-order comparator could benefit a lot from key abbreviation, too. You could do the point -> zorder conversion in the abbreviation routine. That'

Re: Yet another fast GiST build

On 09/09/2020 15:20, Darafei "Komяpa" Praliaskouski wrote: On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: Come to think of it, the point z-order comparator could benefit a lot from key abbreviation, too. You could do the point -> zorder conversion in the abbreviation routine. That'

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Wed, Sep 09, 2020 at 09:22:00PM +0900, Michael Paquier wrote: > On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote: > > Initially I added List *params, and Michael suggested to retire > > ReindexStmt->concurrent. I provided a patch to do so, initially by leaving > > int > > options

Re: Minor fixes for upcoming version 13

Alexander Lakhin writes: > Please consider fixing minor defects in the source code and documentation. I agree with all of these, except the markup fixes in bgworker.sgml still seem not right; it should be more like RegisterBackgroundWorker(BackgroundWorker *worker) > 6. "unhandled previous s

Re: unsupportable composite type partition keys

On Wed, Sep 9, 2020 at 4:17 PM Jobin Augustine wrote: > > Is there a way out if someone accidentally executes the same test case > against PG12? > > testdb=# create table partitioned (a int, b int) > testdb-# partition by list ((row(a, b)::partitioned)); > CREATE TABLE > testdb=# DROP TABLE par

Re: SIGQUIT handling, redux

I wrote: > Stephen Frost writes: >> As I mentioned over there, I agree that we should do this and we should >> further have the statistics collector also do so, which currently sets >> up SIGQUIT with ShutdownRequestPending() and in its loop decides it's >> fine to write out the stats file (which

Re: SIGQUIT handling, redux

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Of course, this is only safe if the SIGQUIT handler is safe to be invoked >> anywhere, so I did a quick survey of backend signal handlers to see if >> that is true. I immediately found pgarch_exit() which surely is not. It >> turn

Re: shared-memory based stats collector

Greetings, * Kyotaro Horiguchi (horikyota@gmail.com) wrote: > > Shouldn't this: > > > > a) be back-patched, as the other change was > > b) also include a change to have the stats collector (which I realize is > >removed later on in this patch set, but we're talking about fixing > >exi

Re: SIGQUIT handling, redux

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > This is to pull together a couple of recent threads that are seemingly > unrelated to $SUBJECT. > > Over in the long thread at [1] we've agreed to try to make the backend > code actually do what assorted comments claim it does, namely allow > SI

Re: doc review for v13

I've added a few more. -- Justin >From 137321a0d476f66b5e5f21c2f627c407330e50b1 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Mon, 30 Mar 2020 19:43:22 -0500 Subject: [PATCH v8 01/14] doc: btree deduplication commit 0d861bbb702f8aa05c2a4e3f1650e7e8df8c8c27 Author: Peter Geoghegan --- doc

Re: [UNVERIFIED SENDER] Re: Fix for parallel BTree initialization bug

Also, the behavior (=line of code) added by the bug fix is the same as existing code in the same function, _bt_first(), at lines 898, 1096, 1132, 1367. And the calls to _bt_parallel_readpage(), line 903, and _bt_steppage(), line 1416, will also ultimately call _bt_parallel_done(). So the bug see

Re: Optimising compactify_tuples()

On Wed, 9 Sep 2020 at 05:38, Thomas Munro wrote: > > On Wed, Sep 9, 2020 at 3:47 AM David Rowley wrote: > > On Tue, 8 Sep 2020 at 12:08, Thomas Munro wrote: > > > One thought is that if we're going to copy everything out and back in > > > again, we might want to consider doing it in a > > > memo

Re: Reduce the time required for a database recovery from archive.

Greetings, * Dmitry Shulga (d.shu...@postgrespro.ru) wrote: > Overall archive file processing is done one by one, and this might > create a performance bottleneck if archived WAL files are delivered slowly, > because the database server has to wait for arrival of the next > WAL segment before appl

Re: Online checksums patch - once again

> On 7 Sep 2020, at 09:17, Michael Paquier wrote: > Daniel, could you look at that? I believe this boils down to a timing issue, I've included a fix in the v21 patch attached to a previous mail upthread. cheers ./daniel

Re: unsupportable composite type partition keys

Is there a way out if someone accidentally executes the same test case against PG12? testdb=# create table partitioned (a int, b int) testdb-# partition by list ((row(a, b)::partitioned)); CREATE TABLE testdb=# DROP TABLE partitioned; ERROR: cache lookup failed for type 18269 > > Ah, I wasn't

Re: More aggressive vacuuming of temporary tables

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2020-08-28 11:46:49 -0400, Tom Lane wrote: > > It strikes me that when we are vacuuming a temporary table (which > > necessarily will be one of our own session), we don't really need > > to care what the global xmin horizon is. If we're

Re: Fix for parallel BTree initialization bug

Hi, I spent some time trying to create a repro (other than testing it on the production instance where we encountered the bug), but was unable to create one within a reasonable time. The tricky part is that the bug symptoms are run-time symptoms -- so not only do you need, first, to satisfy con

Minor fixes for upcoming version 13

Hello hackers, Please consider fixing minor defects in the source code and documentation. 1. a missing dot in guc.c "SELECT name, short_desc FROM pg_settings WHERE short_desc NOT LIKE '%.'" finds only this one instance. 2. inrange -> in_range the former spelling is unique 3. sigature -> signature

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 9, 2020 at 3:56 PM Tomas Vondra wrote: > On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: > >On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander > wrote: > >> > >> On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila > wrote: > >>> > >> > >> Though in fact the one inconsistent place in

Re: Inconsistency in determining the timestamp of the db statfile.

On Wed, Sep 09, 2020 at 03:53:40PM +0530, Amit Kapila wrote: On Wed, Sep 9, 2020 at 3:15 PM Magnus Hagander wrote: On Wed, Sep 9, 2020 at 5:04 AM Amit Kapila wrote: Though in fact the one inconsistent place in the code now is that if it is corrupt in the db entry part of the file it retu

Re: Online checksums verification in the backend

On Wed, Sep 09, 2020 at 11:25:29AM +0200, Julien Rouhaud wrote: > > I'll do some becnhmarking and see if I can get some figures, but it'll > probably > take some time. In the meantime I'm attaching v11 of the patch that should > address all other comments. I just realized that I forgot to updat

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

Peter Eisentraut writes: > On 2020-09-07 01:46, Tom Lane wrote: >> I reviewed the 0002 patch, finding one bug (in int8_sum) > Ouch, no test coverage. Should we perhaps remove this function, since > it's obsolete and unused? I don't feel a need to. >> and a few >> more calls of int8_numeric th

Minor cleanup of partbounds.c

Here is a patch for minor cleanup of the partbounds.c changes made by commit c8434d64c: 1) removes a useless assignment (in normal builds) and 2) improves comments a little. Best regards, Etsuro Fujita partbounds-cleanup.patch Description: Binary data

RE: extension patch of CREATE OR REPLACE TRIGGER

Hi > Those are fixed OK now, but I found 2 new review points. > > > > COMMENT trigger.c (typo) > > + ereport(ERROR, > + (errcode(ERRCODE_DUPLICATE_OBJECT), > + errmsg("trigger \"%s\" for relation \"%s\" is a constraint trigger", > + stmt->trigname, RelationGetRelationName(rel)), > + errhi

Re: Fix for parallel BTree initialization bug

On Tue, Sep 8, 2020 at 11:55 PM Jameson, Hunter 'James' wrote: > > Hi, I ran across a small (but annoying) bug in initializing parallel BTree > scans, which causes the parallel-scan state machine to get confused. > > > To reproduce, you need a query that: > > > > 1. Executes parallel BTree index

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2020-09-09 15:22, Michael Paquier wrote: On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote: Initially I added List *params, and Michael suggested to retire ReindexStmt->concurrent. I provided a patch to do so, initially by leaving int options and then, after this, removing it to

Re: Online checksums verification in the backend

On Wed, Sep 9, 2020 at 2:37 PM Michael Paquier wrote: > > Another thing that was itching me is the introduction of 3 GUCs with > one new category for the sake of two SQL functions. For VACUUM we > have many things relying on the GUC delays, with autovacuum and manual > vacuum. Perhaps it would m

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

On Wed, Sep 9, 2020 at 6:42 PM Alexey Kondratov wrote: > On 2020-09-09 11:45, Andrey V. Lepikhov wrote: > > This does not seem very convenient and will lead to errors in the > > future. So, I agree with Amit. > > And InitResultRelInfo() may set ri_usesMultiInsert to false by default, > since it's

Re: Online checksums verification in the backend

On Wed, Sep 09, 2020 at 11:25:24AM +0200, Julien Rouhaud wrote: > I assumed that the odds of having to check the buffer twice were so low, and > avoiding to keep a bufmapping lock while doing some IO was an uncontroversial > enough optimisation, but maybe that's only wishful thinking. Perhaps it i

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Tue, Sep 08, 2020 at 07:17:58PM -0500, Justin Pryzby wrote: > Initially I added List *params, and Michael suggested to retire > ReindexStmt->concurrent. I provided a patch to do so, initially by leaving > int > options and then, after this, removing it to "complete the thought", and get > rid

Re: Yet another fast GiST build

On Wed, Sep 9, 2020 at 3:09 PM Heikki Linnakangas wrote: > On 09/09/2020 13:28, Andrey M. Borodin wrote: > > Thanks Darafei! > > > >> 9 сент. 2020 г., в 12:05, Darafei Komяpa Praliaskouski > >> написал(а): > >> > >>> How does the 'sortsupport' routine interact with > >>> 'compress'/'decompress'?

  1   2   >