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

On Tue, Dec 1, 2020 at 11:38 AM Dilip Kumar wrote: > > On Mon, Nov 30, 2020 at 6:49 PM Amit Kapila wrote: > > > > On Mon, Nov 30, 2020 at 3:14 AM Noah Misch wrote: > > > > > > On Mon, Sep 07, 2020 at 12:00:41PM +0530, Amit Kapila wrote: > > > > Thanks, I have pushed the last patch. Let's wait

Re: Commitfest 2020-11 is closed

On Tue, Dec 01, 2020 at 01:05:54PM +0300, Anastasia Lubennikova wrote: > Commitfest 2020-11 is officially closed now. > Many thanks to everyone who participated by posting patches, reviewing them, > committing and sharing ideas in discussions! Thanks Anastasia and Georgios for working on that! --

Re: Two fsync related performance issues?

On Tue, Dec 01, 2020 at 07:39:30PM +0800, Craig Ringer wrote: > On Wed, 14 Oct 2020, 13:06 Michael Paquier, wrote: >> Yeah, it is safer to assume that it is the responsability of the >> backup tool to ensure that because it could be possible that a host is >> unplugged just after taking a backup,

Re: Allow some recovery parameters to be changed with reload

Hello > OK, so I pushed the patch. Thanks! Thank you! regards, Sergei

Re: [HACKERS] logical decoding of two-phase transactions

On Tue, Dec 1, 2020 at 6:26 PM Amit Kapila wrote: > > One idea could be that the subscriber skips the transaction if it sees > > the transaction is already prepared. > > > > To skip it, we need to send GID in begin message and then on > subscriber-side, check if the prepared xact already exists,

Re: Recent eelpout failures on 9.x branches

On Wed, Dec 2, 2020 at 12:07 PM Tom Lane wrote: > I'm also wondering a bit why the issue isn't affecting the newer > branches. It's certainly not because we made the test shorter ... I looked at htop while it was building the 9.x branches and saw pg_basebackup sitting in D state waiting for

Re: pg_stat_statements oddity with track = all

On 2020/12/02 15:32, Julien Rouhaud wrote: On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote: On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud wrote: Someone raised an interested point recently on pg_stat_kcache extension for handling nested statements, which also applies

Re: autovac issue with large number of tables

On 2020/12/02 12:53, Masahiko Sawada wrote: On Tue, Dec 1, 2020 at 5:31 PM Masahiko Sawada wrote: On Tue, Dec 1, 2020 at 4:32 PM Fujii Masao wrote: On 2020/12/01 16:23, Masahiko Sawada wrote: On Tue, Dec 1, 2020 at 1:48 PM Kasahara Tatsuhito wrote: Hi, On Mon, Nov 30, 2020 at

Re: pg_stat_statements oddity with track = all

On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote: > On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud wrote: > > > Someone raised an interested point recently on pg_stat_kcache extension for > > handling nested statements, which also applies to pg_stat_statements. > > > ... > > >

Re: pg_stat_statements oddity with track = all

On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud wrote: > Hi, > > Someone raised an interested point recently on pg_stat_kcache extension for > handling nested statements, which also applies to pg_stat_statements. > ... > The only idea I have for that is to add a new field to entry key, for >

Re: proposal: unescape_text function

st 2. 12. 2020 v 0:05 odesílatel Andrew Dunstan napsal: > > On 11/30/20 8:14 AM, Peter Eisentraut wrote: > > On 2020-11-29 18:36, Pavel Stehule wrote: > >> > >> I don't really get the point of this function. There is AFAICT no > >> function to produce this escaped format, and it's not a

Re: Add statistics to pg_stat_wal view for wal related parameter tuning

On 2020/12/01 14:01, Fujii Masao wrote: On 2020/11/26 16:07, Masahiro Ikeda wrote: On 2020-11-25 20:19, Fujii Masao wrote: On 2020/11/19 16:31, Masahiro Ikeda wrote: On 2020-11-17 11:46, Fujii Masao wrote: On 2020/11/16 16:35, Masahiro Ikeda wrote: On 2020-11-12 14:58, Fujii Masao

Re: Add table access method as an option to pgbench

