is pg_log_standby_snapshot() really needed?

Hi, I'm testing the ability to have a logical replica subscribed from a standby. Of course, I'm doing this in a laboratory with no activity so everything get stuck after creating the subscription (the main slot). This is clearly because every time it will create a temp slot for copy a table it

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On Wed, Jun 7, 2023 at 6:18 AM Tomas Vondra wrote: > > On 6/6/23 17:42, Tomas Vondra wrote: > > > > In investigated this a bit more, and the problem actually seems to be > more like this: > > 1) we create a new logical replication slot > > 2) while building the initial snapshot, we start with

Re: Let's make PostgreSQL multi-threaded

On Wed, Jun 7, 2023 at 7:32 AM Tom Lane wrote: > > Thomas Munro writes: > > ... My point is > > that we’re doing pretty unreasonable and inefficient contortions to > > develop new features -- we're not just happily chugging along without > > threads at no cost. > > Sure, but it's not like

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 11:30 PM Robert Haas wrote: > > On Tue, Jun 6, 2023 at 11:46 AM Heikki Linnakangas wrote: > > Bruce was worried about the loss of isolation that the separate address > > spaces gives, and Jeremy shared an anecdote on that. That is an > > objection to the idea itself, i.e.

Re: Improve join_search_one_level readibilty (one line change)

Thank you, Julien, for letting me know that cfbot doesn't test txt files. Much appreciated! v2-0001-Improve-left-deep-tree-dp-algorithm-s-readability.patch Description: Binary data

Re: Improve join_search_one_level readibilty (one line change)

Julien Rouhaud writes: > I'm glad I could help! Thanks for creating the cf entry. Note however that > the cfbot ignores files with a .txt extension (I don't think it's > documented but it will mostly handle files with diff, patch, gz(ip), tar > extensions IIRC, processing them as needed depending

Re: Improve join_search_one_level readibilty (one line change)

On Tue, 6 Jun 2023, 16:18 謝東霖, wrote: > Thank you to Julien Rouhaud and Tender Wang for the reviews. > > Julien's detailed guide has proven to be incredibly helpful, and I am > truly grateful for it. > Thank you so much for providing such valuable guidance! > > I have initiated a new commitfest:

Re: Assert failure of the cross-check for nullingrels

On Wed, Jun 7, 2023 at 4:22 AM Tom Lane wrote: > Alvaro Herrera writes: > > So, is this done? I see that you made other commits fixing related code > > several days after this email, but none seems to match the changes you > > posted in this patch; and also it's not clear to me that there's

Re: Let's make PostgreSQL multi-threaded

Thomas Munro writes: > ... My point is > that we’re doing pretty unreasonable and inefficient contortions to > develop new features -- we're not just happily chugging along without > threads at no cost. Sure, but it's not like chugging along *with* threads would be no-cost. Others have already

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

On Wed, Jun 7, 2023 at 5:44 AM Evan Jones wrote: > > On Tue, Jun 6, 2023 at 5:23 PM Peter Eisentraut wrote: >> >> This addresses only pg_regress. What about all the other test suites? >> Per the previous discussions, you'd need to patch up other places in a >> similar way, potentially

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

Evan Jones writes: > On Tue, Jun 6, 2023 at 5:23 PM Peter Eisentraut > wrote: >> This addresses only pg_regress. What about all the other test suites? > Are there instructions for how I can run these other test suites? configure with --enable-tap-tests, then do "make check-world". Also,

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On 6/6/23 17:42, Tomas Vondra wrote: > > > On 6/6/23 14:00, Alexander Lakhin wrote: >> Hello Tomas, >> >> 06.06.2023 12:56, Tomas Vondra wrote: >>> On 6/6/23 11:00, Alexander Lakhin wrote: Hello, ...> With the debug logging added inside AssertTXNLsnOrder() I see:

doc patch: note AttributeRelationId passed to FDW validator function

Hi Here: https://www.postgresql.org/docs/current/fdw-functions.html the enumeration of OIDs which might be passed as the FDW validator function's second argument omits "AttributeRelationId" (as passed when altering a foreign table's column options). Attached v1 patch adds this to this list

Re: Improving FTS for Greek

