Re: Allow continuations in "pg_hba.conf" files

Hello David, +Agree. However, it would nice to update the sentence below if I understand it correctly. "+   Comments, whitespace and continuations are handled in the same way as in" pg_hba.conf In the attached v3, I've tried to clarify comments and doc about tokenization rules relating

Re: User Interface for WAL usage data

On Fri, Apr 03, 2020 at 10:52:02AM +0530, Amit Kapila wrote: > On Fri, Apr 3, 2020 at 10:41 AM Justin Pryzby wrote: > > > > > > > > > >WAL: records=2359 full page records=42 bytes=447788 > > > > 1) records; 2) pages ("full page images"); 3) bytes > > > > That is exactly like sort

Re: pgbench - add \aset to store results of a combined query

Bonjour Michaël, Sure. I meant that the feature would make sense to write benchmark scripts which would use aset and be able to act on the success or not of this aset, not to resurrect it for a hidden coverage test. This could always be discussed for v14. We'll see. Or v15, or never, who

Re: User Interface for WAL usage data

On Fri, Apr 3, 2020 at 10:41 AM Justin Pryzby wrote: > > > > > > > >WAL: records=2359 full page records=42 bytes=447788 > > 1) records; 2) pages ("full page images"); 3) bytes > > That is exactly like sort (method/type/size) and hash (buckets/batches/size), > and *not* like buffers, which

Re: User Interface for WAL usage data

> > > > > Regarding > > > > > v10-0004-Add-option-to-report-WAL-usage-in-EXPLAIN-and-au.patch: > > > > > I think there should be additional spaces before "full" and before > > > > > "bytes": > > > > > > > > > > >WAL: records=2359 full page records=42 bytes=447788 > > > > > > > > > > Compare

Re: Some problems of recovery conflict wait events

On Fri, 3 Apr 2020 at 12:28, Fujii Masao wrote: > > > > On 2020/04/02 16:12, Fujii Masao wrote: > > > > > > On 2020/04/02 15:54, Masahiko Sawada wrote: > >> On Thu, 2 Apr 2020 at 15:34, Fujii Masao > >> wrote: > >>> > >>> > >>> > >>> On 2020/04/02 14:25, Masahiko Sawada wrote: > On Wed, 1

Re: Removing unneeded self joins