Thanks a lot for the comments, Fabien. Some feedback about v3: In the doc I find TABLEACCESSMETHOD quite hard to read. Use TABLEAM instead? Yes, in this case, *TABLEAM* is easy to read, updated. Also, the next entry uses lowercase (tablespace), why change the style? The original style is

pg_stat_statements oddity with track = all

Hi, Someone raised an interested point recently on pg_stat_kcache extension for handling nested statements, which also applies to pg_stat_statements. The root issue is that when pg_stat_statements tracks nested statements, there's no way to really make sense of the counters, as top level

Re: Improving spin-lock implementation on ARM.

On Tue, 1 Dec 2020 at 22:19, Tom Lane wrote: > Alexander Korotkov writes: > > On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar > wrote: > >> I would request you guys to re-think it from this perspective to help > ensure that PGSQL can scale well on ARM. > >> s_lock becomes a top-most function and

Re: autovac issue with large number of tables

On Tue, Dec 1, 2020 at 5:31 PM Masahiko Sawada wrote: > > On Tue, Dec 1, 2020 at 4:32 PM Fujii Masao > wrote: > > > > > > > > On 2020/12/01 16:23, Masahiko Sawada wrote: > > > On Tue, Dec 1, 2020 at 1:48 PM Kasahara Tatsuhito > > > wrote: > > >> > > >> Hi, > > >> > > >> On Mon, Nov 30, 2020 at

Re: Recent eelpout failures on 9.x branches

On Tue, Dec 01, 2020 at 06:07:17PM -0500, Tom Lane wrote: > Thomas Munro writes: > > Unfortunately, eelpout got kicked off the nice shiny ARM server it was > > running on so last week I moved it to a rack mounted Raspberry Pi. It > > seems to be totally I/O starved causing some timeouts to be

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

On Tue, Dec 01, 2020 at 10:10:45AM +0100, Daniel Gustafsson wrote: > That sounds like it would work. Since the cryptohash implementation owns and > controls the void *data contents it can store whatever it needs to properly > free it. That seems to work properly. I have injected some

RE: Disable WAL logging to speed up data loading

From: Osumi, Takamichi/大墨 昂道 > I executed each wal_level three times and calculated the average time > and found that disabling WAL logging reduced about 73 % of the minimal's > loading speed > in this test. This speed-up came from the difference of generated WAL sizes. So, it's 4x speedup when

Re: room for improvement in amcheck btree checking?

> On Dec 1, 2020, at 4:38 PM, Peter Geoghegan wrote: > > On Tue, Dec 1, 2020 at 12:39 PM Mark Dilger > wrote: >> I found it surprising that even when precisely zero of the tids in the index >> exist in the table the index checks all come back clean. The heapallindexed >> check is

Re: Allow some recovery parameters to be changed with reload

On 2020/11/27 12:05, Kyotaro Horiguchi wrote: At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao wrote in On 2020/11/27 9:30, Kyotaro Horiguchi wrote: At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao wrote in On 2020/11/12 4:38, Sergei Kornilov wrote: Hello Anyway, for now I think

Re: [DOC] Document concurrent index builds waiting on each other

On Tue, Dec 1, 2020 at 6:51 PM Alvaro Herrera wrote: > > On 2020-Nov-30, James Coleman wrote: > > > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera > > wrote: > > > > > > On 2020-Sep-30, Michael Paquier wrote: > > > > Yeah, I think it might be more sensible to document this in > > >

Re: room for improvement in amcheck btree checking?

On Tue, Dec 1, 2020 at 12:39 PM Mark Dilger wrote: > I found it surprising that even when precisely zero of the tids in the index > exist in the table the index checks all come back clean. The heapallindexed > check is technically running as advertised, checking that all of the zero > tuples

Re: [DOC] Document concurrent index builds waiting on each other

On 2020-Nov-30, James Coleman wrote: > On Mon, Nov 30, 2020 at 4:53 PM Alvaro Herrera > wrote: > > > > On 2020-Sep-30, Michael Paquier wrote: > > Yeah, I think it might be more sensible to document this in > > maintenance.sgml, as part of the paragraph that discusses removing > > tuples "to

Re: room for improvement in amcheck btree checking?