> On 7 Jun 2023, at 12:13 AM, Peter Eisentraut wrote: > > On 03.06.23 19:47, Florents Tselai wrote: >> There’s another previous relevant patch [0] but was never merged. I’ve >> included these stop words and added some more (info in README.md). >> For my personal projects looks like it yields

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 6:52 AM Andrew Dunstan wrote: > If we were starting out today we would probably choose a threaded > implementation. But moving to threaded now seems to me like a > multi-year-multi-person project with the prospect of years to come chasing > bugs and the prospect of

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

On Tue, Jun 6, 2023 at 5:23 PM Peter Eisentraut wrote: > This addresses only pg_regress. What about all the other test suites? > Per the previous discussions, you'd need to patch up other places in a > similar way, potentially everywhere system() is called. > Are there instructions for how I

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

On 06.06.23 16:24, Evan Jones wrote: On Mon, Jun 5, 2023 at 10:33 PM Tom Lane > wrote: > Note that this is a known issue Yeah.  We have attempted to work around this before, but failed to find a solution without more downsides than upsides.  I will be

Re: Improving FTS for Greek

On 03.06.23 19:47, Florents Tselai wrote: There’s another previous relevant patch [0] but was never merged. I’ve included these stop words and added some more (info in README.md). For my personal projects looks like it yields much better results. I’d like some feedback on the extension ;

Re: Order changes in PG16 since ICU introduction

> "Joe" == Joe Conway writes: > On 6/6/23 15:55, Tom Lane wrote: >> Robert Haas writes: >>> On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote: Also +1, except that I find "none" a rather confusing choice of name. There *is* a provider, it's just PG itself not either libc or ICU.

Re: Assert failure of the cross-check for nullingrels

Alvaro Herrera writes: > So, is this done? I see that you made other commits fixing related code > several days after this email, but none seems to match the changes you > posted in this patch; and also it's not clear to me that there's any > test case where this patch is expected to change

Re: Order changes in PG16 since ICU introduction

"Jonathan S. Katz" writes: > Since we're bikeshedding, "postgresql" or "builtin" could make it seem > to a (app) developer that these may be recommended options, as we're > trusting PostgreSQL to make the best choices for us. Granted, v16 is > (theoretically) defaulting to ICU, so that choice

Re: Let's make PostgreSQL multi-threaded

On Mon, 5 Jun 2023 at 10:52, Heikki Linnakangas wrote: > > I spoke with some folks at PGCon about making PostgreSQL multi-threaded, > so that the whole server runs in a single process, with multiple > threads. It has been discussed many times in the past, last thread on > pgsql-hackers was back

Re: Assert failure of the cross-check for nullingrels

On 2023-May-21, Tom Lane wrote: > Since we're hard up against the beta1 wrap deadline, I went ahead > and pushed the v5 patch. I doubt that it's perfect yet, but it's > a small change and demonstrably fixes the cases we know about. > > As I said in the commit message, the main knock I'd lay on

Re: Order changes in PG16 since ICU introduction

On 6/6/23 3:56 PM, Joe Conway wrote: On 6/6/23 15:55, Tom Lane wrote: Robert Haas writes: On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote: Also +1, except that I find "none" a rather confusing choice of name. There *is* a provider, it's just PG itself not either libc or ICU. I thought Joe's

Re: Cleaning up nbtree after logical decoding on standby work

On 2023-Jun-05, Peter Geoghegan wrote: > My current plan is to commit this later in the week, unless there are > further objections. Wednesday or possibly Thursday. I've added this as an open item for 16, with Peter and Andres as owners. -- Álvaro Herrera PostgreSQL Developer —

Re: Order changes in PG16 since ICU introduction

On 6/6/23 15:55, Tom Lane wrote: Robert Haas writes: On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote: Also +1, except that I find "none" a rather confusing choice of name. There *is* a provider, it's just PG itself not either libc or ICU. I thought Joe's suggestion of "internal" made more

Re: Order changes in PG16 since ICU introduction

Robert Haas writes: > On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote: >> Also +1, except that I find "none" a rather confusing choice of name. >> There *is* a provider, it's just PG itself not either libc or ICU. >> I thought Joe's suggestion of "internal" made more sense. > Or perhaps "builtin"

Re: could not extend file "base/5/3501" with FileFallocate(): Interrupted system call

On 2023-Apr-24, Andres Freund wrote: > A prototype of that approach is attached. I pushed the retry handling into the > pg_* routines where applicable. I guess we could add pg_* routines for > FileFallocate(), FilePrewarm() etc as well, but I didn't do that here. > > Christoph, could you verify

Re: Order changes in PG16 since ICU introduction