On 4/1/20 8:34 PM, David Steele wrote: This patch no longer applies cleanly on src/test/regress/sql/equivclass.sql: http://cfbot.cputube.org/patch_27_1712.log The CF entry has been updated to Waiting on Author. v.23 in attachment: 1. The patch applies cleanly. 2. Add checks: two

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 9:35 AM Dilip Kumar wrote: > > On Fri, Apr 3, 2020 at 9:17 AM Dilip Kumar wrote: > > > > On Fri, Apr 3, 2020 at 9:02 AM Amit Kapila wrote: > > > > > > On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote: > > > > > > > > I think now I got the reason. Basically, both of

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Fri, 3 Apr 2020 at 16:40, Tom Lane wrote: > (It occurs to me BTW that we've been overly conservative about using > NOT NULL constraints in planning, because of failing to consider that. > Addition or drop of NOT NULL has to cause a change in > pg_attribute.attnotnull, which will definitely

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 9:17 AM Dilip Kumar wrote: > > On Fri, Apr 3, 2020 at 9:02 AM Amit Kapila wrote: > > > > On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote: > > > > > > I think now I got the reason. Basically, both of these records are > > > storing the FPW, and FPW size can vary based on

Re: Unicode normalization SQL functions

On Thu, Apr 2, 2020 at 3:51 PM Peter Eisentraut wrote: > > On 2020-03-26 18:41, John Naylor wrote: > > We don't have a trie implementation in Postgres, but we do have a > > perfect hash implementation. Doing that would bring the tables back to > > 64 bits per entry, but would likely be noticeably

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 9:02 AM Amit Kapila wrote: > > On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote: > > > > I think now I got the reason. Basically, both of these records are > > storing the FPW, and FPW size can vary based on the hole size on the > > page. If hold size is smaller the

Re: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”

On 02-Apr-2020, at 19:25, Tom Lane wrote: Bryn Llewellyn writes: > The documentation in section “8.16.2. Constructing Composite Values” here: > https://www.postgresql.org/docs/11/rowtypes.html#ROWTYPES-IO-SYNTAX > The

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

David Rowley writes: > For just planner smarts such as LEFT JOIN removal, Unique Joins, and > all this Unique Key stuff, we really don't need to record the > dependency as if the index or constraint is dropped, then that'll > cause a relcache invalidation and we'll see the invalidation when we >

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 8:55 AM Dilip Kumar wrote: > > I think now I got the reason. Basically, both of these records are > storing the FPW, and FPW size can vary based on the hole size on the > page. If hold size is smaller the image length will be more, the > image_len= BLCKSZ-hole_size. So

Re: Some problems of recovery conflict wait events

On 2020/04/02 16:12, Fujii Masao wrote: On 2020/04/02 15:54, Masahiko Sawada wrote: On Thu, 2 Apr 2020 at 15:34, Fujii Masao wrote: On 2020/04/02 14:25, Masahiko Sawada wrote: On Wed, 1 Apr 2020 at 22:32, Fujii Masao wrote: On 2020/03/30 20:10, Masahiko Sawada wrote: On Fri, 27

Re: WAL usage calculation patch

On Thu, Apr 2, 2020 at 9:28 PM Dilip Kumar wrote: > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > > > On Thu, Apr 2, 2020 at 6:18 PM Julien Rouhaud wrote: > > > > > > =# select query, calls, wal_bytes, wal_records, wal_num_fpw from > > > pg_stat_statements where query ilike '%create

Re: Online checksums verification in the backend

On Sat, 28 Mar 2020 at 21:19, Julien Rouhaud wrote: > > On Sat, Mar 28, 2020 at 12:28:27PM +0900, Masahiko Sawada wrote: > > On Wed, 18 Mar 2020 at 19:11, Julien Rouhaud wrote: > > > > > > v5 attached > > > > Thank you for updating the patch. I have some comments: > > Thanks a lot for the

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Fri, 3 Apr 2020 at 15:18, Andy Fan wrote: > > The updated patch should fixed all the issues. See the comments below for > more > information. > > On Tue, Mar 31, 2020 at 9:44 AM David Rowley wrote: >> >> + * can only guarantee the uniqueness without considering the null values. >> This >>

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 7:15 AM Kyotaro Horiguchi wrote: > > Hello. > > The v13 patch seems failing to apply on the master. > It is probably due to recent commit ed7a509571. I have briefly studied that and I think we should make this patch account for plan time WAL usage if any similar to what

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 8:14 AM Amit Kapila wrote: > > On Fri, Apr 3, 2020 at 6:37 AM Amit Kapila wrote: > > > > On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar wrote: > > > > > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila > > > wrote: > > > > > > > > 4. > > > > /* # of WAL full page image

Re: pgbench - add \aset to store results of a combined query

On Thu, Apr 02, 2020 at 03:58:50PM +0200, Fabien COELHO wrote: > Sure. I meant that the feature would make sense to write benchmark scripts > which would use aset and be able to act on the success or not of this aset, > not to resurrect it for a hidden coverage test. This could always be

Re: WAL usage calculation patch

On Fri, Apr 3, 2020 at 6:37 AM Amit Kapila wrote: > > On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar wrote: > > > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > > > > > 4. > > > /* # of WAL full page image generated */ > > > Can we change it to "/* # of WAL full page image records

Re: User Interface for WAL usage data

On Thu, Apr 2, 2020 at 12:05 PM Justin Pryzby wrote: > > On Thu, Apr 02, 2020 at 11:32:16AM +0530, Amit Kapila wrote: > > On Thu, Apr 2, 2020 at 11:28 AM Kyotaro Horiguchi > > wrote: > > > > > > At Thu, 2 Apr 2020 00:41:20 -0500, Justin Pryzby > > > wrote in > > > > Regarding > > > >

Re: BUG #16109: Postgres planning time is high across version (Expose buffer usage during planning in EXPLAIN)

On 2020/04/02 15:52, Fujii Masao wrote: On 2020/04/02 15:01, Julien Rouhaud wrote: On Thu, Apr 02, 2020 at 01:05:56PM +0900, Fujii Masao wrote: On 2020/04/02 3:47, Julien Rouhaud wrote: On Wed, Apr 1, 2020 at 7:51 PM Fujii Masao wrote: On 2020/03/31 10:31, Justin Pryzby wrote: On

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

>Some comments about the set_bit/get_bit parts. >I'm reading long_bytea_string_bug_fix_ver6_pg10.patch, but that >applies probably to the other files meant for the existing releases >(I think you could get away with only one patch for backpatching >and one patch for v13, and committers will sort

Re: Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”

Bryn Llewellyn writes: > The documentation in section “8.16.2. Constructing Composite Values” here: > https://www.postgresql.org/docs/11/rowtypes.html#ROWTYPES-IO-SYNTAX > The authoritative documentation for that is at 8.16.6

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

The updated patch should fixed all the issues. See the comments below for more information. On Tue, Mar 31, 2020 at 9:44 AM David Rowley wrote: > On Sun, 29 Mar 2020 at 20:50, Andy Fan wrote: > > Some other changes made in the new patch: > > 1. Fixed bug for UniqueKey calculation for OUTER

Syntax rules for a text value inside the literal for a user-defined type—doc section “8.16.2. Constructing Composite Values”

I’m using PostgreSQL Version 11.2. Try this: create type rt as (a text, b text); create table t(k serial primary key, r rt); insert into t(r) values ('("a","b")'), ('( "e" , "f" )'), ('( "g (h)" , "i, j" )'); select k, '>'||(r).a||'<' as a, '>'||(r).b||'<' as b from t order by k;

Re: WAL usage calculation patch

Hello. The v13 patch seems failing to apply on the master. At Fri, 3 Apr 2020 06:37:21 +0530, Amit Kapila wrote in > On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar wrote: > > > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > > > > > 4. > > > /* # of WAL full page image generated */ > >

Re: snapshot too old issues, first around wraparound and then more.

On Thu, Apr 2, 2020 at 5:17 PM Andres Freund wrote: > Since this is a feature that can result in wrong query results (and > quite possibly crashes / data corruption), I don't think we can just > leave this unfixed. But given the amount of code / infrastructure > changes required to get this into

Re: WAL usage calculation patch

On Thu, Apr 2, 2020 at 8:06 PM Dilip Kumar wrote: > > On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > > > 4. > > /* # of WAL full page image generated */ > > Can we change it to "/* # of WAL full page image records generated */"? > > IMHO, "# of WAL full-page image records" seems like the

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

On Thu, Apr 2, 2020 at 8:46 PM James Coleman wrote: > > On Thu, Apr 2, 2020 at 8:20 PM Tomas Vondra > wrote: > > > > Hi, > > > > Thanks, the v52 looks almost ready. I've been looking at the two or > > three things I mentioned, and I have a couple of comments. > > > > > > 1) /* XXX

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

On Thu, Apr 2, 2020 at 8:20 PM Tomas Vondra wrote: > > Hi, > > Thanks, the v52 looks almost ready. I've been looking at the two or > three things I mentioned, and I have a couple of comments. > > > 1) /* XXX comparison_cost shouldn't be 0? */ > > I'm not worried about this, because this is not

Re: src/test/regress/standby_schedule

Thomas Munro writes: > I guess no human or machine ever runs $SUBJECT, because when I tried > it while hunting down users of txid_XXX functions, it failed (see > end). To run it, you need a primary/standby pair, here 5441/5442, and > then: > PGPORT=5441 psql postgres -f sql/hs_primary_setup.sql

src/test/regress/standby_schedule

Hello, I guess no human or machine ever runs $SUBJECT, because when I tried it while hunting down users of txid_XXX functions, it failed (see end). To run it, you need a primary/standby pair, here 5441/5442, and then: PGPORT=5441 psql postgres -f sql/hs_primary_setup.sql PGPORT=5442

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

Hi, Thanks, the v52 looks almost ready. I've been looking at the two or three things I mentioned, and I have a couple of comments. 1) /* XXX comparison_cost shouldn't be 0? */ I'm not worried about this, because this is not really intriduced by this patch - create_sort_path has the same

Re: snapshot too old issues, first around wraparound and then more.

Hi, On 2020-04-01 12:02:18 -0400, Robert Haas wrote: > I have no objection to the idea that *if* the feature is hopelessly > broken, it should be removed. I don't think we have a real choice here at this point, at least for the back branches. Just about nothing around old_snapshot_threshold

Re: snapshot too old issues, first around wraparound and then more.

Hi, I just spend a good bit more time improving my snapshot patch, so it could work well with a fixed version of the old_snapshot_threshold feature. Mostly so there's no unnecessary dependency on the resolution of the issues in that patch. When testing my changes, for quite a while, I could not

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

David Rowley writes: > On Fri, 3 Apr 2020 at 04:46, Tom Lane wrote: >> Concretely, I suggest the attached, which replaces the autovac disables >> with adjusting partition boundaries so that the partitions contain >> different numbers of rows. > I've looked over this and I agree that it's a

Re: Datum values consistency within one query

Paul Ramsey writes: > Getting the datum value is really fast, so I can have a cache that > keeps the latest detoasted object around, and update it when the datum > changes, and store the cache information in the parent context. Like > so: Jeez, no, not like that. You're just testing a pointer.

Re: [PATCH] Fix for slow GIN index queries when "gin_fuzzy_search_limit" setting is relatively small for large tables

=?UTF-8?B?QWTDqQ==?= writes: >> It seems like what you're actually trying >> to accomplish is to ensure that entryLoadMoreItems's "stepright" path >> is taken, instead of re-descending the index from the root. > What I was primarily trying to do is make sure that when entryLoadMoreItems > is

Datum values consistency within one query

Imagine a function that was going to take a table of, say, images, and so something to them over and over, like: SELECT pixel_count(img), clr_name, img_name FROM images img CROSS JOIN colors clr When you run this function, you find that a great amount of time is being spend in the

Re: Add A Glossary

On Thu, Apr 02, 2020 at 07:09:32PM -0300, Alvaro Herrera wrote: > "partition" instead). If you (or anybody) have suggestions for the > definition of "client" and "session", I'm all ears. We already have Session: A Connection to the Database. I propose: Client: A host (or a process

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

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> Yeah, I'd noticed those on previous readings of the patch. They'd almost >> certainly fail on some of our older/smaller buildfarm members, so they're >> not getting committed, even if they didn't require

