Re: logical replication seems broken
> On 02/12/2021 1:51 PM Amit Kapila wrote:
>
>
> On Fri, Feb 12, 2021 at 6:04 PM Erik Rijkers wrote:
> >
> > Hello,
> >
> > I am seeing errors in replication in a test program that I've been running
> > for years with very little change (since 2017, really [1]).
Hi,
Here is a test program. Careful, it deletes stuff. And it will need some
changes:
I compile postgres server versions into directories like:
$HOME/pg_stuff/pg_installations/pgsql.$projectwhere project is a name
The attached script (logrep_cascade_bug.sh) assumes that two such compiled
versions are present (on my machine they are called HEAD and head0):
$HOME/pg_stuff/pg_installations/pgsql.HEAD --> git master as of today -
friday 12 febr 2021
$HOME/pg_stuff/pg_installations/pgsql.head0 --> 3063eb17593c so that's
from 11 febr, before the replication changes
In the test script, bash variables 'project' (and 'BIN') reflect my set up - so
should probably be changed.
The instance from today 12 february ('HEAD') has the bug:
it keeps endlessly waiting/looping with 'NOK' (=Not OK).
'Not OK' means: primary not identical to all replicas (replica1 seems ok, but
replica2 remains empty)
The instance from yesterday 11 february ('head0') is ok:
it finishes in 20 s after waiting/looping just 2 or 3 times
'ok' means: all replicas are identical to primary (as proven by the md5s).
That's all I have for now - I have no deeper idea about what exactly goes wrong.
I hope that helps, let me know when you cannot reproduce the problem.
Erik Rijkers
logrep_cascade_bug.sh
Description: application/shellscript
Re: logical replication seems broken
> On 2021.02.15. 12:31 Amit Kapila wrote: > On Mon, Feb 15, 2021 at 11:53 AM vignesh C wrote: > > On Sat, Feb 13, 2021 at 5:58 PM Erik Rijkers wrote: > > > I compiled just now a binary from HEAD, and a binary from HEAD+patch > > > HEAD is still broken; your patch rescues it, so yes, fixed. > > > Maybe a test (check or check-world) should be added to run a second > > > replica? (Assuming that would have caught this bug) > > > > > +1 for the idea of having a test for this. I have written a test for this. > > Thanks for the fix Amit, I could reproduce the issue without your fix > > and verified that the issue gets fixed with the patch you shared. > > Attached a patch for the same. Thoughts? > > > > I have slightly modified the comments in the test case to make things > clear. I am planning not to backpatch this because there is no way in > the core code to hit this prior to commit ce0fdbfe97 and we haven't > received any complaints so far. What do you think? My tests indeed run OK with this. (I haven't tested whether the newly added test actually tests for the problem that was there - I suppose one of you did that) Thanks! Erik Rijkers
Re: GROUP BY DISTINCT
> On 2021.02.21. 13:52 Vik Fearing wrote: > > Attached is a patch to implement this for PostgreSQL. > [] The changed line that gets stuffed into sql_features is missing a terminal value (to fill the 'comments' column). This line: '+T434 GROUP BY DISTINCT YES' (A tab at the end will do, I suppose; that's how I fixed the patch locally) Erik Rijkers
is cfbot's apply aging intentional?
Hi, I was looking at the 'Catalog version access' patch, by Vik Fearing. I saw a succesful build by the cfbot but I could not build one here. Only then did I notice that the last apply of the patches by cfbot was on 3769e11 which is the 3rd march, some 10 commits ago. There have been no new patches; one of the patches does not apply anymore. But it's not reported on the cfbot page. Is that the way it's supposed to be? I would have thought there was a regular schedule (hourly? 3-hourly? daily?) when all patches were taken for re-apply, and re-build, so that when a patch stops applying/building/whatever it can be seen on the cfbot page. Maybe I'm just mistaken, and the cfbot is supposed to only rebuild when there is a new patch. That would be kind-of logical too, although I for one would prefer a more continuous building. Can you tell me what is the intention at the moment? Is this a cfbot bug -- or just me being inadequately informed? ;) Thanks, Erik Rijkers
Re: is cfbot's apply aging intentional?
> On 2021.03.08. 01:30 Thomas Munro wrote: > > > On Sun, Mar 7, 2021 at 3:21 AM Julien Rouhaud wrote: > > On Sat, Mar 06, 2021 at 03:00:46PM +0100, e...@xs4all.nl wrote: > > > > > > I was looking at the 'Catalog version access' patch, by Vik Fearing. I > > > saw a succesful build by the cfbot but I > > > Can you tell me what is the intention at the moment? Is this a cfbot bug > > > -- or just me being inadequately informed? ;) > > > > The cfbot will periodically try to rebuild all open patches on the current > > (and > > next) commitfest, as the main goal is to quickly spot patches that have > > rotten. > > But it's running on free platforms so Thomas put some mechanisms to avoid > > Right, it currently tries to reassemble each branch every ~3 days. It > actually has a target of doing it every 2 days but it can't reach that Ah, I didn't realize the cycle could become 2-3 days. I assumed it to be much shorter. > But ... hmm, there must be something else going wrong for Erik here. > Vik's "Catalog version access" patches apply and compile and test fine Yes, you're right, I made an (unrelated) trivial mistake. I just wanted to make sure if that apply age of three days was intentional - I now understand it can happen. Thank you, Erik
Re: pg_amcheck contrib application
> On 2021.03.12. 19:10 Robert Haas wrote: > > > On Fri, Mar 12, 2021 at 11:41 AM Mark Dilger > wrote: > > In this next patch, your documentation patch has been applied, and the > > whole project has been relocated from contrib/pg_amcheck to > > src/bin/pg_amcheck. > > Committed that way with some small adjustments. Let's see what the > buildfarm thinks. > Hi, An output-formatting error, I think: I ran pg_amcheck against a 1.5 GB table: -- pg_amcheck --progress --on-error-stop --heapallindexed -vt myjsonfile100k pg_amcheck: including database: "testdb" pg_amcheck: in database "testdb": using amcheck version "1.3" in schema "public" 0/4 relations (0%) 0/187978 pages (0%) pg_amcheck: checking heap table "testdb"."public"."myjsonfile100k" pg_amcheck: checking btree index "testdb"."public"."myjsonfile100k_pkey" 2/4 relations (50%) 187977/187978 pages (99%), (testdb ) pg_amcheck: checking btree index "testdb"."pg_toast"."pg_toast_26110_index" 3/4 relations (75%) 187978/187978 pages (100%), (testdb ) pg_amcheck: checking heap table "testdb"."pg_toast"."pg_toast_26110" 4/4 relations (100%) 187978/187978 pages (100%) I think there is a formatting glitch in lines like: 2/4 relations (50%) 187977/187978 pages (99%), (testdb ) I suppose that last part should show up trimmed as '(testdb)', right? Thanks, Erik Rijkers
Re: 2021-02-11 release announcement draft
> On 02/08/2021 11:40 PM Jonathan S. Katz wrote: > > > Hi, > > Attached is a draft of the release announcement for the upcoming > 2021-02-11 cumulative update release. Please review for technical 'closes fixes' maybe better is: 'includes fixes' or 'closes bugs' 'also fixes over 80 bugs' Maybe drop the 'also'; those same 80 bugs have just been mentioned. Erik Rijkers
Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace
> On 2021.03.20. 19:48 Gilles Darold wrote:
>
> This is a new version of the patch that now implements all the XQUERY
> regexp functions as described in the standard, minus the differences of
> PostgerSQL regular expression explain in [1].
>
> The standard SQL describe functions like_regex(), occurrences_regex(),
> position_regex(), substring_regex() and translate_regex() which
> correspond to the commonly named functions regexp_like(),
> regexp_count(), regexp_instr(), regexp_substr() and regexp_replace() as
> reported by Chapman Flack in [2]. All these function are implemented in
> [v2-0001-xquery-regexp-functions.patch]
Hi,
Apply, compile and (world)check are fine. I haven't found errors in
functionality.
I went through the docs, and came up with these changes in func.sgml, and
pg_proc.dat.
Useful functions - thanks!
Erik Rijkers--- doc/src/sgml/func.sgml.orig 2021-03-21 03:59:37.884365465 +0100
+++ doc/src/sgml/func.sgml 2021-03-21 11:37:46.880644051 +0100
@@ -3106,7 +3106,7 @@
integer
-Return the number of times a pattern occurs for a match of a POSIX
+Returns the number of times a pattern occurs for a match of a POSIX
regular expression to the string; see
.
@@ -3125,11 +3125,11 @@
integer
- Return the position within string where the
+ Returns the position within string where the
match of a POSIX regular expression occurs. It returns an integer
indicating the beginning or ending position of the matched substring,
depending on the value of the returnopt argument
- (default beginning). If no match is found, then the function returns 0;
+ (default beginning). If no match is found the function returns 0;
see .
@@ -3147,12 +3147,12 @@
boolean
-Evaluate the existence of a match to a POSIX regular expression
+Evaluates the existence of a match to a POSIX regular expression
in string; see .
regexp_like('Hello'||chr(10)||'world', '^world$', 'm')
-3
+t
@@ -5773,7 +5773,7 @@
- The regexp_like function evaluate the existence of a match
+ The regexp_like function evaluates the existence of a match
to a POSIX regular expression in string; returns a boolean
resulting from matching a POSIX regular expression pattern to a string. It has
the syntax regexp_like(string,
@@ -5782,7 +5782,7 @@
from the beginning of string.
The flags parameter is an optional text string
containing zero or more single-letter flags that change the function's behavior.
- regexp_count accepts all the flags
+ regexp_like accepts all the flags
shown in .
This function is similar to regexp operator ~ when used without
flags and similar to operator ~* when
@@ -5792,9 +5792,9 @@
Some examples:
-SELECT 'found' FROM t1 WHERE regexp_like('Hello'||chr(10)||'world', '^world$', 'm');
- regexp_like
---
+SELECT 'found' FROM (values('Hello'||chr(10)||'world') as f(col) WHERE regexp_like(col, '^world$', 'm');
+ ?column?
+--
found
(1 row)
@@ -5814,7 +5814,7 @@
regexp_count accepts all the flags
shown in .
The g flag is forced internally to count all matches.
- This function returns 0 if there is no match or the number of match as
+ This function returns 0 if there is no match or the number of matches as
an integer.
@@ -5853,17 +5853,17 @@
the position of the character after the occurrence.
The flags parameter is an optional text string
containing zero or more single-letter flags that change the function's behavior.
- regexp_count accepts all the flags
+ regexp_instr accepts all the flags
shown in .
The g flag is forced internally to track all matches.
For a pattern with capture groups, group is an integer indicating
- which capture in pattern is the target of the function. A capture group is a part of the pattern
- enclosed in parentheses. Capture groups can be nested. They are numbered in order in which their
- left parentheses appear in pattern. If group is zero, then the position
+ which capture in pattern is the target of the function. A capture group is a part of the pattern
+ enclosed in parentheses. Capture groups can be nested. They are numbered in the order in which their
+ left parentheses appear in pattern. If group is zero, then the position
of the entire substring that matches the pattern is returned. If pattern
- does not have at least group capture group, the function returns zero.
+ does not have at least group capture groups, the function returns zero.
This function returns 0 if there is no match or the starting or ending position
- of match as an integer.
+ of a match as an integer.