On Tue, Jun 6, 2023 at 3:25 PM Tom Lane wrote: > Joe Conway writes: > > On 6/6/23 15:18, Jeff Davis wrote: > >> The locale "C" is a special case, documented as a non-locale. So, if > >> LOCALE/--locale apply to ICU, then either ICU needs to handle locale > >> "C" in the expected way (v8 patch

Re: confusion about this commit "Revert "Skip redundant anti-wraparound vacuums""

On Mon, Jun 5, 2023 at 1:50 AM jiye wrote: > we can not get determinate test case as this issue reproduce only once, > and currently autovaccum can works as we using vacuum freeze for each > tables of each database. > > our client's application is real online bank business, and have serveral >

Re: pg_collation.collversion for C.UTF-8

On 6/6/23 15:23, Jeff Davis wrote: On Mon, 2023-06-05 at 19:43 +0200, Daniel Verite wrote: But in the meantime, personally I don't quite see why Postgres should start forcing C.UTF-8 to sort differently in the database than in the OS. I can see both points of view. It could be surprising to

Re: Order changes in PG16 since ICU introduction

Joe Conway writes: > On 6/6/23 15:18, Jeff Davis wrote: >> The locale "C" is a special case, documented as a non-locale. So, if >> LOCALE/--locale apply to ICU, then either ICU needs to handle locale >> "C" in the expected way (v8 patch series); or when we see locale "C" we >> need to somehow

Re: pg_collation.collversion for C.UTF-8

On Mon, 2023-06-05 at 19:43 +0200, Daniel Verite wrote: > But in the meantime, personally I don't quite see why Postgres should > start forcing C.UTF-8 to sort differently in the database than in the > OS. I can see both points of view. It could be surprising to users if C.UTF-8 does not sort

Re: Order changes in PG16 since ICU introduction

On 6/6/23 15:18, Jeff Davis wrote: On Tue, 2023-06-06 at 15:09 +0200, Daniel Verite wrote: FWIW I don't quite see how 0001 improve things or what problem it's trying to solve. The word "locale" is generic, so we need to make LOCALE/--locale apply to whatever provider is being used. If

Re: Order changes in PG16 since ICU introduction

On 6/6/23 15:15, Jeff Davis wrote: On Tue, 2023-06-06 at 14:11 -0400, Joe Conway wrote: This discussion makes me wonder (though probably too late for the v16 cycle) if we shouldn't treat "C" and "POSIX" locales to be a third provider, something like "internal". That's exactly what I did in

Re: Order changes in PG16 since ICU introduction

On Tue, 2023-06-06 at 14:11 -0400, Joe Conway wrote: > This discussion makes me wonder (though probably too late for the v16 > cycle) if we shouldn't treat "C" and "POSIX" locales to be a third > provider, something like "internal". That's exactly what I did in v6 of this series: I created a

Re: Mark a transaction uncommittable

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Hello It is one of those features that a handful of people would

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 2:00 PM Robert Haas wrote: > > I'm also not quite convinced that there's no long-term use case for > multi-process mode. Maybe you're right and there isn't, but that > amounts to arguing that every extension in the world will be happy to > run in a multi-threaded world

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 2:51 PM Kirk Wolak wrote: > I do wonder if we could add better threading within any given session/process > to get a hybrid? > [maybe this gets us closer to solving some of the problems incrementally?] I don't think it helps much -- if anything, I think that would be more

Re: Order changes in PG16 since ICU introduction

On 6/6/23 09:09, Daniel Verite wrote: Jeff Davis wrote: New patch series attached. I plan to commit 0001 and 0002 soon, unless there are objections. 0001 causes the "C" and "POSIX" locales to be treated with memcmp/pg_ascii semantics in ICU, just like in libc. We also considered a new

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 11:46 AM Heikki Linnakangas wrote: > Bruce was worried about the loss of isolation that the separate address > spaces gives, and Jeremy shared an anecdote on that. That is an > objection to the idea itself, i.e. even if transition was smooth, > bug-free and effortless, that

Re: Let's make PostgreSQL multi-threaded

On 06.06.2023 5:13 PM, Robert Haas wrote: On Tue, Jun 6, 2023 at 9:40 AM Robert Haas wrote: I'm not sure that there's a strong consensus, but I do think it's a good idea. Let me elaborate on this a bit. Not all databases have this problem, and PostgreSQL isn't going to be able to stop

Re: Add support for AT LOCAL

On Tue, 2023-06-06 at 04:24 -0400, Vik Fearing wrote: > > At a quick glance, it looks like you resolve "timezone" at the time > > the query is parsed.  Shouldn't the resolution happen at query > > execution time? > > current_setting(text) is stable, and my tests show that it is calculated > at

Re: Return value of pg_promote()

On Tue, 2023-06-06 at 16:35 +0530, Ashutosh Sharma wrote: > At present, pg_promote() returns true to the caller on successful > promotion of standby, however it returns false in multiple scenarios > which includes: > > 1) The SIGUSR1 signal could not be sent to the postmaster process. > 2) The