Re: Add A Glossary

On 2020-Apr-02, Corey Huinker wrote: > On Thu, Apr 2, 2020 at 8:44 AM Jürgen Purtz wrote: > > > +1 and many thanks to Alvaros edits. > > > > > I did some of the grunt work Alvaro alluded to in v6, and the results are > attached and they build, which means there are no invalid links. Thank you!

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

Tom Lane writes: > "Daniel Verite" writes: >> These 2 tests need to allocate big chunks of contiguous memory, so they >> might fail for lack of memory on tiny machines, and even when not failing, >> they're pretty slow to run. Are they worth the trouble? > > Yeah, I'd noticed those on previous

Re: Nicer error when connecting to standby with hot_standby=off

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:not tested I applied the patch to the latest master branch and run a test below.

Re: Should we add xid_current() or a int8->xid cast?

Hi, On 2020-04-02 14:26:41 -0700, Mark Dilger wrote: > Since Thomas's patch is really just focused on transitioning from txid > -> xid8, I think this conversation is a bit beyond scope for this > patch, except that "xid8" sounds an awful lot like the new type that > all user facing xid output

Re: Should we add xid_current() or a int8->xid cast?

> On Apr 2, 2020, at 2:13 PM, Andres Freund wrote: > > Hi, > > On 2020-04-02 11:47:32 -0700, Mark Dilger wrote: >> I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs >> as an internal implementation and storage detail only, but we still >> have user facing views that don't

