Re: min_safe_lsn column in pg_replication_slots view

On Tue, Jun 23, 2020 at 7:47 AM Fujii Masao wrote: > > On 2020/06/23 10:10, Kyotaro Horiguchi wrote: > > At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao > > wrote in > >> > >>> I feel such a function is good to have but I am not sure if there is a > >>> need to tie it with the removal of min_saf

Re: xid wraparound danger due to INDEX_CLEANUP false

On Tue, 19 May 2020 at 11:32, Masahiko Sawada wrote: > > On Thu, 7 May 2020 at 16:26, Masahiko Sawada > wrote: > > > > On Thu, 7 May 2020 at 15:40, Masahiko Sawada > > wrote: > > > > > > On Thu, 7 May 2020 at 03:28, Peter Geoghegan wrote: > > > > > > > > On Wed, May 6, 2020 at 2:28 AM Masahiko

Re: min_safe_lsn column in pg_replication_slots view

On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao wrote: > > On 2020/06/22 21:01, Amit Kapila wrote: > > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier > > wrote: > >> > >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote: > >>> On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wr

Re: Threading in BGWorkers (!)

On Tue, 23 Jun 2020 at 13:38, Tom Lane wrote: > James Sewell writes: > > I was talking about PostgreSQL and threading on IRC the other day - > which I > > know is a frowned upon topic - and just wanted to frame the same > questions > > here and hopefully get a discussion going. > > I think the s

Re: Update InsertPgAttributeTuple comment to match new signature

On Mon, Jun 22, 2020 at 04:27:18PM +0200, Daniel Gustafsson wrote: > The comment for InsertPgAttributeTuple no longer, since 911e702077037996, > match > reality as attoptions isn't always initialized to NULL. The attached removes > mention of attoptions, and updates the list of always-NULL attrib

Re: Resetting spilled txn statistics in pg_stat_replication

On Tue, Jun 23, 2020 at 9:32 AM Masahiko Sawada wrote: > > On Sun, 21 Jun 2020 at 06:57, Tomas Vondra > wrote: > > > > > > > >What if the decoding has been performed by multiple backends using the > > >same slot? In that case, it will be difficult to make the judgment > > >for the value of logi

Re: Removal of currtid()/currtid2() and some table AM cleanup

On Tue, Jun 23, 2020 at 01:29:06PM +0900, Michael Paquier wrote: > Sorry, but I am not quite sure what is the relationship between > UseDeclareFetch and currtid2()? Is that related to the use of > SQL_CURSOR_KEYSET_DRIVEN? The only thing I can be sure of here is > that we never call currtid2() in

Re: Threading in BGWorkers (!)

> dispatch the threaded work to a non-Postgres-ish process I’m no expert here but all your solid points about threading with Postgres notwithstanding I think there’s some issues around interrupt handling and general syscalls that doesn’t otherwise play nice with “non-Postgres-ish” *threads*

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

On Tue, Jun 23, 2020 at 8:18 AM Amit Kapila wrote: > > On Mon, Jun 22, 2020 at 6:38 PM Dilip Kumar wrote: > > > > On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila wrote: > > > > > > > > @@ -2012,8 +2014,6 @@ ReorderBufferForget(ReorderBuffer *rb, > > > > > TransactionId xid, XLogRecPtr lsn) > > > > >

Re: tag typos in "catalog.sgml"

Bonjour Michaël, Should it be backpatched? I'm not sure what the usual practice is wrt to small fixes in the doc. The text is right, and this impacts only the appearance of the text, so I did not see that this was enough for a backpatch. Ok. It would mean that possible other doc patches on

Re: Removal of currtid()/currtid2() and some table AM cleanup

On Mon, Jun 15, 2020 at 08:50:23PM +0900, Inoue, Hiroshi wrote: > Sorry for the reply. No problem, thanks for taking the time. > On 2020/06/08 15:52, Michael Paquier wrote: >> On Fri, Jun 05, 2020 at 10:25:00PM +0900, Inoue, Hiroshi wrote: >>We have two >> problems here then: >> 1) We cannot

Re: Transactions involving multiple postgres foreign servers, take 2