On 2020-Dec-01, Mark Dilger wrote: > 7) Run a SQL query that uses an index scan on the table and see that it > errors with something like: > >ERROR: could not read block 0 in file "base/13097/16391": read only 0 of > 8192 bytes > > I found it surprising that even when precisely zero of

Re: Recent eelpout failures on 9.x branches

Thomas Munro writes: > Unfortunately, eelpout got kicked off the nice shiny ARM server it was > running on so last week I moved it to a rack mounted Raspberry Pi. It > seems to be totally I/O starved causing some timeouts to be reached, > and I'm looking into fixing that by adding fast storage.

Re: proposal: unescape_text function

On 11/30/20 8:14 AM, Peter Eisentraut wrote: > On 2020-11-29 18:36, Pavel Stehule wrote: >> >>     I don't really get the point of this function.  There is AFAICT no >>     function to produce this escaped format, and it's not a recognized >>     interchange format.  So under what circumstances

Re: Recent eelpout failures on 9.x branches

On Wed, Dec 2, 2020 at 11:36 AM Tom Lane wrote: > Perhaps this is just a question of the machine being too slow to complete > the test, in which case we ought to raise wal_sender_timeout. But it's > weird that it would've started to fail just now, because I don't really > see any changes in

Re: Setof RangeType returns

Patrick Handja writes: > In my case, I do not have a range as an argument, I am receiving 2 int, > which I am using to create a range. How can I initialize typcache in this > case? You should be passing down the pointer from the outer function, which does have it at hand, no?

Recent eelpout failures on 9.x branches

For about a week, eelpout has been failing the pg_basebackup test more often than not, but only in the 9.5 and 9.6 branches: https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=eelpout=REL9_6_STABLE https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=eelpout=REL9_5_STABLE The

Re: Setof RangeType returns

On 12/01/20 17:19, Patrick Handja wrote: > Just figured out. I think I can use RANGE_EMPTY and it will be like: > >> typcache =range_get_typcache(fcinfo, RangeTypeGetOid(RANGE_EMPTY)); Are you sure you are not simply looking for range_get_typcache(fcinfo, INT4RANGEOID) ? Top-posting is not

Re: error_severity of brin work item

On Tue, Dec 01, 2020 at 03:57:24PM -0300, Alvaro Herrera wrote: > On 2020-Dec-01, Justin Pryzby wrote: > > > This was an idea I made up - I don't know any of the details of this, but if > > you give a hint I could look at it more. There'd (still) be a race window, > > but > > I think that's ok.

Re: Setof RangeType returns

Just figured out. I think I can use RANGE_EMPTY and it will be like: > typcache =range_get_typcache(fcinfo, RangeTypeGetOid(RANGE_EMPTY)); Regards, *Andjasubu Bungama, Patrick * Le mar. 1 déc. 2020 à 16:42, Patrick Handja a écrit : > Thanks for the feedback Tom! > > > TypeCacheEntry

Re: Deleting older versions in unique indexes to avoid page splits

On Tue, Dec 1, 2020 at 1:50 AM Heikki Linnakangas wrote: > This is a wholly new concept with a lot of heuristics. It's a lot of > swallow. Thanks for taking a look! Yes, it's a little unorthodox. Ideally, you'd find time to grok the patch and help me codify the design in some general kind of

Re: Setof RangeType returns

Thanks for the feedback Tom! > TypeCacheEntry *typcache; > PG_RETURN_RANGE_P(range_serialize(typcache, , , false)); The use of typcache really confuses me. range_get_typcache() is used in order to initialize typcache > typcache =range_get_typcache(fcinfo, RangeTypeGetOid(r1)); In my case, I do

Re: Index Skip Scan (new UniqueKeys)

On 01/12/2020 22:21, Dmitry Dolgov wrote: On Mon, Nov 30, 2020 at 04:42:20PM +0200, Heikki Linnakangas wrote: I had a quick look at this patch. I haven't been following this thread, so sorry if I'm repeating old arguments, but here we go: Thanks! - I'm surprised you need a new index AM

room for improvement in amcheck btree checking?