Re: Should we add xid_current() or a int8->xid cast?

Hi, On 2020-04-02 11:47:32 -0700, Mark Dilger wrote: > I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs > as an internal implementation and storage detail only, but we still > have user facing views that don't treat it that way. Note that epochs are not really a thing

Re: Should we add xid_current() or a int8->xid cast?

On Thu, Apr 2, 2020 at 2:47 PM Mark Dilger wrote: > > > > > On Apr 2, 2020, at 11:01 AM, Andres Freund wrote: > > > >> > >> Hmm, for some reason I had it in my head that we would make these use an > >> "epoch/val" output format rather than raw uint64 values. > > > > Why would we do that? IMO the

Re: control max length of parameter values logged

Pushed with a bit of editorialization. Great, and thanks for the fixes! Best, Alex

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

On Fri, 3 Apr 2020 at 04:46, Tom Lane wrote: > > I wrote: > > I'd be inclined to undo what you did in favor of initializing the > > test tables to contain significantly different numbers of rows, > > because that would (a) achieve plan stability more directly, > > and (b) demonstrate that the

Re: backup manifests

On 4/2/20 3:47 PM, Andres Freund wrote: On 2020-04-02 15:42:48 -0400, Robert Haas wrote: I suspect I'm not doing quite what you had in mind here... thoughts? I have some ideas, but I think it's complicated enough that I'd not put it in the "pre commit path" for now. +1. These would be great