On Tue, Jun 23, 2020 at 9:03 AM Masahiko Sawada wrote: > > > I've attached the latest version patches. I've incorporated the review > comments I got so far and improved locking strategy. > Thanks for updating the patch. > Please review it. > I think at this stage it is important that we do some

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

Andres Freund writes: > I am only suggesting that where you save the old location, as currently > done with LVRelStats olderrinfo, you instead use a more specific > type. Not that you should pass that anywhere (except for > update_vacuum_error_info). As things currently stand, I don't think we ne

Re: Global snapshots

On Mon, Jun 22, 2020 at 8:36 PM Bruce Momjian wrote: > > On Sat, Jun 20, 2020 at 05:51:21PM +0530, Amit Kapila wrote: > > I feel if Sawada-San or someone involved in another patch also once > > studies this approach and try to come up with some form of comparison > > then we might be able to make

Re: Testing big endian code with Travis CI's new s390x support

On Mon, Jun 22, 2020 at 6:27 PM Thomas Munro wrote: > arch: > - s390x > > ... and then it needed these lines commented out: > > #before_install: > # - echo '/tmp/%e-%s-%p.core' | sudo tee /proc/sys/kernel/core_pattern One thing I forgot to mention: for some reason slapd is strangely broken on

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

Hi, On 2020-06-22 20:43:47 -0500, Justin Pryzby wrote: > On Mon, Jun 22, 2020 at 01:57:12PM -0700, Andres Freund wrote: > > On 2020-06-22 15:43:11 -0500, Justin Pryzby wrote: > > > On Mon, Jun 22, 2020 at 01:09:39PM -0700, Andres Freund wrote: > > > > I'm also uncomfortable with the approach of ju

Re: Resetting spilled txn statistics in pg_stat_replication

On Sun, 21 Jun 2020 at 06:57, Tomas Vondra wrote: > > On Thu, Jun 18, 2020 at 12:21:17PM +0530, Amit Kapila wrote: > >On Thu, Jun 18, 2020 at 8:01 AM Masahiko Sawada > > wrote: > >> > >> On Wed, 17 Jun 2020 at 20:14, Amit Kapila wrote: > >> > > >> > > >> > I had written above in the context of pe

Re: hashagg slowdown due to spill changes

Hi, I think it'd be good to get the changes that aren't related to projection merged. As far as I can tell there's performance regressions both because of the things I'd listed upthread, and due to the projection issue. That's not obvious because because we first won performance and then lost it

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

On Tue, Jun 23, 2020 at 7:13 AM Justin Pryzby wrote: > > On Mon, Jun 22, 2020 at 01:57:12PM -0700, Andres Freund wrote: > > > > No, I don't think that's a solution. I think it's wrong to have > > something like olderrinfo in the first place. Using a struct with ~25 > > members to store the current

Re: Threading in BGWorkers (!)

