Re: [HACKERS] Restricting maximum keep segments by repslots

At Tue, 31 Mar 2020 18:01:36 -0300, Alvaro Herrera wrote in > I noticed some other things: > > 1. KeepLogSeg sends a warning message when slots fall behind. To do > this, it searches for "the most affected slot", that is, the slot that > lost the most data. But it seems to me that that's a

Re: backup manifests

On Tue, Mar 31, 2020 at 03:50:34PM -0700, Andres Freund wrote: > On 2020-03-31 14:10:34 -0400, Robert Haas wrote: > > +/* > > + * Attempt to parse the WAL files required to restore from backup using > > + * pg_waldump. > > + */ > > +static void > > +parse_required_wal(validator_context *context,

wraparound dangers in snapshot too old

Hi, I am trying to change the snapshot too old infrastructure so it cooperates with my snapshot scalability patch. While trying to understand the code sufficiently, I think I found a fairly serious issue: To map the time-based old_snapshot_threshold to an xid that can be used as a cutoff for

Re: control max length of parameter values logged

Hi, On Wed, Apr 01, 2020 at 01:52:48AM +0100, Alexey Bashtanov wrote: > +++ b/doc/src/sgml/config.sgml > + xreflabel="log_parameter_max_length"> > + log_parameter_max_length > (integer) > + > + log_parameter_max_length configuration > parameter > + > + > +

Re: A bug when use get_bit() function for a long bytea string

>+ int64 res,resultlen; >It's better to have them on separate lines. Sorry for that, done. >-unsigned >+int64 > hex_decode(const char *src, unsigned len, char *dst) >Do we want to explicitly cast the return value to int64? Will build on some >platform crib if not done so? >I don't know of such

Re: [Proposal] Global temporary tables

On Wed, Apr 1, 2020 at 8:52 AM 曾文旌 wrote: > > > 2020年3月31日 下午9:59，Prabhat Sahu 写道： > > Hi Wenjing, > Thanks for the new patch. > I saw with the patch(gtt_v23.patch), we are supporting the new concept > "global temporary sequence"(i.e. session-specific sequence), is this > intentional? > > It

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Wed, 1 Apr 2020 at 13:45, Andy Fan wrote: >> 5. I think you should be performing a bms_del_member during join >> removal rather than removing this Assert() >> >> - Assert(bms_equal(rel->relids, root->all_baserels)); >> >> FWIW, it's far from perfect that you've needed to delay the left join >>

Re: [Proposal] Global temporary tables

> 2020年3月31日 下午9:59，Prabhat Sahu 写道： > > Hi Wenjing, > Thanks for the new patch. > I saw with the patch(gtt_v23.patch), we are supporting the new concept > "global temporary sequence"(i.e. session-specific sequence), is this > intentional? It was supported in earlier versions, This causes

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, Apr 1, 2020 at 8:26 AM Masahiko Sawada wrote: > > On Wed, 1 Apr 2020 at 11:46, Amit Kapila wrote: > > > > On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote: > > > > > > While testing I have found one issue. Basically, during a parallel > > > vacuum, it was showing more number of > > >

Re: Tab completion for \gx

Patch applied though PG 10, thanks. --- On Thu, Mar 26, 2020 at 09:58:50AM -0700, Vik Fearing wrote: > While reviewing the patch for \gf, I noticed that \gx does not have tab > completion for its optional filename.

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, 1 Apr 2020 at 11:46, Amit Kapila wrote: > > On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote: > > > > While testing I have found one issue. Basically, during a parallel > > vacuum, it was showing more number of > > shared_blk_hits+shared_blks_read. After, some investigation, I found >

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Wed, Apr 1, 2020 at 8:16 AM Amit Kapila wrote: > > On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote: > > > > While testing I have found one issue. Basically, during a parallel > > vacuum, it was showing more number of > > shared_blk_hits+shared_blks_read. After, some investigation, I found

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Tue, Mar 31, 2020 at 7:32 PM Dilip Kumar wrote: > > While testing I have found one issue. Basically, during a parallel > vacuum, it was showing more number of > shared_blk_hits+shared_blks_read. After, some investigation, I found > that during the cleanup phase nworkers are -1, and because

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 10:12:29PM -0400, James Coleman wrote: On Tue, Mar 31, 2020 at 9:59 PM Tomas Vondra wrote: On Tue, Mar 31, 2020 at 08:42:47PM -0400, James Coleman wrote: >On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra > wrote: >> >> On Tue, Mar 31, 2020 at 08:11:15PM -0400, James

Re: recovery_target_action=pause with confusing hint

>> When I test the patch, I find an issue: I start a stream with >> 'promote_trigger_file' >> GUC valid, and exec pg_wal_replay_pause() during recovery and as below it >> shows success to pause at the first time. I think it use a initialize >> 'SharedPromoteIsTriggered' value first time I exec

Re: Issues with building cpp extensions on PostgreSQL 10+

Patch applied to PG 10, thanks. I don't know about your other questions, but if you want to propose a patch, we can review it. Thanks. --- On Fri, Mar 20, 2020 at 05:02:15PM +0100, Oleksii Kliukin wrote: > Hello, > >

Re: error context for vacuum to include block number

On Tue, Mar 31, 2020 at 8:53 AM Justin Pryzby wrote: > > On Tue, Mar 31, 2020 at 07:50:45AM +0530, Amit Kapila wrote: > > One thing I have noticed is that there is some saving by using > > vacrelstats->relnamespace as that avoids sys cache lookup. OTOH, > > using vacrelstats->relname doesn't

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On Tue, Mar 31, 2020 at 03:48:21PM +0900, Michael Paquier wrote: > Thanks, committed 0001 after fixing the order of the headers. One > patch left. And committed now 0002, meaning that we are officially done. Thanks Alexey for your patience. -- Michael signature.asc Description: PGP signature

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 9:59 PM Tomas Vondra wrote: > > On Tue, Mar 31, 2020 at 08:42:47PM -0400, James Coleman wrote: > >On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra > > wrote: > >> > >> On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote: > >> >On Tue, Mar 31, 2020 at 7:56 PM Tomas

Re: Race condition in SyncRepGetSyncStandbysPriority

On Tue, 31 Mar 2020 at 23:16, Masahiko Sawada wrote: > > On Fri, 27 Mar 2020 at 13:54, Fujii Masao wrote: > > > > > > > > On 2020/03/27 10:26, Tom Lane wrote: > > > Twice in the past month [1][2], buildfarm member hoverfly has managed > > > to reach the "unreachable" Assert(false) at the end of

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 08:42:47PM -0400, James Coleman wrote: On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra wrote: On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote: >On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra > wrote: >> >> On Tue, Mar 31, 2020 at 07:09:04PM -0400, James

Re: backend type in log_line_prefix?

On Fri, Mar 27, 2020 at 04:30:07PM +0900, Kyotaro Horiguchi wrote: > Hello. > > At Mon, 23 Mar 2020 18:38:53 -0400, Bruce Momjian wrote in > > Patch applied to master, thanks. > > The patch (8e8a0becb3) named archiver process as just "archiver". On > the other hand the discussion in the

Re: [HACKERS] Restricting maximum keep segments by repslots

At Tue, 31 Mar 2020 16:59:05 -0300, Alvaro Herrera wrote in > On 2020-Mar-31, Alvaro Herrera wrote: > > > On 2020-Mar-31, Alvaro Herrera wrote: > > > > > I'm not sure if I explained my proposal clearly. What if > > > XLogGetLastRemovedSegno returning zero means that every segment is > > >

Re: [HACKERS] Restricting maximum keep segments by repslots

At Tue, 31 Mar 2020 14:18:36 -0300, Alvaro Herrera wrote in > On 2020-Mar-31, Alvaro Herrera wrote: > > > I'm not sure if I explained my proposal clearly. What if > > XLogGetLastRemovedSegno returning zero means that every segment is > > valid? We don't need to scan pg_xlog at all. > > I

Re: control max length of parameter values logged

Alexey Bashtanov writes: > Sorry for the delay, please could you have a look? Got it, will look tomorrow. (I think it's important to get this done for v13, before we ship this behavior.) regards, tom lane

Re: control max length of parameter values logged

Also agreed. It's been like it is for a long time with not that many complaints, so the case for changing the default behavior seems a bit weak. Barring other opinions, I think we have consensus here on what to do. Alexey, will you update your patch? Sorry for the delay, please could you

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Thanks David for your time, I will acknowledge every item you mentioned with the updated patch. Now I just talk about part of them. > 1. There seem to be some cases where joins are no longer being > detected as unique. This is evident in postgres_fdw.out. We shouldn't > be regressing any of

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 8:38 PM Tomas Vondra wrote: > > On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote: > >On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra > > wrote: > >> > >> On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote: > >> >On Tue, Mar 31, 2020 at 6:54 PM Tomas

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 08:11:15PM -0400, James Coleman wrote: On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra wrote: On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote: >On Tue, Mar 31, 2020 at 6:54 PM Tomas Vondra > wrote: >> >> On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On 2020-Mar-31, Tom Lane wrote: > James Coleman writes: > > On Tue, Mar 31, 2020 at 1:04 PM Tom Lane wrote: > >> Perhaps the semantics are such that that's actually sensible, but it's > >> far from a straightforward remapping of the old enum. > > > Right, I didn't see the explicit "= 0" in

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 7:56 PM Tomas Vondra wrote: > > On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote: > >On Tue, Mar 31, 2020 at 6:54 PM Tomas Vondra > > wrote: > >> > >> On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote: > >> >Tomas Vondra writes: > >> >> In general, I

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 07:09:04PM -0400, James Coleman wrote: On Tue, Mar 31, 2020 at 6:54 PM Tomas Vondra wrote: On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote: >Tomas Vondra writes: >> In general, I think it'd be naive that we can make planner smarter with >> no extra overhead

Re: proposal \gcsv

I took a look at this proposal, and while I see the value of being able to do something like this, it seems pretty short-sighted and non-orthogonal as it stands. We've already got \gx, which is a wart, and now this patch wants to add \gfmt which is a different wart of the same ilk. What happens

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020-03-27 04:15, Kartyshov Ivan wrote: Anna, feel free to work on this patch. Ivan and I worked on this patch a bit more. We fixed the bugs that we could find and cleaned up the code. For now, we've kept both options: WAIT as a standalone statement and WAIT as a part of BEGIN. The new

Re: Less-silly selectivity for JSONB matching operators

On 31/03/2020 18:53, Tom Lane wrote: Renamed "matchsel" to "matchingsel" etc, added DEFAULT_MATCHING_SEL, rebased over commit 911e70207. Since that commit already created new versions of the relevant contrib modules, I think we can just redefine what those versions contain, rather than making

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 6:54 PM Tomas Vondra wrote: > > On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote: > >Tomas Vondra writes: > >> In general, I think it'd be naive that we can make planner smarter with > >> no extra overhead spent on planning, and we can never accept patches > >>

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 06:35:32PM -0400, Tom Lane wrote: Tomas Vondra writes: In general, I think it'd be naive that we can make planner smarter with no extra overhead spent on planning, and we can never accept patches adding even tiny overhead. With that approach we'd probably end up with a

Re: backup manifests

Hi, On 2020-03-31 14:10:34 -0400, Robert Haas wrote: > I made an attempt to implement this. Awesome! > In the attached patch set, 0001 I'm going to work on those things. I > would appreciate *very timely* feedback on anything people do or do > not like about this, because I want to commit this

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 06:00:00PM -0400, James Coleman wrote: On Tue, Mar 31, 2020 at 5:53 PM Tomas Vondra wrote: On Tue, Mar 31, 2020 at 02:23:15PM -0400, James Coleman wrote: >On Mon, Mar 30, 2020 at 9:14 PM Tomas Vondra > wrote: >> >> The main thing I've been working on today is

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

Tomas Vondra writes: > In general, I think it'd be naive that we can make planner smarter with > no extra overhead spent on planning, and we can never accept patches > adding even tiny overhead. With that approach we'd probably end up with > a trivial planner that generates just a single query

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-Mar-31, Alvaro Herrera wrote: > I think we should kill(SIGTERM) the walsender using the slot > (slot->active_pid), > then acquire the slot and set it to some state indicating that it is now > useless, no longer reserving WAL; so when the walsender is restarted, it > will find the slot

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-Mar-31, Alvaro Herrera wrote: > /* release lock before syscalls */ > foreach(l, pids_to_kill) > { > kill(SIGTERM, lfirst_int(l)); > } > > I sense some attempt to salvage

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 5:53 PM Tomas Vondra wrote: > > On Tue, Mar 31, 2020 at 02:23:15PM -0400, James Coleman wrote: > >On Mon, Mar 30, 2020 at 9:14 PM Tomas Vondra > > wrote: > >> > >> The main thing I've been working on today is benchmarking how this > >> affects planning. And I'm seeing a

Re: Improving connection scalability: GetSnapshotData()

Hi, On 2020-03-31 13:04:38 -0700, Andres Freund wrote: > I'm still fighting with snapshot_too_old. The feature is just badly > undertested, underdocumented, and there's lots of other oddities. I've > now spent about as much time on that feature than on the whole rest of > the patchset. To expand

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 02:23:15PM -0400, James Coleman wrote: On Mon, Mar 30, 2020 at 9:14 PM Tomas Vondra wrote: The main thing I've been working on today is benchmarking how this affects planning. And I'm seeing a regression that worries me a bit, unfortunately. The test I'm doing is

Re: Rethinking opclass member checks and dependency strength

Alvaro Herrera writes: > On 2019-Aug-18, Tom Lane wrote: >> * I'm not at all impressed with the name, location, or concept of >> opfam_internal.h. I think we should get rid of that header and put >> the OpFamilyMember struct somewhere else. Given that this patch >> makes it part of the AM API,

Re: Berserk Autovacuum (let's save next Mandrill)

I wrote: > Dean Rasheed writes: >> I had a go at reproducing this. I wasn't able to produce the reported >> failure, but I can reliably produce an Assert failure that may be >> related by doing a VACUUM FULL simultaneously with an ANALYZE that is >> generating extended stats, which produces: >>

Re: Rethinking opclass member checks and dependency strength

On 2019-Aug-18, Tom Lane wrote: > * I'm not at all impressed with the name, location, or concept of > opfam_internal.h. I think we should get rid of that header and put > the OpFamilyMember struct somewhere else. Given that this patch > makes it part of the AM API, it wouldn't be unreasonable

Re: [HACKERS] Restricting maximum keep segments by repslots

I noticed some other things: 1. KeepLogSeg sends a warning message when slots fall behind. To do this, it searches for "the most affected slot", that is, the slot that lost the most data. But it seems to me that that's a bit pointless; if a slot data, it's now useless and anything that was

Re: Berserk Autovacuum (let's save next Mandrill)

Dean Rasheed writes: > I had a go at reproducing this. I wasn't able to produce the reported > failure, but I can reliably produce an Assert failure that may be > related by doing a VACUUM FULL simultaneously with an ANALYZE that is > generating extended stats, which produces: > ... > It looks to

Re: Rethinking opclass member checks and dependency strength

I wrote: > Still haven't got a better naming idea, but in the meantime here's > a rebase to fix a conflict with 612a1ab76. I see from the cfbot that this needs another rebase, so here 'tis. No changes in the patch itself. regards, tom lane diff --git

Re: Small docs bugfix: make it clear what can be used in UPDATE FROM and DELETE USING

On Wed, Mar 18, 2020 at 12:24:45PM -0400, Bruce Momjian wrote: > On Tue, Mar 17, 2020 at 10:58:54PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > I have implemented the ideas above in the attached patch. I have > > > synchronized the syntax to match SELECT, and synchronized the

Re: Berserk Autovacuum (let's save next Mandrill)

On Tue, 31 Mar 2020 at 04:39, David Rowley wrote: > > On Sat, 28 Mar 2020 at 22:22, David Rowley wrote: > > I'm unsure yet if this has caused an instability on lousyjack's run in > > [1]. > > pogona has just joined in on the fun [1], so, we're not out the woods > on this yet. I'll start having a

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

On Tue, Mar 17, 2020 at 02:04:01PM -0500, Justin Pryzby wrote: > > The example in the documentation could be better indented. Also, ISTM that > > there are two implicit laterals (format & pg_ls_dir_recurse) that I would > > make explicit. I'd use the pcs alias explicitely. I'd use meaningful

Re: Improving connection scalability: GetSnapshotData()

Hi, I'm still fighting with snapshot_too_old. The feature is just badly undertested, underdocumented, and there's lots of other oddities. I've now spent about as much time on that feature than on the whole rest of the patchset. As an example for under-documented, here's a definitely non-trivial

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-Mar-31, Alvaro Herrera wrote: > On 2020-Mar-31, Alvaro Herrera wrote: > > > I'm not sure if I explained my proposal clearly. What if > > XLogGetLastRemovedSegno returning zero means that every segment is > > valid? We don't need to scan pg_xlog at all. > > I mean this: [v21 does it

Re: Add A Glossary

On Tue, Mar 31, 2020 at 2:09 PM Justin Pryzby wrote: > On Sun, Oct 13, 2019 at 04:52:05PM -0400, Corey Huinker wrote: > > 1. It's obviously incomplete. There are more terms, a lot more, to add. > > How did you come up with the initial list of terms ? > 1. I asked some newer database people to

Re: WIP: System Versioned Temporal Table

Hi Surafel and the rest, I'm the owner of the Israeli meetup group of PostgreSQL, and I'm interested in Temporality and have been trying for several years a few ways to add it to PostgreSQL (all of them through extensions and external ways). I'm happy that this is done by you internally (and a

Re: recovery_target_action=pause with confusing hint

   My proposal does not change the behavior after this commit, only changing the lines in the logs. >>> >>>  Yes. What's your opinion about the latest patch based on Robert's idea? >>>  Barring any ojection, I'd like to commit that. >> >>  Oh, sorry. Looks good and solves my issue > >

Re: Planning counters in pg_stat_statements (using pgss_store)

On Wed, Apr 01, 2020 at 02:43:10AM +0900, Fujii Masao wrote: > > > On 2020/03/31 16:33, Julien Rouhaud wrote: > > > > v12 attached! > > Thanks for updating the patch! The patch looks good to me. > > I applied minor and cosmetic changes into the patch. Attached is > the updated version of the

Re: recovery_target_action=pause with confusing hint

On 2020/03/31 19:33, Sergei Kornilov wrote: Hello  My proposal does not change the behavior after this commit, only changing the lines in the logs. Yes. What's your opinion about the latest patch based on Robert's idea? Barring any ojection, I'd like to commit that. Oh, sorry. Looks

Re: Ecpg dependency

On Sat, Mar 21, 2020 at 06:13:03PM -0400, Bruce Momjian wrote: > On Sat, Mar 21, 2020 at 07:30:48PM +, Dagfinn Ilmari Mannsåker wrote: > > Bruce Momjian writes: > > > On Sat, Mar 21, 2020 at 02:14:44PM -0400, Bruce Momjian wrote: > > > Oh, I forgot to mention I got this line from > > >

Re: Add A Glossary

On Sun, Oct 13, 2019 at 04:52:05PM -0400, Corey Huinker wrote: > 1. It's obviously incomplete. There are more terms, a lot more, to add. How did you come up with the initial list of terms ? Here's some ideas; I'm *not* suggesting to include all of everything, but hopefully start with a coherent,

Re: Add A Glossary

On Mon, Mar 30, 2020 at 01:10:19PM -0400, Corey Huinker wrote: > + > +Aggregating > + > + > + The act of combining a collection of data (input) values into > + a single output value, which may not be of the same type as the > + input values. I think we maybe already

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

James Coleman writes: > On Tue, Mar 31, 2020 at 1:04 PM Tom Lane wrote: >> Perhaps the semantics are such that that's actually sensible, but it's >> far from a straightforward remapping of the old enum. > Right, I didn't see the explicit "= 0" in other enums there, so it > made me wonder if it

Re: Add A Glossary

On Tue, Mar 31, 2020 at 04:13:00PM +0200, Jürgen Purtz wrote: > Please find some minor suggestions in the attachment. They are based on > Corey's last patch 0001-glossary-v4.patch. > @@ -220,7 +220,7 @@ >Records to the file system and creates a special >checkpoint record. This

Re: Less-silly selectivity for JSONB matching operators

Renamed "matchsel" to "matchingsel" etc, added DEFAULT_MATCHING_SEL, rebased over commit 911e70207. Since that commit already created new versions of the relevant contrib modules, I think we can just redefine what those versions contain, rather than making yet-newer versions. (Of course, that

Re: Planning counters in pg_stat_statements (using pgss_store)

On 2020/03/31 16:33, Julien Rouhaud wrote: On Tue, Mar 31, 2020 at 04:10:47PM +0900, Fujii Masao wrote: On 2020/03/31 15:03, Julien Rouhaud wrote: On Tue, Mar 31, 2020 at 12:21:43PM +0900, Fujii Masao wrote: On 2020/03/31 3:16, Julien Rouhaud wrote: On Mon, Mar 30, 2020 at 6:36 PM Fujii

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 1:04 PM Tom Lane wrote: > > James Coleman writes: > > + * TuplesortMethod is used in a bitmask in Increment Sort's shared memory > > + * instrumentation so needs to have each value be a separate bit. > > >> I don't quite understand why you skipped "1". (Also, is the use

Re: Explain: Duplicate key "Workers" in JSON format

On 2020-Mar-31, Tom Lane wrote: > Alvaro Herrera writes: > > We have not fixed this, have we? > > Isn't this 10013684970453a0ddc86050bba813c64321 ? Ah, right, another thread reporting the same thing, two months after this one. Thanks both :-) -- Álvaro Herrera

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-Mar-31, Alvaro Herrera wrote: > I'm not sure if I explained my proposal clearly. What if > XLogGetLastRemovedSegno returning zero means that every segment is > valid? We don't need to scan pg_xlog at all. I mean this: XLogSegNo FindOldestXLogFileSegNo(void) { XLogSegNo segno =

[PATCH] Fix type var declaration (src/backend/access/brin/brin.c)

Hi, bringetbitmap function returns int64 value, but internally uses int. For prevent future bugs, fix to right type. best regards, Ranier Vilela fix_int64_brin.patch Description: Binary data

Re: Explain: Duplicate key "Workers" in JSON format

Alvaro Herrera writes: > We have not fixed this, have we? Isn't this 10013684970453a0ddc86050bba813c64321 ? regards, tom lane

Re: Explain: Duplicate key "Workers" in JSON format

On 2020-03-31 14:06:50 -0300, Alvaro Herrera wrote: > We have not fixed this, have we? I thought we did: commit 10013684970453a0ddc86050bba813c64321 Author: Tom Lane Date: 2020-01-25 18:16:42 -0500 Clean up EXPLAIN's handling of per-worker details. Previously, it was possible

Re: Explain: Duplicate key "Workers" in JSON format

We have not fixed this, have we? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

James Coleman writes: > + * TuplesortMethod is used in a bitmask in Increment Sort's shared memory > + * instrumentation so needs to have each value be a separate bit. >> I don't quite understand why you skipped "1". (Also, is the use of zero >> a wise choice?) > The assignment of 0 was

Re: Less-silly selectivity for JSONB matching operators

Alexey Bashtanov writes: >> I was wondering about DEFAULT_MATCHING_SEL. The difference in purpose >> from DEFAULT_MATCH_SEL wouldn't be too obvious, but then it probably >> wouldn't be anyway. > Fine with me, especially if both new functions are renamed accordingly. Yup, that would make sense,

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Mar 31, 2020 at 12:31 PM Alvaro Herrera wrote: > > On 2020-Mar-30, James Coleman wrote: > > > +/* > > + *Instruementation information for IncrementalSort > > + * > > + */ > > +typedef struct IncrementalSortGroupInfo > > +{ > > + int64

Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction

Justin Pryzby writes: > I suggest to leave stat() alone in your patch for stable releases. I think > it's okay if we change behavior so that a broken symlink is skipped instead of > erroring (as a side effect of skipping ENOENT with stat()). But not okay if > we > change pg_ls_logdir() to hide

Re: Less-silly selectivity for JSONB matching operators

I was wondering about DEFAULT_MATCHING_SEL. The difference in purpose from DEFAULT_MATCH_SEL wouldn't be too obvious, but then it probably wouldn't be anyway. Fine with me, especially if both new functions are renamed accordingly. Best, Alex

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On 2020-Mar-30, James Coleman wrote: > +/* > + *Instruementation information for IncrementalSort > + * > + */ > +typedef struct IncrementalSortGroupInfo > +{ > + int64 groupCount; > + longmaxDiskSpaceUsed; > + long

Re: Less-silly selectivity for JSONB matching operators

Alexey Bashtanov writes: >> So that leaves us with needing >> to find a better name for this new one. Any ideas? > I'm thinking of something wide like > opersel, operjoinsel, DEFAULT_OPER_SEL > or maybe even > genericsel, genericjoinsel, DEFAULT_GENERIC_SEL Seems a little *too* generic :-( I

Re: Less-silly selectivity for JSONB matching operators

So that leaves us with needing to find a better name for this new one. Any ideas? I'm thinking of something wide like opersel, operjoinsel, DEFAULT_OPER_SEL or maybe even genericsel, genericjoinsel, DEFAULT_GENERIC_SEL Best, Alex

Re: Less-silly selectivity for JSONB matching operators

Alexey Bashtanov writes: > The only little thing I can think of is hardcoding it as 2 * DEFAULT_EQ_SEL. > While I don't have any arguments against the value itself I think it > should be configurable independently. > Sadly DEFAULT_MATCH_SEL name is already taken for text patterns. > Not sure if

Re: Less-silly selectivity for JSONB matching operators

Quickly tested like this: create table t(a jsonb); insert into t select jsonb_object( array[(random() * 10)::int::text], '{" "}') from generate_series(1, 10); insert into t select jsonb_object( array[(random() * 10)::int::text], array[(random() * 1000)::int::text]) from generate_series(1,

Re: Less-silly selectivity for JSONB matching operators

Hi Tom, The patches look entirely reasonable to me. The second one needs to be rebased. I like the idea of stubbing matchjoinsel for now, as well as being careful with operators that may correlate with sort orderings. The only little thing I can think of is hardcoding it as 2 *

Re: fix for BUG #3720: wrong results at using ltree

I wrote: > I've marked this RFC, and will push tomorrow unless somebody wants > to object to the loss of backwards compatibility. And done. I noticed in some final testing that it's possible to make this code take a long time by forcing it to backtrack a lot: regression=# SELECT (('1' ||

Re: A rather hackish POC for alternative implementation of WITH TIES

On 2020-Mar-26, Surafel Temesgen wrote: > On Wed, Jan 22, 2020 at 3:35 PM Andrew Gierth > wrote: > > > > "Alvaro" == Alvaro Herrera writes: > > > > I was largely holding off on doing further work hoping for some > > discussion of which way we should go. If you think my approach is worth >

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-Mar-31, Kyotaro Horiguchi wrote: > Thank you for looking this and trouble rebasing! > > At Mon, 30 Mar 2020 20:03:27 -0300, Alvaro Herrera > wrote in > > I rebased this patch; it's failing to apply due to minor concurrent > > changes in PostgresNode.pm. I squashed the patches in a

Re: [PATCH] remove condition always true (/src/backend/access/heap/vacuumlazy.c)

Hi, Thanks for the commit. Ranier Vilela

Re: WAL usage calculation patch

On Tue, Mar 31, 2020 at 7:39 PM Julien Rouhaud wrote: > > On Tue, Mar 31, 2020 at 12:21 PM Kuntal Ghosh > wrote: > > > > On Mon, Mar 30, 2020 at 6:14 PM Julien Rouhaud wrote: > > > > > @@ -448,6 +449,7 @@ XLogInsert(RmgrId rmid, uint8 info) > > bool doPageWrites; > > XLogRecPtr fpw_lsn; > >

Re: Race condition in SyncRepGetSyncStandbysPriority

On Fri, 27 Mar 2020 at 13:54, Fujii Masao wrote: > > > > On 2020/03/27 10:26, Tom Lane wrote: > > Twice in the past month [1][2], buildfarm member hoverfly has managed > > to reach the "unreachable" Assert(false) at the end of > > SyncRepGetSyncStandbysPriority. > > When I search the past

Re: Add A Glossary

On 30.03.20 19:10, Corey Huinker wrote: On Sun, Mar 29, 2020 at 5:29 AM Jürgen Purtz > wrote: On 27.03.20 21:12, Justin Pryzby wrote: > On Fri, Mar 20, 2020 at 11:32:25PM +0100, Jürgen Purtz wrote: + Archiver >>> Can you change that to archiver

Re: WAL usage calculation patch

On Tue, Mar 31, 2020 at 12:21 PM Kuntal Ghosh wrote: > > On Mon, Mar 30, 2020 at 6:14 PM Julien Rouhaud wrote: > > > @@ -448,6 +449,7 @@ XLogInsert(RmgrId rmid, uint8 info) > bool doPageWrites; > XLogRecPtr fpw_lsn; > XLogRecData *rdt; > + int num_fpw = 0; > > /* > * Get values needed

Re: A bug when use get_bit() function for a long bytea string

Thanks for the changes, + int64 res,resultlen; It's better to have them on separate lines. -unsigned +int64 hex_decode(const char *src, unsigned len, char *dst) Do we want to explicitly cast the return value to int64? Will build on some platform crib if not done so? I don't know of such a

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

On Tue, Mar 31, 2020 at 12:20 PM Dilip Kumar wrote: > > On Tue, Mar 31, 2020 at 10:44 AM Masahiko Sawada > wrote: > > > > On Tue, 31 Mar 2020 at 12:58, Amit Kapila wrote: > > > > > > On Mon, Mar 30, 2020 at 12:31 PM Masahiko Sawada > > > wrote: > > > > > > > > The patch for vacuum conflicts

Re: WAL usage calculation patch

On Tue, Mar 31, 2020 at 12:17 PM Amit Kapila wrote: > > It is possible that both of us are having different meanings for below > two variables: > +typedef struct WalUsage > +{ > + long wal_records; /* # of WAL records produced */ > + long wal_fpw_records; /* # of full page write WAL records > + *

Re: Random set of typos spotted

On Tue, Mar 31, 2020 at 3:37 PM Daniel Gustafsson wrote: > > A collection of random typos in docs and comments spotted while working around > the tree. Thanks, pushed! -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/

Re: [Proposal] Global temporary tables

Hi Wenjing, Thanks for the new patch. I saw with the patch(gtt_v23.patch), we are supporting the new concept "global temporary sequence"(i.e. session-specific sequence), is this intentional? postgres=# create *global temporary sequence* gt_seq; CREATE SEQUENCE postgres=# create sequence seq;

Re: WAL usage calculation patch

On Tue, Mar 31, 2020 at 11:21 AM Dilip Kumar wrote: > > I have started reviewing this patch and I have some comments/questions. Thanks a lot! > > 1. > @@ -22,6 +22,10 @@ static BufferUsage save_pgBufferUsage; > > static void BufferUsageAdd(BufferUsage *dst, const BufferUsage *add); > >

  1   2   >