Peter, While working on the pg_amcheck code for [1], I discovered an unexpected deficiency in the way btree indexes are checked. So far as I can tell from the docs [2], the deficiency does not violate any promises that amcheck is making, but I found it rather surprising all the same. To

Re: [sqlsmith] Failed assertion during partition pruning

I wrote: > What it looks like to me is that the code for setting up run-time > partition pruning has failed to consider the possibility of nested > partitioning: it's expecting that every partitioned table will have > at least one direct child that is a leaf. I'm not sure though > whether just

Re: Index Skip Scan (new UniqueKeys)

> On Mon, Nov 30, 2020 at 04:42:20PM +0200, Heikki Linnakangas wrote: > > I had a quick look at this patch. I haven't been following this thread, so > sorry if I'm repeating old arguments, but here we go: Thanks! > - I'm surprised you need a new index AM function (amskip) for this. Can't > you

Re: proposal: unescape_text function

út 1. 12. 2020 v 20:20 odesílatel Chapman Flack napsal: > >> po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule < > pavel.steh...@gmail.com> > >> napsal: > >>> I checked this and it is "prefix backslash-u hex" used by Java, > >>> JavaScript or RTF - > >>>

Re: PG vs LLVM 12 on seawasp, next round

Hi, On 2020-12-01 21:04:44 +0100, Fabien COELHO wrote: > Andres investigated a few days ago, managed to reproduce the issue locally, > and has one line patch. I'm unsure if it should be prevently back-patched, > though. I see no reason not to backpatch - it's more correct for past versions of

Re: PG vs LLVM 12 on seawasp, next round

Hello Thomas, Since seawasp's bleeding edge LLVM installation moved to "trunk 20201114 c8f4e06b 12.0.0" ~16 days ago, it has been red. Further updates didn't help it and it's now on "trunk 20201127 6ee22ca6 12.0.0". I wonder if there is something in Fabien's scripting that needs to be

Re: proposal: unescape_text function

>> po 30. 11. 2020 v 22:15 odesílatel Pavel Stehule >> napsal: >>> I checked this and it is "prefix backslash-u hex" used by Java, >>> JavaScript or RTF - >>> https://billposer.org/Software/ListOfRepresentations.html If I look on that page, it appears that RTF is using a similar-looking escape

Re: error_severity of brin work item

On 2020-Dec-01, Justin Pryzby wrote: > This was an idea I made up - I don't know any of the details of this, but if > you give a hint I could look at it more. There'd (still) be a race window, > but > I think that's ok. See CommitTransaction() and friends, where AtEOXact_on_commit_actions()

Re: error_severity of brin work item

On Tue, Dec 01, 2020 at 11:07:30AM -0300, Alvaro Herrera wrote: > > Should it be done in an AtCommit hook or something like that ? > > I didn't like this idea much on first read, on extensibility grounds, > but perhaps it's not so bad because we can generalize it whenever > there's pressure to

Off-Schedule Minor Release Consideration?

Hackers, Given that we have already heard about 3 separate minor release regressions in the most recent update I'm putting forth for discussion whether an off-schedule release should be done. I probably wouldn't care as much if it wasn't for the fact that the same release fixes two CVEs.

Re: Minor documentation error regarding streaming replication protocol

