Re: Remove last traces of HPPA support

On Tue, Jul 2, 2024 at 5:56 AM Tom Lane wrote: > Done at commit edadeb0710. Here are some experimental patches to try out some ideas mentioned upthread, that are approximately unlocked by that cleanup. 1. We could get rid of --disable-spinlocks. It is hard to imagine a hypothetical new port th

Re: Removing unneeded self joins

On Mon, Jun 17, 2024 at 3:00 AM jian he wrote: > On Mon, May 6, 2024 at 11:55 PM Tom Lane wrote: > > > > Robert Haas writes: > > > I want to go on record right now as disagreeing with the plan proposed > > > in the commit message for the revert commit, namely, committing this > > > again early i

Re: Relation bulk write facility

On Tue, Jul 02, 2024 at 02:42:50PM +0300, Heikki Linnakangas wrote: > On 02/07/2024 02:24, Noah Misch wrote: > > On Tue, Jul 02, 2024 at 12:53:05AM +0300, Heikki Linnakangas wrote: > log_newpage_range() loads the pages to the buffer > cache and dirties them. That kinds of sucks actually, I wish it

Re: Cleaning up perl code

On Tue, Jul 02, 2024 at 01:55:25PM +0100, Dagfinn Ilmari Mannsåker wrote: > For clarity, I've rebased my addional unused-variable changes (except > the errcodes-related ones, see below) onto current master, and split it > into separate commits with detailed explaiations for each file file, see > at

RE: speed up a logical replica setup

Dear Amit, > IIUC, the problem is that the consistent_lsn value returned by > setup_publisher() is the "end +1" location of the required LSN whereas > the recovery_target_lsn used in wait_for_end_recovery() expects the > LSN value to be "start" location of required LSN. Yeah, right. It is same as

RE: speed up a logical replica setup

Dear Alexander and other hackers, > As a recent buildfarm failure [1] shows, that test addition introduced > new instability: > ### Starting node "node_s" > # Running: pg_ctl -w -D > /home/bf/bf-build/piculet/HEAD/pgsql.build/testrun/pg_basebackup/040_pg_c > reatesubscriber/data/t_040_pg_createsub

Re: Conflict Detection and Resolution

On Tue, Jul 2, 2024 at 2:40 PM shveta malik wrote: > > On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote: > > > > On Tue, Jun 18, 2024 at 3:29 PM shveta malik wrote: > > > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar > > > wrote: > > > > > > I tried to work out a few scenarios with this, where

Re: Conflict Detection and Resolution

On Wed, Jul 3, 2024 at 10:47 AM Dilip Kumar wrote: > > On Tue, Jul 2, 2024 at 2:40 PM shveta malik wrote: > > > > On Wed, Jun 19, 2024 at 1:52 PM Dilip Kumar wrote: > > > > > > On Tue, Jun 18, 2024 at 3:29 PM shveta malik > > > wrote: > > > > On Tue, Jun 18, 2024 at 11:34 AM Dilip Kumar > >

Re: What is a typical precision of gettimeofday()?

> On 2 Jul 2024, at 22:20, Tom Lane wrote: > > It sure looks like this is exact-to-the-nanosecond results, > since the modal values match the overall per-loop timing, > and there are no zero measurements. That’s a very interesting result, from the UUID POV! If time is almost always advancing,

Re: speed up a logical replica setup

On Wed, Jul 3, 2024 at 9:21 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Amit, > > > IIUC, the problem is that the consistent_lsn value returned by > > setup_publisher() is the "end +1" location of the required LSN whereas > > the recovery_target_lsn used in wait_for_end_recovery() expects the > > L

Re: Conflict Detection and Resolution

On Wed, Jul 3, 2024 at 11:00 AM shveta malik wrote: > > > Yes, I also think it should be independent of CDR. IMHO, it should be > > based on the user-configured maximum clock skew tolerance and can be > > independent of CDR. > > +1 > > > IIUC we would make the remote apply wait just > > before co

Re: Incorrect Assert in BufFileSize()?

On Fri, 17 May 2024 at 19:19, David Rowley wrote: > > On Thu, 16 May 2024 at 07:20, Peter Geoghegan wrote: > > Notice that comments above BufFileSize() say "Return the current > > fileset based BufFile size". There are numerous identical assertions > > at the start of several other functions with

Re: speed up a logical replica setup

On Wed, Jul 3, 2024 at 11:27 AM Amit Kapila wrote: > > > Do you have any other idea? > > > > The other idea could be that we use the minimum restart_lsn of all the > slots created by this tool as a consistent_lsn. We can probably get > that value by using pg_get_replication_slots() but this idea n

Re: speed up a logical replica setup

On Wed, Jul 3, 2024 at 10:42 AM Hayato Kuroda (Fujitsu) wrote: > > Based on that, I considered a scenario why the slot could not be synchronized. > I felt this was not caused by the pg_createsubscriber. > > 1. At initial stage, the xmin of the physical slot is 743, and nextXid of the >primary

<    1   2