Re: Let's make PostgreSQL multi-threaded

On 2023-06-06 12:24, Heikki Linnakangas wrote: I'm afraid having multiple processes and JVMs doesn't help that. If you can escape the one JVM in one backend process, it's game over. So there's escape and there's escape, right? Java still prioritizes (and has, in fact, strengthened) barriers

Re: abi-compliance-checker

+abidiff = find_program('abidiff', native: false, required: false) +abidw = find_program('abidw', native: false, required: false) + +abidw_flags = [ + '--drop-undefined-syms', + '--no-architecture', + '--no-comp-dir-path', + '--no-elf-needed', + '--no-show-locs', + '--type-id-style', 'hash',

Re: ERROR: could not determine which collation to use for string comparison

On Tue, 2023-06-06 at 11:42 -0300, Rômulo Coutinho wrote: > We recently upgraded to Postgres 15.3. When running ANALYZE, we get the > following message: > ERROR:  could not determine which collation to use for string comparison > HINT:  Use the COLLATE clause to set the collation explicitly. > >

ERROR: could not determine which collation to use for string comparison

Hi, We recently upgraded to Postgres 15.3. When running ANALYZE, we get the following message: ERROR: could not determine which collation to use for string comparison HINT: Use the COLLATE clause to set the collation explicitly. We have never seen this before. Could this be a bug? Regards,

Re: Potential us of initialized memory in xlogrecovery.c

On 06/06/2023 10:24, Tristan Partin wrote: Hello, Today, I compiled the master branch of Postgres with the following GCC version: gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2) I got the following warning: [701/2058] Compiling C object

Re: Let's make PostgreSQL multi-threaded

On 06/06/2023 11:48, c...@anastigmatix.net wrote: And the devs of Java, in their immeasurable wisdom, have announced a "JDK Enhancement Proposal" (that's just what these things are called, don't blame Orwell), JEP 411[2][3], in which all of the Security Manager features that PL/Java relies on

Re: RFC: logical publication via inheritance root?

On 4/4/23 08:14, Jacob Champion wrote: > Yes, sorry -- after 062a84442, the architecture needs to change in a > way that I'm still working through. I've moved the patch to Waiting on > Author while I figure out the rebase. Okay -- that took longer than I wanted, but here's a rebased patchset that

Re: Let's make PostgreSQL multi-threaded

On 2023-06-06 08:06, Konstantin Knizhnik wrote: 7. It will be hard to support non-multithreaded PL languages (like python), but for example support of Java will be more natural and efficient. To this I say ... Hmm. Surely, the current situation with a JVM in each backend process (that calls

Re: Let's make PostgreSQL multi-threaded

On 06/06/2023 09:40, Robert Haas wrote: On Mon, Jun 5, 2023 at 10:52 AM Heikki Linnakangas wrote: I spoke with some folks at PGCon about making PostgreSQL multi-threaded, so that the whole server runs in a single process, with multiple threads. It has been discussed many times in the past,

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On 6/6/23 14:00, Alexander Lakhin wrote: > Hello Tomas, > > 06.06.2023 12:56, Tomas Vondra wrote: >> On 6/6/23 11:00, Alexander Lakhin wrote: >>> Hello, >>> ...> With the debug logging added inside AssertTXNLsnOrder() I see: >>> ctx->snapshot_builder->start_decoding_at: 209807224, >>>

Potential us of initialized memory in xlogrecovery.c

Hello, Today, I compiled the master branch of Postgres with the following GCC version: gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2) I got the following warning: [701/2058] Compiling C object src/backend/postgres_lib.a.p/access_transam_xlogrecovery.c.o In function ‘recoveryStopsAfter’,

Re: [PATCH] pg_regress.c: Fix "make check" on Mac OS X: Pass DYLD_LIBRARY_PATH