On Thu, 2020-10-08 at 23:17 -0400, Bruce Momjian wrote: > As I said before, it is more raw bytes, but > we > don't have an SQL data type for that. Sorry to jump in to this thread late. Can't we just set both "filename" and "content" to be BYTEA, but then set the format code to 1 (indicating

Re: Improving spin-lock implementation on ARM.

> On 01/12/2020, 16:59, "Alexander Korotkov" wrote: > On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar wrote: > > FWIW, here is an earlier discussion on the same (also added the >> proposal author here) : Thanks for looping me in! >> >> >

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 7:57 PM Zidenberg, Tsahi wrote: > > On 01/12/2020, 16:59, "Alexander Korotkov" wrote: > > On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar > > wrote: > > > FWIW, here is an earlier discussion on the same (also added the > >> proposal author here) : > > Thanks for

Re: Improving spin-lock implementation on ARM.

Alexander Korotkov writes: > On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar wrote: >> I would request you guys to re-think it from this perspective to help ensure >> that PGSQL can scale well on ARM. >> s_lock becomes a top-most function and LSE is not a universal solution but >> CAS surely

Re: Confusing behavior of psql's \e

On 12/01/20 11:21, Laurenz Albe wrote: > On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote: >>> complain about it, so I propose to clear the query buffer if the >>> editor exits without modifying the file. >> >> Or how about keeping the query buffer content unchanged, but not >> executing it?

Re: Add session statistics to pg_stat_database

On Fri, Nov 20, 2020 at 3:41 PM Laurenz Albe wrote: > On Tue, 2020-11-17 at 17:33 +0100, Magnus Hagander wrote: > > I've taken a look as well, and here are a few short notes: > > Much appreciated! > Sorry about the delay in getting back to you on this one. FYI, while the patch has been bumped

Re: Confusing behavior of psql's \e

On Tue, 2020-12-01 at 11:03 -0500, Chapman Flack wrote: > On 11/30/20 22:38, Laurenz Albe wrote: > > I have been annoyed about this myself, and I have heard other prople > > complain about it, so I propose to clear the query buffer if the > > editor exits without modifying the file. > > Or how

Re: Avoid using lcons and list_delete_first in plan_union_children()

On 01/12/2020 12:52, Hou, Zhijie wrote: Hi, In function plan_union_children(), I found the lcons and list_delete_first here is easy to be replaced by lappend and list_delete_last. And I also found a previous commit do similar thing, so I try to improve this one. Previous commit:

Re: Phrase search vs. multi-lexeme tokens

On Thu, Nov 12, 2020 at 4:09 PM Alexander Korotkov wrote: > This issue looks like the much more complex design bug in phrase > search. Fixing this would require some kind of readahead or multipass > processing, because we don't know how to process 'pg_class' in > advance. > > Is this really a

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 6:19 PM Krunal Bauskar wrote: > I would request you guys to re-think it from this perspective to help ensure > that PGSQL can scale well on ARM. > s_lock becomes a top-most function and LSE is not a universal solution but > CAS surely helps ease the main bottleneck. CAS

Re: Confusing behavior of psql's \e

On 11/30/20 22:38, Laurenz Albe wrote: > I have been annoyed about this myself, and I have heard other prople > complain about it, so I propose to clear the query buffer if the > editor exits without modifying the file. Or how about keeping the query buffer content unchanged, but not executing

Re: [HACKERS] Custom compression methods

On Tue, Dec 1, 2020 at 4:50 PM Dilip Kumar wrote: > > On Sat, Nov 21, 2020 at 3:50 AM Robert Haas wrote: > > While working on this comment I have doubts. > > > I wonder in passing about TOAST tables and materialized views, which > > are the other things that have storage. What gets stored for >

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Hi Justin, Thanks for all the comments. I'll incorporate everything and submit an updated version later. On 2020-Nov-30, Justin Pryzby wrote: > On Tue, Nov 03, 2020 at 08:56:06PM -0300, Alvaro Herrera wrote: > > +++ b/src/bin/psql/describe.c > > - printfPQExpBuffer(,

Re: BUG #15383: Join Filter cost estimation problem in 10.5

On 30.10.2020 19:33, David G. Johnston wrote: On Fri, Oct 30, 2020 at 9:16 AM Anastasia Lubennikova mailto:lubennikov...@gmail.com>> wrote: Status update for a commitfest entry. It looks like there was no real progress on this issue since April. I see only an experimental patch.

Re: Improving spin-lock implementation on ARM.

On Tue, 1 Dec 2020 at 20:25, Alexander Korotkov wrote: > On Tue, Dec 1, 2020 at 3:44 PM Krunal Bauskar > wrote: > > I have completed benchmarking with lse. > > > > Graph attached. > > Thank you for benchmarking. > > Now I agree with this comment by Tom Lane > > > In general, I'm pretty

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

On 09.11.2020 19:31, Stephen Frost wrote: Greetings, * Dmitry Shulga (d.shu...@postgrespro.ru) wrote: On 19 Oct 2020, at 23:25, Stephen Frost wrote: process finishes a WAL file but then just sit around doing nothing while waiting for the applying process to finish another segment. I believe

Re: Strange behavior with polygon and NaN

Anastasia Lubennikova writes: > The commitfest is closed now and this entry is "Waiting on author". > As far as I see, part of the fixes is already committed. Is there > anything left to work on or this patch needs review/ ready for committer > now? I think it should be "needs review" now.

Re: runtime error copying oids field

On 2020-Dec-01, Alvaro Herrera wrote: > On 2020-Nov-30, Zhihong Yu wrote: > > > Alvaro, et al: > > Please let me know how to proceed with the patch. > > > > Running test suite with the patch showed no regression. > > That's good to hear. I'll get it pushed today. Thanks for following > up.

Re: Corruption during WAL replay

On 06.11.2020 14:40, Masahiko Sawada wrote: So I agree to proceed with the patch that adds a critical section independent of fixing other related things discussed in this thread. If Teja seems not to work on this I’ll write the patch. Regards, -- Masahiko Sawada EnterpriseDB:

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar wrote: > On Tue, 1 Dec 2020 at 15:33, Krunal Bauskar wrote: > > What I meant was outline-atomics support was added in GCC-9.4 and was made > > default in gcc-10. > > LSE support is present for quite some time. > > FWIW, here is an earlier discussion

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 3:44 PM Krunal Bauskar wrote: > I have completed benchmarking with lse. > > Graph attached. Thank you for benchmarking. Now I agree with this comment by Tom Lane > In general, I'm pretty skeptical of *all* the results posted so far on > this thread, because everybody

Re: Corner-case bug in pg_rewind

> > Status update for a commitfest entry. > > The patch is Waiting on Author for some time. As this is a bug fix, I am > moving it to the next CF. > Ian, are you planning to continue working on it? > As a reviewer, I consider the patch useful and good overall. The comments I left were purely

Re: [PATCH] SET search_path += octopus

At 2020-10-28 18:29:30 -0700, and...@anarazel.de wrote: > > I think my gut feeling about this still is that it's not worth > implementing something that doesn't work in postgresql.conf. The > likelihood of ending up with something that makes it hard to to > eventually implement proper

Re: Corner-case bug in pg_rewind

On 16.11.2020 05:49, Ian Lawrence Barwick wrote: Note that the patch may require reworking for HEAD due to changes in commit 9c4f5192f6. I'll try to take another look this week. Regards Ian Barwick -- EnterpriseDB: https://www.enterprisedb.com Status update for a commitfest entry.

Re: Unnecessary delay in streaming replication due to replay lag

On 20.11.2020 11:21, Michael Paquier wrote: On Tue, Sep 15, 2020 at 05:30:22PM +0800, lchch1...@sina.cn wrote: I read the code and test the patch, it run well on my side, and I have several issues on the patch. + RequestXLogStreaming(ThisTimeLineID, +

Re: error_severity of brin work item

On 2020-Nov-30, Justin Pryzby wrote: > On Mon, Nov 30, 2020 at 08:47:32PM -0300, Alvaro Herrera wrote: > > The more I look at this, the less I like it. This would set a precedent > > that any action that can be initiated from an autovac work-item has a > > requirement of silently being discarded

Re: Strange behavior with polygon and NaN

On 25.11.2020 11:14, Kyotaro Horiguchi wrote: At Wed, 25 Nov 2020 11:39:39 +0900 (JST), Kyotaro Horiguchi wrote in So that line of thought prompts me to tread *very* carefully when trying to dodge NaN results. We need to be certain that we introduce only logically-defensible special cases.

RE: Disable WAL logging to speed up data loading

Hi Sorry for being late. On Tuesday, December 1, 2020 10:42 AM Tsunakawa, Takayuki wrote: > From: Kyotaro Horiguchi > > Yeah, although it's enough only to restrict non-harmful records > > practically, if we find that only a few kinds of records are needed, > > maybe it's cleaner to allow

Re: Terminate the idle sessions

On 25.11.2020 05:18, Li Japin wrote: On Nov 24, 2020, at 11:20 PM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Mon, Nov 23, 2020 at 11:22 PM Li Japin > wrote: How about use “foreign-data wrapper” replace “postgres_fdw”? I don't see

Re: Error on failed COMMIT

Hi, this patch fails on the cfbot yet it has received an update during the current CF. I will move it to the next CF and mark it there as Waiting on Author. Cheers, Georgios The new status of this patch is: Needs review

Re: Consider parallel for lateral subqueries with limit

On Mon, Nov 30, 2020 at 7:00 PM James Coleman wrote: > > I've been investigating parallelizing certain correlated subqueries, > and during that work stumbled across the fact that > set_rel_consider_parallel disallows parallel query on what seems like > a fairly simple case. > > Consider this

Re: Cost overestimation of foreign JOIN

On Mon, Nov 30, 2020 at 11:56 PM Andrey Lepikhov wrote: > > On 30.11.2020 22:38, Tom Lane wrote: > > Andrey Lepikhov writes: > >> Maybe it is needed to swap lines 2908 and 2909 (see attachment)? > > > > No; as explained in the comment immediately above here, we're assuming > > that the join

Re: Notes on physical replica failover with logical publisher or subscriber

On Mon, Nov 30, 2020 at 9:30 AM Craig Ringer wrote: > > Hi all > > I recently wrote some notes on interaction between physical > replication failover/promotion and logical replication publisher > and/or standby. > > As you probably all know, right now we don't support physical failover > for

Re: Display individual query in pg_stat_activity

This patch fails in the cfbot for quite some time now. I shall close it as Return With Feedback and not move it to the next CF. Please feel free to register an updated version afresh for the next CF. Cheers, //Georgios

Re: runtime error copying oids field

On 2020-Nov-30, Zhihong Yu wrote: > Alvaro, et al: > Please let me know how to proceed with the patch. > > Running test suite with the patch showed no regression. That's good to hear. I'll get it pushed today. Thanks for following up.

Re: Additional improvements to extended statistics

On 12/1/20 9:15 AM, Dean Rasheed wrote: > On Sun, 29 Nov 2020 at 21:02, Tomas Vondra > wrote: >> >> Those are fairly minor issues. I don't have any deeper objections, and >> it seems committable. Do you plan to do that sometime soon? >> > > OK, I've updated the patch status in the CF app, and I

Re: Improving spin-lock implementation on ARM.

On Tue, 1 Dec 2020 at 02:16, Alexander Korotkov wrote: > On Mon, Nov 30, 2020 at 9:21 PM Tom Lane wrote: > > Alexander Korotkov writes: > > > I tend to think that LSE is enabled by default in Apple's clang based > > > on your previous message[1]. In order to dispel the doubts could you > > >

Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW

Hi, I think we can pass CURSOR_OPT_PARALLEL_OK to pg_plan_query() for refresh mat view so that parallelism can be considered for the SELECT part of the previously created mat view. The refresh mat view queries can be faster in cases where SELECT is parallelized. Attaching a small patch.

Re: Two fsync related performance issues?

On Wed, 14 Oct 2020, 13:06 Michael Paquier, wrote: > On Wed, Oct 14, 2020 at 02:48:18PM +1300, Thomas Munro wrote: > > On Wed, Oct 14, 2020 at 12:53 AM Michael Banck > > wrote: > >> One question about this: Did you consider the case of a basebackup being > >> copied/restored somewhere and the

Re: [HACKERS] Custom compression methods

On Sat, Nov 21, 2020 at 3:50 AM Robert Haas wrote: While working on this comment I have doubts. > I wonder in passing about TOAST tables and materialized views, which > are the other things that have storage. What gets stored for > attcompression? For a TOAST table it probably doesn't matter

Avoid using lcons and list_delete_first in plan_union_children()

Hi, In function plan_union_children(), I found the lcons and list_delete_first here is easy to be replaced by lappend and list_delete_last. And I also found a previous commit do similar thing, so I try to improve this one. Previous commit: d97b714a219959a50f9e7b37ded674f5132f93f3 Best

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

On Tue, Dec 1, 2020 at 11:38 AM Dilip Kumar wrote: > > On Mon, Nov 30, 2020 at 6:49 PM Amit Kapila wrote: > > > > > > What is going on here is that the expected streaming file is missing. > > Normally, the first time we send a stream of changes (some percentage > > of transaction changes) we

Re: Improving spin-lock implementation on ARM.

On Tue, 1 Dec 2020 at 15:33, Krunal Bauskar wrote: > What I meant was outline-atomics support was added in GCC-9.4 and was made > default in gcc-10. > LSE support is present for quite some time. FWIW, here is an earlier discussion on the same (also added the proposal author here) :

Commitfest 2020-11 is closed

Hi, hackers! Commitfest 2020-11 is officially closed now. Many thanks to everyone who participated by posting patches, reviewing them, committing and sharing ideas in discussions! Today, me and Georgios will move the remaining items to the next CF or return them with feedback. We're planning

Re: Improving spin-lock implementation on ARM.

On Tue, 1 Dec 2020 at 15:16, Alexander Korotkov wrote: > On Tue, Dec 1, 2020 at 6:26 AM Krunal Bauskar > wrote: > > On Tue, 1 Dec 2020 at 02:31, Alexander Korotkov > wrote: > >> BTW, how do you get that required gcc version is 9.4? I've managed to > >> use LSE with gcc 9.3. > > > > Did they

Re: Deleting older versions in unique indexes to avoid page splits

This is a wholly new concept with a lot of heuristics. It's a lot of swallow. But here are a few quick comments after a first read-through: On 30/11/2020 21:50, Peter Geoghegan wrote: +/* + * State used when calling table_index_delete_check() to perform "bottom up" + * deletion of duplicate

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 9:01 AM Tom Lane wrote: > I did what I could in this department. It's late and I'm not going to > have time to run read/write benchmarks before bed, but here are some > results for the "pgbench -S" cases. I tried to match your testing > choices, but could not entirely: >

Re: Improving spin-lock implementation on ARM.

On Tue, Dec 1, 2020 at 6:26 AM Krunal Bauskar wrote: > On Tue, 1 Dec 2020 at 02:31, Alexander Korotkov wrote: >> BTW, how do you get that required gcc version is 9.4? I've managed to >> use LSE with gcc 9.3. > > Did they backported it to 9.3? > I am just looking at the gcc guide. >

Re: [HACKERS] Custom compression methods

On Wed, Nov 25, 2020 at 12:50 AM Alvaro Herrera wrote: > > On 2020-Nov-24, Tom Lane wrote: > > > Robert Haas writes: > > > > Oh, I thought it had been suggested in previous discussions that these > > > should be treated as access methods rather than inventing a whole new > > > concept just for

Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2

> On 1 Dec 2020, at 06:38, Michael Paquier wrote: > > On Mon, Nov 30, 2020 at 02:29:29PM +0100, Daniel Gustafsson wrote: >> Yeah, that's along the lines of what I was thinking of. > > Hmm. I have looked at that, and thought first about having directly a > reference to the resowner directly in

Re: enable_incremental_sort changes query behavior

On 01.12.2020 03:08, James Coleman wrote: On Tue, Nov 3, 2020 at 4:39 PM Tomas Vondra wrote: I've pushed the 0001 part, i.e. the main fix. Not sure about the other parts (comments and moving the code back to postgres_fdw) yet. I noticed the CF entry [1] got moved to the next CF; I'm thinking

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

On Tue, Dec 1, 2020 at 2:40 PM tsunakawa.ta...@fujitsu.com wrote: > From: Amit Langote > > Andrey's original patch had the flag to, as I understand it, make the > > partitioning case work correctly. When inserting into a > > non-partitioned table, there's only one relation to care about. In >

Re: [PATCH] Runtime control of CLOBBER_CACHE_ALWAYS

On Mon, 30 Nov 2020, 20:38 Anastasia Lubennikova, < a.lubennik...@postgrespro.ru> wrote: > On 27.10.2020 11:34, Peter Eisentraut wrote: > > On 2020-09-25 09:40, Craig Ringer wrote: > >> While working on extensions I've often wanted to enable cache > >> clobbering for a targeted piece of code,

Re: Printing backtrace of postgres processes

On Tue, Dec 1, 2020 at 9:31 AM Tom Lane wrote: > > Andres Freund writes: > > It should be quite doable to emit such backtraces directly to stderr, > > instead of using appendStringInfoString()/elog(). > > No, please no. > > (1) On lots of logging setups (think syslog), anything that goes to >

  1   2   >