Re: Planning counters in pg_stat_statements (using pgss_store)

Fujii Masao-4 wrote > On 2020/04/01 18:19, Fujii Masao wrote: > > Finally I pushed the patch! > Many thanks for all involved in this patch! > > As a remaining TODO item, I'm thinking that the document would need to > be improved. For example, previously the query was not stored in pgss > when it

Re: snapshot too old issues, first around wraparound and then more.

On Thu, Apr 2, 2020 at 11:28 AM Peter Geoghegan wrote: > In conclusion, I share Andres' concerns here. There are glaring > problems with how we manipulate the data structure that controls the > effective horizon for pruning. Maybe they can be fixed while leaving > the code that manages the

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

"Daniel Verite" writes: > These 2 tests need to allocate big chunks of contiguous memory, so they > might fail for lack of memory on tiny machines, and even when not failing, > they're pretty slow to run. Are they worth the trouble? Yeah, I'd noticed those on previous readings of the patch.

Re: backup manifests

On 2020-04-02 15:42:48 -0400, Robert Haas wrote: > I suspect I'm not doing quite what you had in mind here... thoughts? I have some ideas, but I think it's complicated enough that I'd not put it in the "pre commit path" for now.

Re: backup manifests

On Thu, Apr 2, 2020 at 2:55 PM Robert Haas wrote: > On Thu, Apr 2, 2020 at 2:23 PM Andres Freund wrote: > > > That might make the window fairly wide on normal systems, but I'm not > > > sure about Raspberry Pi BF members or things running > > > CLOBBER_CACHE_ALWAYS/RECURSIVELY. I guess I could

Re: backup manifests

On Thu, Apr 2, 2020 at 3:26 PM David Steele wrote: > So, with the addition of the 0004 patch down-thread this looks > committable to me. Glad to hear it. Thank you. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Add A Glossary

On Thu, Apr 2, 2020 at 8:44 AM Jürgen Purtz wrote: > +1 and many thanks to Alvaros edits. > > I did some of the grunt work Alvaro alluded to in v6, and the results are attached and they build, which means there are no invalid links. Notes: * no definition wordings were changed * added a linkend

Re: backup manifests

On 4/2/20 1:04 PM, Robert Haas wrote: > There are still some things that not everybody is happy about. In particular, Stephen and David are unhappy about using CRC-32C as the default algorithm, but Andres and Noah both think it's a reasonable choice, even if not as robust as everybody will want.

Re: Should we add xid_current() or a int8->xid cast?