On Mon, Jun 5, 2023 at 10:33 PM Tom Lane wrote: > > Note that this is a known issue > Yeah. We have attempted to work around this before, but failed to find > a solution without more downsides than upsides. I will be interested > to look at this patch, but lack time for it right now. Anybody

Re: [PATCH] hstore: Fix parsing on Mac OS X: isspace() is locale specific

On Tue, Jun 6, 2023 at 7:37 AM Michael Paquier wrote: > Indeed. It looks like 9ae2661 missed this spot. > I didn't think to look for a previous fix, thanks for finding this commit id! I did a quick look at the places found with "git grep isspace" yesterday. I agree with the comment from

Re: Let's make PostgreSQL multi-threaded

On Tue, Jun 6, 2023 at 9:40 AM Robert Haas wrote: > I'm not sure that there's a strong consensus, but I do think it's a good idea. Let me elaborate on this a bit. I think one of PostgreSQL's bigger problems right now is that it doesn't scale as far as users would like. Beyond a couple of

Re: Let's make PostgreSQL multi-threaded

On Mon, Jun 5, 2023 at 10:52 AM Heikki Linnakangas wrote: > I spoke with some folks at PGCon about making PostgreSQL multi-threaded, > so that the whole server runs in a single process, with multiple > threads. It has been discussed many times in the past, last thread on > pgsql-hackers was back

Re: Implement generalized sub routine find_in_log for tap test

On Tue, 6 Jun 2023 at 09:36, Michael Paquier wrote: > > On Tue, Jun 06, 2023 at 08:05:49AM +0530, Amit Kapila wrote: > > Personally, I don't see any problem to do this refactoring for v16. > > However, sometimes, we do decide to backpatch refactoring in tests to > > avoid backpatch effort. I am

Re: Order changes in PG16 since ICU introduction

Jeff Davis wrote: > New patch series attached. I plan to commit 0001 and 0002 soon, unless > there are objections. > > 0001 causes the "C" and "POSIX" locales to be treated with > memcmp/pg_ascii semantics in ICU, just like in libc. We also > considered a new "none" provider, but it's

Re: Implement generalized sub routine find_in_log for tap test

On Tue, Jun 6, 2023 at 4:11 PM Michael Paquier wrote: > > On Tue, Jun 06, 2023 at 10:00:00AM +0530, Bharath Rupireddy wrote: > > +1 for deduplicating find_in_log. How about deduplicating advance_wal > > too so that 019_replslot_limit.pl, 033_replay_tsp_drops.pl, > >

Re: Let's make PostgreSQL multi-threaded

On 06.06.2023 12:07 AM, Jonah H. Harris wrote: On Mon, Jun 5, 2023 at 8:18 AM Tom Lane wrote: For the record, I think this will be a disaster.  There is far too much code that will get broken, largely silently, and much of it is not under our control. While I've long been

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

Hello Tomas, 06.06.2023 12:56, Tomas Vondra wrote: On 6/6/23 11:00, Alexander Lakhin wrote: Hello, ...> With the debug logging added inside AssertTXNLsnOrder() I see: ctx->snapshot_builder->start_decoding_at: 209807224, ctx->reader->EndRecPtr: 210043072,

Re: [PATCH] hstore: Fix parsing on Mac OS X: isspace() is locale specific

On Mon, Jun 05, 2023 at 11:26:56AM -0400, Evan Jones wrote: > This patch fixes a rare parsing bug with unicode characters on Mac OS X. > The problem is that isspace() on Mac OS X changes its behaviour with the > locale. Use scanner_isspace instead, which only returns true for ASCII > whitespace.

Re: Do we want a hashset type?

On 6/5/23 21:52, Joel Jacobson wrote: > On Mon, Jun 5, 2023, at 01:44, Tomas Vondra wrote: >> Anyway, I hacked together a trivial set backed by an open addressing >> hash table: >> >> https://github.com/tvondra/hashset >> >> It's super-basic, providing just some bare minimum of functions, but

Re: 回复：Fix missing initialization of delayChkptEnd

On Tue, Jun 06, 2023 at 03:13:14PM +0900, Kyotaro Horiguchi wrote: > After a quick check through the 14 tree, then compaing with the > corresponding parts of 15, it hit me that ProcArrayClearTransaction() > needs an assertion on the variable. Other than that, the patch looks > good to me. Yeah,

Re: Simplify pg_collation.collversion for Windows libc