James Sewell writes: > I was talking about PostgreSQL and threading on IRC the other day - which I > know is a frowned upon topic - and just wanted to frame the same questions > here and hopefully get a discussion going. I think the short answer about threading in bgworkers (or any other backend

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

On Mon, Jun 22, 2020 at 6:38 PM Dilip Kumar wrote: > > On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila wrote: > > > > > > @@ -2012,8 +2014,6 @@ ReorderBufferForget(ReorderBuffer *rb, > > > > TransactionId xid, XLogRecPtr lsn) > > > > if (txn->base_snapshot != NULL && txn->ninvalidations > 0) > > >

Re: Parallel copy

Thanks Ashutosh For your review, my comments are inline. On Fri, Jun 19, 2020 at 5:41 PM Ashutosh Sharma wrote: > > 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 tryin

Re: Parallel Seq Scan vs kernel read ahead

On Tue, 23 Jun 2020 at 07:33, Robert Haas wrote: > On Mon, Jun 22, 2020 at 12:47 PM Ranier Vilela wrote: > > Questions: > > 1. Why acquire and release lock in retry: loop. > > This is a super-bad idea. Note the coding rule mentioned in spin.h. > There are many discussion on this mailing list abou

Re: min_safe_lsn column in pg_replication_slots view

On 2020/06/23 10:10, Kyotaro Horiguchi wrote: At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao wrote in On 2020/06/22 21:01, Amit Kapila wrote: On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier wrote: On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote: On Sat, Jun 20, 2020

Re: min_safe_lsn column in pg_replication_slots view

On Tue, Jun 23, 2020 at 10:10:37AM +0900, Kyotaro Horiguchi wrote: > At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao > wrote in >> Isn't this confusing? I think that we should store the last removed >> WAL segment to somewhere (e.g., pg_control) and restore it at >> the startup, so that we can s

Extra target list entries for child partitions in DELETE...USING...RETURNING

A few months ago while writing the initial version of a patch to extract the columns that need to be scanned at plan time for use by table AMs, [1] Ashwin and I noticed some peculiar aspects of the reltarget exprs for partition tables for DELETE FROM ... USING... WHERE... RETURNING ... queries (men

Re: SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762

On Sun, Jun 21, 2020 at 01:02:34PM -0700, Andres Freund wrote: > I still maintain that adding restrictions here is a bad idea. Even > disregarding the discussion of running normal queries interspersed, it's > useful to be able to both request WAL and receive logical changes over > the same connecti

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

On Mon, Jun 22, 2020 at 01:57:12PM -0700, Andres Freund wrote: > On 2020-06-22 15:43:11 -0500, Justin Pryzby wrote: > > On Mon, Jun 22, 2020 at 01:09:39PM -0700, Andres Freund wrote: > > > I'm also uncomfortable with the approach of just copying all of > > > LVRelStats in several places: > > > > >

Re: pg_regress cleans up tablespace twice.

On Sun, Jun 21, 2020 at 10:38:22PM +1200, Thomas Munro wrote: > On Sun, Jun 21, 2020 at 8:42 PM Michael Paquier wrote: >> Thanks, and sorry for the trouble. What actually happened back in >> 2018? I can see c2ff3c68 in the git history of the cfbot code, but it >> does not give much details. > >

Move syncscan.c?

Hi, It's a bit odd that syncscan.c is used by both heapam.c and tableam.c, and provides a generic block-synchronization mechanism that other table AMs might want to use too, but it lives under src/backend/access/heap. It doesn't actually do anything heap specific (beyond being block-oriented), an

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

On Mon, Jun 22, 2020 at 08:18:58PM +0300, Alexey Kondratov wrote: > I wonder how it could be used via the replication protocol, but probably > this option should be added there as well for consistency. Mostly the same code path is taken by the SQL function and the replication command, so adding a

Re: min_safe_lsn column in pg_replication_slots view

At Mon, 22 Jun 2020 22:02:51 +0900, Fujii Masao wrote in > > > On 2020/06/22 21:01, Amit Kapila wrote: > > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier > > wrote: > >> > >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote: > >>> On Sat, Jun 20, 2020 at 09:45:52AM +0530, Ami

Re: tag typos in "catalog.sgml"

On Mon, Jun 22, 2020 at 09:09:28PM +0200, Fabien COELHO wrote: > Should it be backpatched? I'm not sure what the usual practice is wrt to > small fixes in the doc. The text is right, and this impacts only the appearance of the text, so I did not see that this was enough for a backpatch. -- Michael

Threading in BGWorkers (!)

Hi hackers, I was talking about PostgreSQL and threading on IRC the other day - which I know is a frowned upon topic - and just wanted to frame the same questions here and hopefully get a discussion going. On IRC RhodiumToad offered the following advice (after a standard there be dragons here dis

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

Justin Pryzby writes: > On Mon, Jun 22, 2020 at 06:15:27PM -0400, Tom Lane wrote: >> That seems like rather pointless micro-optimization really; the struct's >> not *that* large. But I have a different complaint now that I look at >> this code: is it safe at all? I see that the indname field is

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

On Mon, Jun 22, 2020 at 06:15:27PM -0400, Tom Lane wrote: > Andres Freund writes: > > No, I don't think that's a solution. I think it's wrong to have > > something like olderrinfo in the first place. Using a struct with ~25 > > members to store the current state of three variables just doesn't mak

Re: Parallel Seq Scan vs kernel read ahead

On Tue, 23 Jun 2020 at 09:52, Thomas Munro wrote: > > On Fri, Jun 19, 2020 at 2: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. > > I wond

Re: POC: GROUP BY optimization

On Mon, Jun 22, 2020 at 11:50:49AM -0400, Robert Haas wrote: On Sat, May 16, 2020 at 10:56 AM Tomas Vondra wrote: The local effects are trivial - it's for example reordering the pathkeys to make the explicit sort as cheap as possible. This thread already discussed a number of things to base thi

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

Andres Freund writes: > No, I don't think that's a solution. I think it's wrong to have > something like olderrinfo in the first place. Using a struct with ~25 > members to store the current state of three variables just doesn't make > sense. Why isn't this just a LVSavedPosition struct or someth

Re: Parallel Seq Scan vs kernel read ahead

On Fri, Jun 19, 2020 at 2: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. I wonder how this interacts with the sync scan feature. It has a conf

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

Hi, On 2020-06-22 15:43:11 -0500, Justin Pryzby wrote: > On Mon, Jun 22, 2020 at 01:09:39PM -0700, Andres Freund wrote: > > I'm also uncomfortable with the approach of just copying all of > > LVRelStats in several places: > > > > > /* > > > @@ -1580,9 +1648,15 @@ lazy_vacuum_page(Relation onerel

Re: [HACKERS] Custom compression methods

Hi, On 2020-06-19 13:03:02 -0400, Robert Haas wrote: > - I can see three possible ways of breaking our dependence on 'pglz' > for TOAST compression. Option #1 is to pick one new algorithm which we > think is better than 'pglz' in all relevant ways and use it as the > default for all new compressed

Re: Backpatch b61d161c14 (Introduce vacuum errcontext ...)

On Mon, Jun 22, 2020 at 01:09:39PM -0700, Andres Freund wrote: > On 2020-06-22 10:35:47 +0530, Amit Kapila wrote: > > I propose to backpatch b61d161c14 [1] (Introduce vacuum errcontext to > > display additional information.). ... > I think having the additional information in the back branches woul

Re: Parallel Seq Scan vs kernel read ahead

Em seg., 22 de jun. de 2020 às 16:33, Robert Haas escreveu: > Ranier, > > This topic is largely unrelated to the current thread. Also... > Weel, I was trying to improve the patch for the current thread. Or perhaps, you are referring to something else, which I may not have understood. > > On Mon

Re: Default setting for enable_hashagg_disk

On Mon, 2020-06-22 at 15:28 -0400, Robert Haas wrote: > The weirdness is the problem here, at least for me. Generally, I > don't > like GUCs of the form give_me_the_old_strange_behavior=true I agree with all of that in general. > I don't think it necessarily implies that either. I do however have

Re: Backpatch b61d161c14

Hi, On 2020-06-22 10:35:47 +0530, Amit Kapila wrote: > I propose to backpatch b61d161c14 [1] (Introduce vacuum errcontext to > display additional information.). In the recent past, we have seen an > error report similar to "ERROR: found xmin 2157740646 from before > relfrozenxid 1197" from multip

Re: More tzdb fun: POSIXRULES is being deprecated upstream

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. By luck, we now have a moderately well-educated guess about that from Paul Eggert himself [1]: : Probably NetBSD will go first as they tend to buy t

Re: Parallel Seq Scan vs kernel read ahead

Ranier, This topic is largely unrelated to the current thread. Also... On Mon, Jun 22, 2020 at 12:47 PM Ranier Vilela wrote: > Questions: > 1. Why acquire and release lock in retry: loop. This is a super-bad idea. Note the coding rule mentioned in spin.h. There are many discussion on this maili

Re: Default setting for enable_hashagg_disk

On Mon, Jun 22, 2020 at 1:30 PM Jeff Davis wrote: > On Mon, 2020-06-22 at 10:52 -0400, Robert Haas wrote: > > So I feel like the really important thing here is to fix the cases > > that don't come out well with default settings. > > ...with the caveat that perfection is not something to expect fro

EXPLAIN: Non-parallel ancestor plan nodes exclude parallel worker instrumentation

Hello, I had some questions about the behavior of some accounting in parallel EXPLAIN plans. Take the following plan: ``` Gather (cost=1000.43..750173.74 rows=2 width=235) (actual time=1665.122..1665.122 rows=0 loops=1) Workers Planned: 2 Workers Launched: 2 Buffers: shared hit=27683 read=

Re: Decomposing xml into table

Surafel Temesgen writes: > In PostgreSQL there are a function table_to_xml to map the table content > to xml value but there are no functionality to decompose xml back into > table Huh? XMLTABLE does that, and it's even SQL-standard. > I propose to have this by extending copy to handle xml for

Re: tag typos in "catalog.sgml"

Good catches, thanks Fabien. I will fix that tomorrow or so. And applied to HEAD. Ok. Should it be backpatched? I'm not sure what the usual practice is wrt to small fixes in the doc. -- Fabien.

Re: Decomposing xml into table

po 22. 6. 2020 v 20:49 odesílatel Surafel Temesgen napsal: > In PostgreSQL there are a function table_to_xml to map the table content > to xml value but there are no functionality to decompose xml back into > table which can be used in system that uses xml for transport only or there > are a need

Decomposing xml into table

In PostgreSQL there are a function table_to_xml to map the table content to xml value but there are no functionality to decompose xml back into table which can be used in system that uses xml for transport only or there are a need to migrate to database system to use database functionality. I prop

Re: Warn when parallel restoring a custom dump without data offsets

Adding Jim, since he ask about helping with perl. You can read the history of the patch here: https://commitfest.postgresql.org/28/2568/ https://www.postgresql.org/message-id/flat/CALBH9DDuJ+scZc4MEvw5uO-=vRyR2=QF9+Yh=3hpenkhwfs...@mail.gmail.com Some context: David is adding a test case for a

Re: Asymmetry in opening and closing indices for partition routing

Hi Ashutosh, On 2020-Jun-22, Ashutosh Bapat wrote: > I couldn't find code where this can happen but I don't see any code which > prevents this. This looks like a recipe for memory and reference leaks. > > We could fix this by > 1. Make ExecOpenIndices and ExecCloseIndices so that they can be cal

Re: Default setting for enable_hashagg_disk

On Mon, 2020-06-22 at 11:17 -0400, Robert Haas wrote: > I mean, that's fine, but I am trying to make a more general point > about priorities. Getting the GUCs right is a lot less important than > getting the feature right. What about the feature you are worried that we're getting wrong? Regards,

Re: Default setting for enable_hashagg_disk

On Mon, 2020-06-22 at 10:52 -0400, Robert Haas wrote: > So I feel like the really important thing here is to fix the cases > that don't come out well with default settings. ...with the caveat that perfection is not something to expect from our planner. > If we can't do that, > then the feature i

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

On 2020-06-19 21:57, Fujii Masao wrote: 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 functi

Re: Parallel Seq Scan vs kernel read ahead

Em seg., 22 de jun. de 2020 às 02:53, David Rowley escreveu: > On Mon, 22 Jun 2020 at 16:54, David Rowley wrote: > > I also tested this an AMD machine running Ubuntu 20.04 on kernel > > version 5.4.0-37. I used the same 100GB table I mentioned in [1], but > > with the query "select * from t whe

Re: Backpatch b61d161c14

On 2020-Jun-22, Amit Kapila wrote: > I propose to backpatch b61d161c14 [1] (Introduce vacuum errcontext to > display additional information.). In the recent past, we have seen an > error report similar to "ERROR: found xmin 2157740646 from before > relfrozenxid 1197" from multiple EDB customers.

Re: Online checksums patch - once again

On Mon, Jun 22, 2020 at 8:27 AM Daniel Gustafsson wrote: > Restartability is implemented by keeping state in pg_class. I opted for a > bool > which is cleared as the first step of checksum enable, since it offers fewer > synchronization cornercases I think. Unless you take AccessExclusiveLock o

Re: may I help with Perl?

> On Jun 22, 2020, at 9:09 AM, Jim Woodworth wrote: > > I have been programming Perl for over several years and would like to help if > needed. Will be looking through the issues for anything that jumps out at > me, but if there is something that someone is aware of that needs attention >

Re: Add support for INDEX_CLEANUP and TRUNCATE to vacuumdb

On 6/21/20, 9:36 PM, "Michael Paquier" wrote: > Okay. I have gone through the patch again, and applied it as of > 9550ea3. Thanks. Thanks! Nathan

Re: suggest to rename enable_incrementalsort

On Mon, Jun 22, 2020 at 11:22 AM Bruce Momjian wrote: > I think the big problem is that, without the extra underscore, it reads > as increment-alsort. ;-) I know you're joking, but I think there's a serious issue here. We often both omit word separators and also abbreviate, and I doubt that the

Re: suggest to rename enable_incrementalsort

Bruce Momjian writes: > On Mon, Jun 22, 2020 at 10:41:17AM -0400, Tom Lane wrote: >> Maybe I'm just used to the names, but I find that things like >> "enable_seqscan" and "enable_nestloop" are pretty readable. >> Once they get longer, though, not so much. So I agree with >> renaming enable_increm

may I help with Perl?

Hi All, I have been programming Perl for over several years and would like to help if needed. Will be looking through the issues for anything that jumps out at me, but if there is something that someone is aware of that needs attention please let me know. If I am going about this the wrong way p

Re: POC: GROUP BY optimization

On Sat, May 16, 2020 at 10:56 AM Tomas Vondra wrote: > The local effects are trivial - it's for example reordering the pathkeys > to make the explicit sort as cheap as possible. This thread already > discussed a number of things to base this on - ndistinct for columns, > cost of comparison functio

Re: Missing "Up" navigation link between parts and doc root?

On Sun, Jun 21, 2020 at 09:19:27AM +0200, Fabien COELHO wrote: > > Hello devs, > > I've been annoyed that the documentation navigation does not always has an > "Up" link. It has them inside parts, but the link disappears and you have to > go for the "Home" link which is far on the right when on t

Re: suggest to rename enable_incrementalsort

On Mon, Jun 22, 2020 at 10:41:17AM -0400, Tom Lane wrote: > Robert Haas writes: > > On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra > > wrote: > >> The reason why I kept the single-word variant is consistency with other > >> GUCs that affect planning, like enable_indexscan, enable_hashjoin and > >>

Assertion failure in pg_copy_logical_replication_slot()

Hi, If restart_lsn of logical replication slot gets behind more than max_slot_wal_keep_size from the current LSN, the logical replication slot would be invalidated and its restart_lsn is reset to an invalid LSN. If this logical replication slot with an invalid restart_lsn is specified as the sour

Re: Default setting for enable_hashagg_disk

On Mon, Jun 22, 2020 at 11:06 AM Justin Pryzby wrote: > This was addressed in 92c58fd94801dd5c81ee20e26c5bb71ad64552a8 > https://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items&diff=34994&oldid=34993 I mean, that's fine, but I am trying to make a more general point about priorities.

Re: suggest to rename enable_incrementalsort

On Mon, Jun 22, 2020 at 10:31 AM Tomas Vondra wrote: > OK, challenge accepted. $100 to the first person who commits a patch > with a variable NaMeS___LiKeTh_is. :-) Well, that was hyperbole, but people have proposed some pretty wacky schemes, and a few of those have ended up in the tree. For exa

Re: Global snapshots

On Sat, Jun 20, 2020 at 05:51:21PM +0530, Amit Kapila wrote: > I feel if Sawada-San or someone involved in another patch also once > studies this approach and try to come up with some form of comparison > then we might be able to make better decision. It is possible that > there are few good thing

Re: Default setting for enable_hashagg_disk

On Mon, Jun 22, 2020 at 10:52:37AM -0400, Robert Haas wrote: > On Wed, Jun 10, 2020 at 2:39 PM Jeff Davis wrote: > > The behavior in v13 master is, by default, analagous to Sort or > > anything else that adapts at runtime to spill. If we had spillable > > HashAgg the whole time, we wouldn't be wor

Re: Global snapshots

On Sat, Jun 20, 2020 at 05:54:18PM +0530, Amit Kapila wrote: > On Fri, Jun 19, 2020 at 6:33 PM Bruce Momjian wrote: > > > > 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

Re: Default setting for enable_hashagg_disk

On Wed, Jun 10, 2020 at 2:39 PM Jeff Davis wrote: > The behavior in v13 master is, by default, analagous to Sort or > anything else that adapts at runtime to spill. If we had spillable > HashAgg the whole time, we wouldn't be worried about #2 at all. But, > out of conservatism, I am trying to acco

Re: suggest to rename enable_incrementalsort

Robert Haas writes: > On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra > wrote: >> The reason why I kept the single-word variant is consistency with other >> GUCs that affect planning, like enable_indexscan, enable_hashjoin and >> many others. > Right, so that makes sense, but from a larger point of

Re: suggest to rename enable_incrementalsort

On Mon, Jun 22, 2020 at 10:16:54AM -0400, Robert Haas wrote: On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra wrote: The reason why I kept the single-word variant is consistency with other GUCs that affect planning, like enable_indexscan, enable_hashjoin and many others. Right, so that makes sens

Update InsertPgAttributeTuple comment to match new signature

The comment for InsertPgAttributeTuple no longer, since 911e702077037996, match reality as attoptions isn't always initialized to NULL. The attached removes mention of attoptions, and updates the list of always-NULL attributes to match what the code does (the git history didn't provide rationale f

Re: Parallel Seq Scan vs kernel read ahead

On Sun, Jun 21, 2020 at 6:52 PM David Rowley wrote: > Perhaps that's not a problem though, but then again, perhaps just > keeping it at 131072 regardless of RELSEG_SIZE and BLCKSZ is also ok. > The benchmarks I did on Windows [1] showed that the returns diminished > once we started making the step

Asymmetry in opening and closing indices for partition routing

Hi All, ExecInitPartitionInfo() has code 536 /* 537 * Open partition indices. The user may have asked to check for conflicts 538 * within this leaf partition and do "nothing" instead of throwing an 539 * error. Be prepared in that case by initializing the index information

Re: [PATCH] Initial progress reporting for COPY command

On Mon, Jun 22, 2020 at 03:33:00PM +0200, Josef Šimánek wrote: po 22. 6. 2020 v 14:14 odesílatel Tomas Vondra napsal: On Sun, Jun 21, 2020 at 01:40:34PM +0200, Josef Šimánek wrote: >Thanks for all comments. I have updated code to support more options >(including STDIN/STDOUT) and added some do

Re: suggest to rename enable_incrementalsort

On Sun, Jun 21, 2020 at 7:22 AM Tomas Vondra wrote: > The reason why I kept the single-word variant is consistency with other > GUCs that affect planning, like enable_indexscan, enable_hashjoin and > many others. Right, so that makes sense, but from a larger point of view, how much sense does it

Re: [PATCH] Initial progress reporting for COPY command

po 22. 6. 2020 v 14:14 odesílatel Tomas Vondra napsal: > On Sun, Jun 21, 2020 at 01:40:34PM +0200, Josef Šimánek wrote: > >Thanks for all comments. I have updated code to support more options > >(including STDIN/STDOUT) and added some documentation. > > > >Patch is attached and can be found also

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

On Mon, Jun 22, 2020 at 5:26 PM Amit Kapila wrote: > > On Mon, Jun 22, 2020 at 4:41 PM Dilip Kumar wrote: > > > > On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote: > > > > > > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote: > > > > > > > > Yes, I have made the changes. Basically, now I am

Re: min_safe_lsn column in pg_replication_slots view

On 2020/06/22 21:01, Amit Kapila wrote: On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier wrote: On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote: On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote: Isn't this information specific to checkpoints, so maybe better to

Re: Online checksums patch - once again

> On 23 Jan 2020, at 18:23, Robert Haas wrote: > ..That's probably easier and more efficient if it's just value > in pg_class than if they have to go poking around in another catalog. > So I am tentatively inclined to think that just putting it in pg_class > makes more sense. ..which is what I d

Re: [PATCH] Initial progress reporting for COPY command

On Sun, Jun 21, 2020 at 01:40:34PM +0200, Josef Šimánek wrote: Thanks for all comments. I have updated code to support more options (including STDIN/STDOUT) and added some documentation. Patch is attached and can be found also at https://github.com/simi/postgres/pull/5. Diff version: https://gi

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

On Wed, 17 Jun 2020 at 11:54, Andrey V. Lepikhov wrote: > On 6/15/20 10:26 AM, Ashutosh Bapat wrote: > > Thanks Andrey for the patch. I am glad that the patch has taken care > > of some corner cases already but there exist still more. > > > > COPY command constructed doesn't take care of dropped

Re: Backpatch b61d161c14

On Mon, Jun 22, 2020 at 10:35 AM Amit Kapila wrote: > > I propose to backpatch b61d161c14 [1] (Introduce vacuum errcontext to > display additional information.). In the recent past, we have seen an > error report similar to "ERROR: found xmin 2157740646 from before > relfrozenxid 1197" from multi

Re: min_safe_lsn column in pg_replication_slots view

On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier wrote: > > On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote: > > On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote: > >> Isn't this information specific to checkpoints, so maybe better to > >> display in view pg_stat_bgwrite

Re: suggest to rename enable_incrementalsort

On Mon, Jun 22, 2020 at 4:48 AM David Rowley wrote: > > On Sun, 21 Jun 2020 at 23:22, Tomas Vondra > wrote: > > > > On Sun, Jun 21, 2020 at 09:05:32AM +0200, Julien Rouhaud wrote: > > >On Sun, Jun 21, 2020 at 8:26 AM Peter Eisentraut > > > wrote: > > >> > > >> I suggest to rename enable_incremen

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

On Mon, Jun 22, 2020 at 4:41 PM Dilip Kumar wrote: > > On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote: > > > > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote: > > > > > > Yes, I have made the changes. Basically, now I am only using the > > > XLOG_XACT_INVALIDATIONS for generating all the

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

On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote: > > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote: > > > > Yes, I have made the changes. Basically, now I am only using the > > XLOG_XACT_INVALIDATIONS for generating all the invalidation messages. > > So whenever we are getting the new set

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

On Mon, Jun 22, 2020 at 4:26 PM Amit Kapila wrote: > > On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote: > > > > Yes, I have made the changes. Basically, now I am only using the > > XLOG_XACT_INVALIDATIONS for generating all the invalidation messages. > > So whenever we are getting the new set

Re: [PATCH] Initial progress reporting for COPY command

po 22. 6. 2020 v 9:15 odesílatel vignesh C napsal: > On Sun, Jun 21, 2020 at 5:11 PM Josef Šimánek > wrote: > > > > Thanks for all comments. I have updated code to support more options > (including STDIN/STDOUT) and added some documentation. > > > > Patch is attached and can be found also at > h

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

On Thu, Jun 18, 2020 at 9:02 PM Dilip Kumar wrote: > > Yes, I have made the changes. Basically, now I am only using the > XLOG_XACT_INVALIDATIONS for generating all the invalidation messages. > So whenever we are getting the new set of XLOG_XACT_INVALIDATIONS, we > are directly appending it to th

Re: [PATCH] Initial progress reporting for COPY command

po 22. 6. 2020 v 4:48 odesílatel Fujii Masao napsal: > > > On 2020/06/21 20:33, Josef Šimánek wrote: > > > > > > po 15. 6. 2020 v 6:39 odesílatel Fujii Masao < > masao.fu...@oss.nttdata.com > napsal: > > > > > > > > On 2020/06/14 21:32, Josef Šimánek wrote:

Re: [PATCH] Initial progress reporting for COPY command

On Sun, Jun 21, 2020 at 5:11 PM Josef Šimánek wrote: > > Thanks for all comments. I have updated code to support more options > (including STDIN/STDOUT) and added some documentation. > > Patch is attached and can be found also at > https://github.com/simi/postgres/pull/5. > > Diff version: https

  1   2   >