Andres Freund writes: > On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote: >> Hmm, for some reason I had it in my head that we would make these use an >> "epoch/val" output format rather than raw uint64 values. > Why would we do that? IMO the goal should be to reduce awareness of the >

Re: Proposal: Expose oldest xmin as SQL function for monitoring

Andres Freund writes: > On 2020-04-01 19:57:32 -0400, Tom Lane wrote: >> Agreed, but just knowing what the oldest xmin is doesn't help you >> find *where* it is. Maybe what we need is a view showing all of >> these potential sources of an old xmin. > +1. This would be extermely useful. It's a

Re: control max length of parameter values logged

Alexey Bashtanov writes: > Please see the new version attached. Pushed with a bit of editorialization. regards, tom lane

Re: backup manifests

On 2020-04-02 14:55:19 -0400, Robert Haas wrote: > > Yes, I am asking for something to be changed: I'd like the code that > > read()s the file when computing the checksum to add up how many bytes > > were read, and compare that to the size in the manifest. And if there's > > a difference report an

Re: control max length of parameter values logged

Alvaro Herrera writes: > More or less. If you don't add these chars, mbcliplen doesn't think > there's character there, so it ends up not adding the ellipsis. (I > don't remember why it has to be two chars rather than just one.) I think the idea is to be sure that there's a full multibyte

Re: Should we add xid_current() or a int8->xid cast?

> On Apr 2, 2020, at 11:01 AM, Andres Freund wrote: > >> >> Hmm, for some reason I had it in my head that we would make these use an >> "epoch/val" output format rather than raw uint64 values. > > Why would we do that? IMO the goal should be to reduce awareness of the > 32bitness of normal

Re: snapshot too old issues, first around wraparound and then more.

On Tue, Mar 31, 2020 at 11:40 PM Andres Freund wrote: > The problem, as far as I can tell, is that > oldSnapshotControl->head_timestamp appears to be intended to be the > oldest value in the ring. But we update it unconditionally in the "need > a new bucket, but it might not be the very next one"

Re: backup manifests

Hi, On 2020-04-02 14:16:27 -0400, Robert Haas wrote: > On Thu, Apr 2, 2020 at 1:23 PM Andres Freund wrote: > > I suspect its possible to control the timing by preventing the > > checkpoint at the end of recovery from completing within a relevant > > timeframe. I think configuring a large

Re: backup manifests

On Thu, Apr 2, 2020 at 1:23 PM Andres Freund wrote: > I suspect its possible to control the timing by preventing the > checkpoint at the end of recovery from completing within a relevant > timeframe. I think configuring a large checkpoint_timeout and using a > non-fast base backup ought to do the

Re: bad wal on replica / incorrect resource manager data checksum in record / zfs

Hi, On 2020-02-19 16:35:53 -0500, Alex Malek wrote: > We are having a reoccurring issue on 2 of our replicas where replication > stops due to this message: > "incorrect resource manager data checksum in record at ..." Could you show the *exact* log output please? Because this could temporarily

Re: Allow continuations in "pg_hba.conf" files

On 2020-04-01 10:25 p.m., Fabien COELHO wrote: Hello, FWIW, I don't think so. Generally a trailing backspace is an escape character for the following newline.  And '\ ' is a escaped space, which is usualy menas a space itself. In this case escape character doesn't work generally and I think

Re: Should we add xid_current() or a int8->xid cast?

Hi, On 2020-04-02 14:33:18 -0300, Alvaro Herrera wrote: > On 2020-Apr-02, Thomas Munro wrote: > > > On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro > > wrote: > > > * updated OIDs to avoid collisions > > > * added btequalimage to btree/xid8_ops > > > > Here's the version I'm planning to commit

Re: Proposal: Expose oldest xmin as SQL function for monitoring

Hi, On 2020-04-01 19:57:32 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Apr-01, Tom Lane wrote: > >> The fact that I had to use max(age(...)) in that sample query > >> hints at one reason: it's really hard to do arithmetic correctly > >> on raw XIDs. Dealing with wraparound is a

Re: bad wal on replica / incorrect resource manager data checksum in record / zfs

