Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On Tue, Apr 21, 2020 at 02:27:20PM +0900, Fujii Masao wrote: > On 2020/04/21 10:59, Michael Paquier wrote: >> With your patch, this code >> now means that in order to finish recovery you need to send SIGUSR2 to >> the startup process *and* to create the promote signal file. > > Yes, but isn't

pgbench testing with contention scenarios

Subject changed. Earlier it was : spin_delay() for ARM On Fri, 17 Apr 2020 at 22:54, Robert Haas wrote: > > On Thu, Apr 16, 2020 at 3:18 AM Amit Khandekar wrote: > > Not relevant to the PAUSE stuff Note that when the parallel > > clients reach from 24 to 32 (which equals the machine CPUs),

Re: design for parallel backup

Hi, On 2020-04-21 10:20:01 +0530, Amit Kapila wrote: > It is quite likely that compression can benefit more from parallelism > as compared to the network I/O as that is mostly a CPU intensive > operation but I am not sure if we can just ignore the benefit of > utilizing the network bandwidth. In

Re: WIP: WAL prefetch (another approach)

On Sun, Apr 19, 2020 at 11:46 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > Thanks for working on this patch, it seems like a great feature. I'm > probably a bit late to the party, but still want to make couple of > commentaries. Hi Dmitry, Thanks for your feedback and your interest in this

Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On 2020/04/21 10:59, Michael Paquier wrote: On Mon, Apr 20, 2020 at 03:26:16PM +0900, Fujii Masao wrote: Patch attached. I will add this into the first CF for v14. Thanks! -if (IsPromoteSignaled()) +/* + * In 9.1 and 9.2 the postmaster unlinked the promote file inside the +

Re: Parallel Append can break run-time partition pruning

Hi David, On Tue, Apr 21, 2020 at 12:03 PM David Rowley wrote: > On Fri, 17 Apr 2020 at 19:08, Amit Langote wrote: > > On Wed, Apr 15, 2020 at 4:18 PM David Rowley wrote: > > > I'm a bit divided on what the correct fix is. If I blame Parallel > > > Append for not trying hard enough to pull up

Re: It is not documented that pg_promote can exit standby mode

On 2020/04/20 20:38, Fujii Masao wrote: On 2020/04/18 2:46, Tom Lane wrote: Fujii Masao writes: Thanks for the report and the patch! It looks good to me. Barring any objection, I will commit this patch. It might be worth writing "pg_promote() is called" (adding parentheses) to make it

Re: Fix for pg_statio_all_tables

Michael Paquier writes: > On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote: >> As a bugfix, I think this should be backpatched. But this patch >> requires catalog change. Were similar cases there before? If so, >> how did we resolve them? > A backpatch can happen in such

Re: Do we need to handle orphaned prepared transactions in the server?

On Mon, Apr 20, 2020 at 10:35:15PM -0400, Bruce Momjian wrote: > On Thu, Apr 16, 2020 at 03:11:51PM -0400, Tom Lane wrote: >> If we were going to go down the path of periodically logging warnings >> about old prepared transactions, some single-instance background task >> like the checkpointer

Re: design for parallel backup

On Tue, Apr 21, 2020 at 2:40 AM Andres Freund wrote: > > On 2020-04-20 16:36:16 -0400, Robert Haas wrote: > > > If a backup client - either current or hypothetical - is compressing > > and encrypting, then it doesn't have either a filesystem I/O or a > > network I/O in progress while it's doing

Bogus documentation for bogus geometric operators

While revising the docs for the geometric operators, I came across these entries: <^ Is below (allows touching)? circle '((0,0),1)' <^ circle '((0,5),1)' >^ Is above (allows touching)? circle '((0,5),1)' >^ circle '((0,0),1)' These have got more than a few problems: 1. There

Re: WIP/PoC for parallel backup

On Tue, Apr 14, 2020 at 8:07 PM Asif Rehman wrote: > > I forgot to make a check for no-manifest. Fixed. Attached is the updated > patch. > > Have we done any performance testing with this patch to see the benefits? If so, can you point me to the results? If not, then can we perform some tests on

Re: spin_delay() for ARM

On Sat, 18 Apr 2020 at 03:30, Thomas Munro wrote: > > On Sat, Apr 18, 2020 at 2:00 AM Ants Aasma wrote: > > On Thu, 16 Apr 2020 at 10:33, Pavel Stehule wrote: > > > what I know, pgbench cannot be used for testing spinlocks problems. > > > > > > Maybe you can see this issue when a) use higher

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 11:31 PM Robert Haas wrote: > > On Mon, Apr 20, 2020 at 12:10 AM Dilip Kumar wrote: > > I have started reviewing these patches. I think, the fixes looks right to > > me. > > > > + LWLockAcquire(OldSnapshotTimeMapLock, LW_SHARED); > > + mapping->head_offset =

Re: Parallel Append can break run-time partition pruning

On Fri, 17 Apr 2020 at 19:08, Amit Langote wrote: > > On Wed, Apr 15, 2020 at 4:18 PM David Rowley wrote: > > I'm a bit divided on what the correct fix is. If I blame Parallel > > Append for not trying hard enough to pull up the lower Append in > > accumulate_append_subpath(), then clearly the

Re: Do we need to handle orphaned prepared transactions in the server?

On Thu, Apr 16, 2020 at 03:11:51PM -0400, Tom Lane wrote: > If we were going to go down the path of periodically logging warnings > about old prepared transactions, some single-instance background task > like the checkpointer would be a better place to do the work in. But > I'm not really

Re: 001_rep_changes.pl stalls

On Mon, Apr 20, 2020 at 07:24:28PM +0900, Fujii Masao wrote: > I was misreading this as something like "any other blocking than > the blocking in WalSndLoop()". Ok, I have no more comments on > the patch. Patch looks rather sane to me at quick glance. I can see that WAL senders are now not stuck

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 8:02 PM Dilip Kumar wrote: > On Mon, Apr 20, 2020 at 12:29 PM Thomas Munro wrote: > > I mean I want to verify that VACUUM or heap prune actually removed a > > tuple that was visible to an old snapshot. An idea I just had: maybe > > sto_using_select.spec should check the

Re: Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On Mon, Apr 20, 2020 at 03:26:16PM +0900, Fujii Masao wrote: > Patch attached. I will add this into the first CF for v14. Thanks! > -if (IsPromoteSignaled()) > +/* > + * In 9.1 and 9.2 the postmaster unlinked the promote file inside the > + * signal handler. It now leaves the

Re: Adding missing object access hook invocations

On Mon, Apr 20, 2020 at 01:32:31PM -0400, Alvaro Herrera wrote: > I think it's fine to put this in at this time. It's not a new feature. > The only thing this needs is to go through a new release cycle so that > people can adjust to the new hook invocations as necessary. Okay. Any other

Re: Fix for pg_statio_all_tables

On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote: > Among all the joined tables, only "pg_index I" is expected to have > multiple rows associated with single relation. But we do sum() for > toast index "pg_index X" as well. As the result, we multiply > statistics for toast

Binary search in ScalarArrayOpExpr for OR'd constant arrays

Over in "execExprInterp() questions / How to improve scalar array op expr eval?" [1] I'd mused about how we might be able to optimized scalar array ops with OR'd semantics. This patch implements a binary search for such expressions when the array argument is a constant so that we can avoid

Fix for pg_statio_all_tables

Hi! It appears that definition of pg_statio_all_tables has bug. CREATE VIEW pg_statio_all_tables AS SELECT C.oid AS relid, N.nspname AS schemaname, C.relname AS relname, pg_stat_get_blocks_fetched(C.oid) -

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

> + deleteDependencyRecordsFor(TriggerRelationId, > + pg_trigger->oid, > + false); > + deleteDependencyRecordsFor(RelationRelationId, > +

Re: Poll: are people okay with function/operator table redesign?

On 2020-Apr-20, Tom Lane wrote: > Alvaro Herrera writes: > > There's one with a separate column for the operator, without types, at > > the left (the "with names" example at > > https://postgr.es/m/14380.1587242...@sss.pgh.pa.us ). That seemed > > pretty promising -- not sure why it was

Re: Poll: are people okay with function/operator table redesign?

Alvaro Herrera writes: > There's one with a separate column for the operator, without types, at > the left (the "with names" example at > https://postgr.es/m/14380.1587242...@sss.pgh.pa.us ). That seemed > pretty promising -- not sure why it was discarded. Well, I wouldn't say it was discarded

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 1:40 PM Robert Haas wrote: > On Mon, Apr 20, 2020 at 4:30 PM Andres Freund wrote: > > A few billion CLogTruncationLock acquisitions in short order will likely > > have at least as big an impact as ShareUpdateExclusiveLock held for the > > duration of the check. That's not

Re: Poll: are people okay with function/operator table redesign?

On 2020-Apr-20, Tom Lane wrote: > Victor Yegorov writes: > > While table 9.5 with functions looks quite nice, I quite dislike 9.4 with > > operators. > > Previously, I could lookup operator in the leftmost column and read on. > > Right now I have to look through the whole table (well, not

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 12:40 PM Mark Dilger wrote: > Ok, I'll work in that direction and repost when I have something along those > lines. Great, thanks! It also occurs to me that the B-Tree checks that amcheck already has have one remaining blindspot: While the heapallindexed verification

Re: design for parallel backup

Hi, On 2020-04-20 16:36:16 -0400, Robert Haas wrote: > My suspicion is that it has mostly to do with adequately utilizing the > hardware resources on the server side. If you are network-constrained, > adding more connections won't help, unless there's something shaping > the traffic which can be

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 4:30 PM Andres Freund wrote: > A few billion CLogTruncationLock acquisitions in short order will likely > have at least as big an impact as ShareUpdateExclusiveLock held for the > duration of the check. That's not really a relevant concern or > txid_status(). Per-tuple

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 12:42 PM Andres Freund wrote: > This is something we really really really need. I'm very excited to see > progress! +1 My experience with amcheck was that the requirement that we document and verify pretty much every invariant (the details of which differ slightly based

Re: design for parallel backup

On Mon, Apr 20, 2020 at 4:19 PM Andres Freund wrote: > Why do we want parallelism here. Or to be more precise: What do we hope > to accelerate by making what part of creating a base backup > parallel. There's several potential bottlenecks, and I think it's > important to know the design

Re: new heapcheck contrib module

Hi, On 2020-04-20 15:59:49 -0400, Robert Haas wrote: > On Mon, Apr 20, 2020 at 3:42 PM Andres Freund wrote: > > I don't think random interspersed uses of CLogTruncationLock are a good > > idea. If you move to only checking visibility after tuple fits into > > [relfrozenxid, nextXid), then you

Re: design for parallel backup

Thanks for your thoughts. On Mon, Apr 20, 2020 at 4:02 PM Peter Eisentraut wrote: > That would clearly be a good goal. Non-parallel backup should ideally > be parallel backup with one worker. Right. > But it doesn't follow that the proposed design is wrong. It might just > be that the design

Re: design for parallel backup

Hi, On 2020-04-15 11:57:29 -0400, Robert Haas wrote: > Over at > http://postgr.es/m/CADM=JehKgobEknb+_nab9179HzGj=9eitzwmod2mpqr_rif...@mail.gmail.com > there's a proposal for a parallel backup patch which works in the way > that I have always thought parallel backup would work: instead of >

Re: new heapcheck contrib module

[ retrying from the email address I intended to use ] On Mon, Apr 20, 2020 at 3:42 PM Andres Freund wrote: > I don't think random interspersed uses of CLogTruncationLock are a good > idea. If you move to only checking visibility after tuple fits into > [relfrozenxid, nextXid), then you don't

Re: design for parallel backup

On 2020-04-15 17:57, Robert Haas wrote: Over at http://postgr.es/m/CADM=JehKgobEknb+_nab9179HzGj=9eitzwmod2mpqr_rif...@mail.gmail.com there's a proposal for a parallel backup patch which works in the way that I have always thought parallel backup would work: instead of having a monolithic

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On Mon, Apr 20, 2020 at 06:35:44PM +0900, Amit Langote wrote: > On Mon, Apr 20, 2020 at 5:49 AM Justin Pryzby wrote: > > On Sun, Apr 19, 2020 at 03:13:29PM -0400, Alvaro Herrera wrote: > > > What happens if you detach the parent? I mean, should the trigger > > > removal recurse to children? > >

Re: new heapcheck contrib module

Hi, On 2020-04-20 10:59:28 -0700, Mark Dilger wrote: > I have been talking with Robert about table corruption that occurs > from time to time. The page checksum feature seems sufficient to > detect most random corruption problems, but it can't detect "logical" > corruption, where the page is

Re: new heapcheck contrib module

> On Apr 20, 2020, at 12:37 PM, Peter Geoghegan wrote: > > I mean an interface that's friendly to DBAs, that verifies an entire > database. No custom sql query required. Something that provides a reasonable > mix of verification options based on high level directives. All verification >

Re: new heapcheck contrib module

I mean an interface that's friendly to DBAs, that verifies an entire database. No custom sql query required. Something that provides a reasonable mix of verification options based on high level directives. All verification methods can be combined in a granular, possibly randomized fashion. Maybe

Re: relocating the server's backup manifest code

On Sat, Apr 18, 2020 at 8:12 PM Michael Paquier wrote: > I would suggest to > still use BackupManifest instead of Manifest in those functions and > structures though, ... Done in the attached, which also adds "backup_" to the type names. After further examination, I think the Copyright header

Re: new heapcheck contrib module

> On Apr 20, 2020, at 11:31 AM, Peter Geoghegan wrote: > > IMV, the problem that we have with amcheck is that it's too hard to > use in a top down kind of way. Perhaps there is an opportunity to > provide a more top-down interface to an expanded version of amcheck > that does heap checking.

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 11:19 AM Robert Haas wrote: > I wondered if people would suggest that. Didn't take long. You were the one that pointed out that my first version of contrib/amcheck, which was called "contrib/btreecheck", should have a more general name. And rightly so! The basic

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 2:09 PM Peter Geoghegan wrote: > Cool. Why not make it part of contrib/amcheck? I wondered if people would suggest that. Didn't take long. The documentation would need some updating, but that's doable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: new heapcheck contrib module

On Mon, Apr 20, 2020 at 10:59 AM Mark Dilger wrote: > The attached module provides the means to scan a relation and sanity check > it. Currently, it checks xmin and xmax values against relfrozenxid and > relminmxid, and also validates TOAST pointers. If people like this, it could > be expanded

Re: design for parallel backup

On Mon, Apr 20, 2020 at 8:50 AM Amit Kapila wrote: > It is not apparent how you are envisioning this division on the > server-side. I think in the currently proposed patch, each worker on > the client-side requests the specific files. So, how are workers going > to request such numbered files

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 12:10 AM Dilip Kumar wrote: > I have started reviewing these patches. I think, the fixes looks right to me. > > + LWLockAcquire(OldSnapshotTimeMapLock, LW_SHARED); > + mapping->head_offset = oldSnapshotControl->head_offset; > + mapping->head_timestamp =

new heapcheck contrib module

Hackers, I have been talking with Robert about table corruption that occurs from time to time. The page checksum feature seems sufficient to detect most random corruption problems, but it can't detect "logical" corruption, where the page is valid but inconsistent with the rest of the database

Re: more ALTER .. DEPENDS ON EXTENSION fixes

On 2020-Mar-06, Ibrar Ahmed wrote: > I think we need a tab-completion patch too for this. Thanks, I pushed this. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: more ALTER .. DEPENDS ON EXTENSION fixes

I pushed this (to pg13 only) using the originally proposed "NO DEPENDS" syntax. It's trivial to change to REVOKE DEPENDS on REMOVE DEPENDS if we decide to do that. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Adding missing object access hook invocations

On 2020-Apr-20, Michael Paquier wrote: > Unfortunately, we are past feature freeze so this will have to wait > until v14 opens for business to be merged, and I'll take care of it. > Or would others prefer to not wait one extra year for those changes to > be released? I think it's fine to put

Re: Poll: are people okay with function/operator table redesign?

Victor Yegorov writes: > While table 9.5 with functions looks quite nice, I quite dislike 9.4 with > operators. BTW, I think a big part of the problem with table 9.4 as it's being rendered in the web style right now is that the type placeholders (numeric_type etc) are being rendered in a

Re: More efficient RI checks - take 2

> > I can imagine removal of the SPI from the current implementation (and > constructing the plans "manually"), but note that the queries I use in my > patch are no longer that trivial. So the SPI makes sense to me because it > ensures regular query planning. > As an intermediate step, in the

Re: More efficient RI checks - take 2

Corey Huinker wrote: > These numbers are very promising, and much more in line with my initial > expectations. Obviously the impact on single-row DML is of major concern, > though. Yes, I agree. > In doing my initial attempt, the feedback I was getting was that the people > who truly

Re: Poll: are people okay with function/operator table redesign?

Victor Yegorov writes: > While table 9.5 with functions looks quite nice, I quite dislike 9.4 with > operators. > Previously, I could lookup operator in the leftmost column and read on. > Right now I have to look through the whole table (well, not really, but > still) to find the operator. Aside

Re: Allow pg_read_all_stats to read pg_stat_progress_*

On Mon, Apr 20, 2020 at 4:12 PM Tom Lane wrote: > Stephen Frost writes: > > Ugh. That doesn't make it correct though.. We really should be using > > has_privs_of_role() for these cases (and that goes for all of the > > default role cases- some of which are correct and others are not, it > >

Re: Allow pg_read_all_stats to read pg_stat_progress_*

Stephen Frost writes: > Ugh. That doesn't make it correct though.. We really should be using > has_privs_of_role() for these cases (and that goes for all of the > default role cases- some of which are correct and others are not, it > seems). I have a different concern about this patch: while

Re: More efficient RI checks - take 2

Pavel Stehule wrote: >> st 8. 4. 2020 v 18:36 odesílatel Antonin Houska napsal: > >> Some performance comparisons are below. (Besides the execution time, please >> note the difference in the number of trigger function executions.) In >> general, >> the checks are significantly faster if

Re: Problem with logical replication

On Thu, 16 Apr 2020 at 17:48, Dilip Kumar wrote: > > While try to setup a cascading replication, I have observed that if we > set the REPLICA IDENTITY to FULL on the subscriber side then there is > an Assert hit. > > After analysis I have found that, when we set the REPLICA IDENTITY to > FULL on

Re: [Proposal] Global temporary tables

On 4/20/20 2:59 PM, 曾文旌 wrote: Please check my new patch. Thanks Wenjing. Please refer this below scenario , getting error -  ERROR:  could not read block 0 in file "base/16466/t4_16472": read only 0 of 8192 bytes Steps to reproduce Connect to psql terminal,create a table ( create global

Re: PG compilation error with Visual Studio 2015/2017/2019

On Sun, Apr 19, 2020 at 3:46 PM Juan José Santamaría Flecha wrote: > > > On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila wrote: >> >> On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha >> wrote: >> > >> > We can get a match for those locales in non-ISO format by enumerating >> >

Re: design for parallel backup

On Wed, Apr 15, 2020 at 9:27 PM Robert Haas wrote: > > Over at > http://postgr.es/m/CADM=JehKgobEknb+_nab9179HzGj=9eitzwmod2mpqr_rif...@mail.gmail.com > there's a proposal for a parallel backup patch which works in the way > that I have always thought parallel backup would work: instead of >

Re: It is not documented that pg_promote can exit standby mode

On 2020/04/18 2:46, Tom Lane wrote: Fujii Masao writes: Thanks for the report and the patch! It looks good to me. Barring any objection, I will commit this patch. It might be worth writing "pg_promote() is called" (adding parentheses) to make it clearer that a function is being referred

Re: Allow pg_read_all_stats to read pg_stat_progress_*

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Apr 20, 2020 at 12:43 PM Andrey M. Borodin > wrote: > > > 16 апр. 2020 г., в 17:46, Magnus Hagander > > написал(а): > > > If we do that, it may be better that we define "PGSTAT_VIEW_PRIV()" or > > > something like and replace

Re: Allow pg_read_all_stats to read pg_stat_progress_*

On Mon, Apr 20, 2020 at 12:43 PM Andrey M. Borodin wrote: > > > > 16 апр. 2020 г., в 17:46, Magnus Hagander > написал(а): > > > > > > If we do that, it may be better that we define "PGSTAT_VIEW_PRIV()" or > > something like and replace the all occurances of the idiomatic > > condition with it.

Re: Allow pg_read_all_stats to read pg_stat_progress_*

> 16 апр. 2020 г., в 17:46, Magnus Hagander написал(а): > > > If we do that, it may be better that we define "PGSTAT_VIEW_PRIV()" or > something like and replace the all occurances of the idiomatic > condition with it. > > You mean something like the attached? > > Is it correct that we

Re: Poll: are people okay with function/operator table redesign?

вс, 19 апр. 2020 г. в 20:00, Tom Lane : > In the meantime I plan to push forward with the markup approach we've > got. The editorial content should still work if we find a better > markup answer, and I'm willing to do the work of replacing the markup > as long as somebody else figures out what

Re: 001_rep_changes.pl stalls

On 2020/04/20 16:02, Noah Misch wrote: On Mon, Apr 20, 2020 at 02:30:08PM +0900, Fujii Masao wrote: +* Block if we have unsent data. XXX For logical replication, let +* WalSndWaitForWal(), handle any other blocking; idle receivers need +*

Re: [Proposal] Global temporary tables

> I think this is expected, and user test_gtt does not have permission to > vacuum the system table. > This has nothing to do with GTT. > > Hi Wenjing, Thanks for the explanation. Thanks for the new patch. I have verified the crash, Now its resolved. -- With Regards, Prabhat Kumar Sahu

Re: where should I stick that backup?

On Thu, Apr 16, 2020 at 3:44 AM Andres Freund wrote: > > > I think having a simple framework in pg_basebackup for plugging in new > > algorithms would make it noticeably simpler to add LZ4 or whatever > > your favorite compression algorithm is. And I think having that > > framework also be able

Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables

On Mon, Apr 20, 2020 at 5:49 AM Justin Pryzby wrote: > On Sun, Apr 19, 2020 at 03:13:29PM -0400, Alvaro Herrera wrote: > > On 2020-Apr-18, Justin Pryzby wrote: > > > I haven't heard a compelling argument for or against either way. > > > > > > Maybe the worst behavior might be if, during ATTACH,

Re: [Proposal] Global temporary tables

> 2020年4月17日 下午7:26，Prabhat Sahu 写道： > > On Fri, Apr 17, 2020 at 2:44 PM 曾文旌 > wrote: > > I improved the logic of the warning message so that when the gap between > relfrozenxid of GTT is small, > it will no longer be alarmed message. > > Hi Wenjing, >

Re: PG compilation error with Visual Studio 2015/2017/2019

On Mon, Apr 20, 2020 at 10:10 AM Amit Kapila wrote: > Yes, I am planning to look into it. Actually, I think the main thing > here is to ensure that we don't break something which was working with > _create_locale API. I am trying to understand how lc_messages affect the error messages on

Re: 001_rep_changes.pl stalls

At Mon, 20 Apr 2020 00:59:54 -0700, Noah Misch wrote in > On Mon, Apr 20, 2020 at 04:15:40PM +0900, Kyotaro Horiguchi wrote: > > At Sat, 18 Apr 2020 00:01:42 -0700, Noah Misch wrote in > > > On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote: > > > > At Fri, 17 Apr 2020 17:00:15

Re: Possible cache reference leak by removeExtObjInitPriv

At Fri, 17 Apr 2020 13:07:15 -0400, Tom Lane wrote in > Kyotaro Horiguchi writes: > > Recently a cache reference leak was reported then fixed [1]. > > I happened to notice a similar possible leakage in > > removeEtObjInitPriv. I haven't found a way to reach the code, but can > > be forcibly

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 12:29 PM Thomas Munro wrote: > > On Mon, Apr 20, 2020 at 6:35 PM Dilip Kumar wrote: > > On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro > > wrote: > > > > > > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote: > > > > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro > > >

Re: 001_rep_changes.pl stalls

On Mon, Apr 20, 2020 at 04:15:40PM +0900, Kyotaro Horiguchi wrote: > At Sat, 18 Apr 2020 00:01:42 -0700, Noah Misch wrote in > > On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote: > > > At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi > > > wrote in > > > > By the

Re: 001_rep_changes.pl stalls

At Mon, 20 Apr 2020 14:30:08 +0900, Fujii Masao wrote in > > > On 2020/04/18 16:01, Noah Misch wrote: > > On Sat, Apr 18, 2020 at 12:29:58AM +0900, Fujii Masao wrote: > >>> 4. Keep the WalSndLoop() wait, but condition it on !logical. This is > >>> the > >>> minimal fix, but it crudely

Re: 001_rep_changes.pl stalls

At Sat, 18 Apr 2020 00:01:42 -0700, Noah Misch wrote in > On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote: > > At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > By the way, if latch is consumed in WalSndLoop, succeeding call to > > >

Re: 001_rep_changes.pl stalls

On Mon, Apr 20, 2020 at 02:30:08PM +0900, Fujii Masao wrote: > + * Block if we have unsent data. XXX For logical replication, > let > + * WalSndWaitForWal(), handle any other blocking; idle > receivers need > + * its additional actions. For physical

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 6:35 PM Dilip Kumar wrote: > On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro wrote: > > > > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote: > > > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro > > > wrote: > > Is this an improvement? I realise that there is still

Re: where should I stick that backup?

On Mon, Apr 13, 2020 at 5:57 AM Stephen Frost wrote: > > There's a couple of other pieces here that I think bear mentioning. The > first is that pgBackRest has an actual 'restore' command- and that works > with the filters and works with the storage drivers, so what you're > looking at when it

Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro wrote: > > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar wrote: > > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro > > wrote: > > > I think I found another bug in MaintainOldSnapshotTimeMapping(): if > > > you make time jump by more than

Remove non-fast promotion Re: Should we remove a fallback promotion? take 2

On 2020/03/10 6:56, Andres Freund wrote: Hi, On 2020-03-06 16:33:18 -0300, Alvaro Herrera wrote: On 2020-Mar-06, Michael Paquier wrote: On Thu, Mar 05, 2020 at 09:40:54AM -0500, Robert Haas wrote: Seems reasonable, but it would be better if people proposed these kinds of changes closer to

Re: Race condition in SyncRepGetSyncStandbysPriority

On 2020/04/18 0:31, Tom Lane wrote: Kyotaro Horiguchi writes: At Fri, 17 Apr 2020 16:03:34 +0900, Fujii Masao wrote in I agree that it might be worth considering the removal of am_sync for the master branch or v14. But I think that it should not be back-patched. Ah! Agreed. Yeah,

Re: where should I stick that backup?

On Mon, Apr 20, 2020 at 8:18 AM Amit Kapila wrote: > > On Sat, Apr 18, 2020 at 8:35 PM Robert Haas wrote: > > > > On Fri, Apr 17, 2020 at 7:44 PM Andres Freund wrote: > > > This suggest that pipes do have a considerably higher overhead on > > > windows, but that it's not all that terrible if