On 06.06.23 03:21, Thomas Munro wrote: On Mon, Jun 5, 2023 at 12:56 PM Daniel Verite wrote: postgres=# select collversion,count(*) from pg_collation group by collversion; collversion | count ---+--- | 5 1539.5,1539.5 | 1457 (2 rows) According to [1]

Return value of pg_promote()

Hi All, At present, pg_promote() returns true to the caller on successful promotion of standby, however it returns false in multiple scenarios which includes: 1) The SIGUSR1 signal could not be sent to the postmaster process. 2) The postmaster died during standby promotion. 3) Standby couldn't

Re: Support logical replication of DDLs

On Mon, Jun 5, 2023 at 3:00 PM shveta malik wrote: > Few assorted comments: === 1. I see the following text in 0005 patch: "It supports most of ALTER TABLE command except some commands(DDL related to PARTITIONED TABLE ...) that are recently introduced but are not yet supported by

Re: Improve join_search_one_level readibilty (one line change)

Thank you to Julien Rouhaud and Tender Wang for the reviews. Julien's detailed guide has proven to be incredibly helpful, and I am truly grateful for it. Thank you so much for providing such valuable guidance! I have initiated a new commitfest: https://commitfest.postgresql.org/43/4346/

Re: Implement generalized sub routine find_in_log for tap test

On Tue, Jun 06, 2023 at 10:00:00AM +0530, Bharath Rupireddy wrote: > +1 for deduplicating find_in_log. How about deduplicating advance_wal > too so that 019_replslot_limit.pl, 033_replay_tsp_drops.pl, > 035_standby_logical_decoding.pl and 001_stream_rep.pl can benefit > immediately? As in a small

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

On 6/6/23 11:00, Alexander Lakhin wrote: > Hello, > ...> With the debug logging added inside AssertTXNLsnOrder() I see: > ctx->snapshot_builder->start_decoding_at: 209807224, > ctx->reader->EndRecPtr: 210043072, > SnapBuildXactNeedsSkip(ctx->snapshot_builder, ctx->reader->EndRecPtr): 0 > and

Re: Parallelize correlated subqueries that execute within each worker

On Mon, Jan 23, 2023 at 10:00 PM James Coleman wrote: > Which this patch we do in fact now see (as expected) rels with > non-empty lateral_relids showing up in generate_[useful_]gather_paths. > And the partial paths can now have non-empty required outer rels. I'm > not able to come up with a

Re: Support logical replication of DDLs

On Thu, 1 Jun 2023 at 07:42, Yu Shi (Fujitsu) wrote: > > On Wed, May 31, 2023 5:41 PM shveta malik wrote: > > > > PFA the set of patches consisting above changes. All the changes are > > made in 0008 patch. > > > > Apart from above changes, many partition attach/detach related tests > > are

Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)

Hello, 21.10.2022 08:49, Amit Kapila wrote: On Fri, Oct 21, 2022 at 8:01 AM Masahiko Sawada wrote: Thank you for the comment! I agreed with all comments and I've updated patches accordingly. Pushed after removing the test case from v11-13 branches as it is not relevant to those branches and

Re: Add support for AT LOCAL

On 6/6/23 03:56, Laurenz Albe wrote: On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote: The Standard defines time zone conversion as follows: ::=    [ ] ::=    AT ::= LOCAL    | TIME ZONE While looking at something else, I noticed we do not support AT LOCAL. The local

Re: Add support for AT LOCAL

On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote: > The Standard defines time zone conversion as follows: > > ::= >    [ ] > > ::= >    AT > > ::= > LOCAL >    | TIME ZONE > > > While looking at something else, I noticed we do not support AT LOCAL. > The local time zone is

Re: 回复：Fix missing initialization of delayChkptEnd

Good catch! At Tue, 06 Jun 2023 00:39:47 +0800, "蔡梦娟(玊于)" wrote in > Hi, all. I updated the patch for this bugfix, the previous one > missed the modification of function InitAuxiliaryProcess, please > check the new patch. After a quick check through the 14 tree, then compaing with the

RE: Support logical replication of DDLs

On Thur, June 1, 2023 at 23:42 vignesh C wrote: > On Wed, 31 May 2023 at 14:32, Wei Wang (Fujitsu) > wrote: > > ~~~ > > > > 2. Deparsed results of the partition table. > > When I run the following SQLs: > > ``` > > create table parent (a int primary key) partition by range (a); > > create table