On Wed, Feb 19, 2020 at 4:35 PM Alex Malek wrote: > > Hello Postgres Hackers - > > We are having a reoccurring issue on 2 of our replicas where replication > stops due to this message: > "incorrect resource manager data checksum in record at ..." > This has been occurring on average once every 1

Re: Should we add xid_current() or a int8->xid cast?

On 2020-Apr-02, Thomas Munro wrote: > On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote: > > * updated OIDs to avoid collisions > > * added btequalimage to btree/xid8_ops > > Here's the version I'm planning to commit tomorrow, if no one objects. > Changes: > > * txid.c renamed to

Re: backup manifests

Hi, On 2020-04-02 13:04:45 -0400, Robert Haas wrote: > And here's another new patch set. After some experimentation, I was > able to manually test the timeline-switch-during-a-base-backup case > and found that it had bugs in both pg_validatebackup and the code I > added to the backend's

Re: control max length of parameter values logged

On 2020-Apr-02, Alexey Bashtanov wrote: > > > + if > > > (log_parameter_max_length_on_error > 0) > > > + { > > > + /* > > > +

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

movead...@highgo.ca wrote: > A little update for the patch, and patches for all stable avilable. Some comments about the set_bit/get_bit parts. I'm reading long_bytea_string_bug_fix_ver6_pg10.patch, but that applies probably to the other files meant for the existing releases (I think

Re: snapshot too old issues, first around wraparound and then more.

Hi, On April 2, 2020 9:36:32 AM PDT, Kevin Grittner wrote: >On Wed, Apr 1, 2020 at 7:17 PM Andres Freund >wrote: > >> FWIW, with autovacuum=off the query does not get killed until a >manual >> vacuum, nor if fewer rows are deleted and the table has previously >been >> vacuumed. >> >> The

Re: snapshot too old issues, first around wraparound and then more.

On Wed, Apr 1, 2020 at 7:17 PM Andres Freund wrote: > FWIW, with autovacuum=off the query does not get killed until a manual > vacuum, nor if fewer rows are deleted and the table has previously been > vacuumed. > > The vacuum in the second session isn't required. There just needs to be >

Re: Ltree syntax improvement

Nikita Glukhov writes: > Rebased patch attached. Thanks for rebasing! The cfbot's not very happy though: 4842ltxtquery_io.c: In function ‘makepol’: 4843ltxtquery_io.c:188:13: error: ‘escaped’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 4844 if (lenval - escaped

Re: Should we add xid_current() or a int8->xid cast?

> On Apr 2, 2020, at 9:06 AM, Mark Dilger wrote: > > ("xid8_current" is not exercised by name anywhere in the regression suite, > that I can see.) I spoke too soon. That's exercised in the new xid.sql test file. It didn't show up in my 'git diff', because it's new. Sorry about that. —

Re: Should we add xid_current() or a int8->xid cast?

> On Apr 1, 2020, at 8:21 PM, Thomas Munro wrote: > > On Sat, Mar 21, 2020 at 11:14 AM Thomas Munro wrote: >> * updated OIDs to avoid collisions >> * added btequalimage to btree/xid8_ops > > Here's the version I'm planning to commit tomorrow, if no one objects. > Changes: > > * txid.c

Re: snapshot too old issues, first around wraparound and then more.

On Wed, Apr 1, 2020 at 6:59 PM Andres Freund wrote: > index fetches will never even try to > detect that tuples it needs actually have already been pruned away. > I looked at this flavor of problem today and from what I saw: (1) This has been a problem all the way back to 9.6.0. (2) The

Re: WAL usage calculation patch

On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > On Thu, Apr 2, 2020 at 6:18 PM Julien Rouhaud wrote: > > > > =# select query, calls, wal_bytes, wal_records, wal_num_fpw from > > pg_stat_statements where query ilike '%create index%'; > > query |

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

I wrote: > I'd be inclined to undo what you did in favor of initializing the > test tables to contain significantly different numbers of rows, > because that would (a) achieve plan stability more directly, > and (b) demonstrate that the planner is actually ordering the > tables by cost correctly.

Re: WIP/PoC for parallel backup

On Thu, Apr 2, 2020 at 11:17 AM Asif Rehman wrote: >> Why would you need to do that? As long as the process where >> STOP_BACKUP can do the check, that seems good enough. > > Yes, but the user will get the error only after the STOP_BACKUP, not while > the backup is > in progress. So if the

Re: [HACKERS] WAL logging problem in 9.4.3?

On Wed, Apr 1, 2020 at 11:51 PM Noah Misch wrote: > I've translated the non-vote comments into estimated votes of -0.3, -0.6, > -0.4, +0.5, and -0.3. Hence, I revoke the plan to back-patch. FWIW, I also think that it would be better not to back-patch. The risk of back-patching is that this will

Re: WIP/PoC for parallel backup

On Thu, Apr 2, 2020 at 4:47 PM Robert Haas wrote: > On Fri, Mar 27, 2020 at 1:34 PM Asif Rehman > wrote: > > Yes, we are fetching a single file. However, SEND_FILES is still capable > of fetching multiple files in one > > go, that's why the name. > > I don't see why it should work that way. If

Re: Proposal: Expose oldest xmin as SQL function for monitoring

On Thu, Apr 2, 2020 at 12:13 AM Craig Ringer wrote: > > > > > On Thu, 2 Apr 2020 at 07:57, Tom Lane wrote: >> >> Alvaro Herrera writes: >> > On 2020-Apr-01, Tom Lane wrote: >> >> The fact that I had to use max(age(...)) in that sample query >> >> hints at one reason: it's really hard to do

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

David Rowley writes: > On Thu, 2 Apr 2020 at 16:13, Tom Lane wrote: >> Quite :-(. While it's too early to declare victory, we've seen no >> more failures of this ilk since 0936d1b6f, so it's sure looking like >> autovacuum did have something to do with it. > How about [1]? It seems related to

Re: WAL usage calculation patch

On Thu, Apr 02, 2020 at 06:40:51PM +0530, Amit Kapila wrote: > On Thu, Apr 2, 2020 at 6:18 PM Julien Rouhaud wrote: > > > > =# select query, calls, wal_bytes, wal_records, wal_num_fpw from > > pg_stat_statements where query ilike '%create index%'; > > query

Re: WAL usage calculation patch

On Thu, Apr 2, 2020 at 6:41 PM Amit Kapila wrote: > > On Thu, Apr 2, 2020 at 6:18 PM Julien Rouhaud wrote: > > > > =# select query, calls, wal_bytes, wal_records, wal_num_fpw from > > pg_stat_statements where query ilike '%create index%'; > > query |

Re: WIP/PoC for parallel backup

On Thu, Apr 2, 2020 at 9:46 AM Kashif Zeeshan < kashif.zees...@enterprisedb.com> wrote: > Does it fail to clean up the backup folder in all cases where the >> backup failed, or just in this case? >> > The cleanup is done in the cases I have seen so far with base > pg_basebackup functionality (not

Re: pgbench - add \aset to store results of a combined query

Michaël, ISTM that I submitted a patch to test whether a variable exists in pgbench, like available in psql (:{?var} I think), Not sure if improving the readability of the tests is a reason for this patch. So I would suggest to just live with relying on debug() for now to check that a

Re: WIP/PoC for parallel backup

On Thu, Apr 2, 2020 at 6:23 PM Robert Haas wrote: > On Thu, Apr 2, 2020 at 7:55 AM Kashif Zeeshan > wrote: > > Thanks alot Robert, > > In this case the backup folder was not being emptied as the backup was > failed, the cleanup should be done in this case too. > > Does it fail to clean up the

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

New conflict, rebased v9 attached. >From 26b98194d8add282158c65f6ac46c721ba80f498 Mon Sep 17 00:00:00 2001 From: Julien Rouhaud Date: Mon, 18 Mar 2019 18:55:50 +0100 Subject: [PATCH v9 1/2] Expose queryid in pg_stat_activity and log_line_prefix Similarly to other fields in pg_stat_activity, only

  1   2   >