Re: "Time of latest checkpoint" stays too old on both master and slave
On 06/30/2019 10:59 AM, rihad wrote: Damn. Sorry, and please disregard my post. The master server had the wrong time. Not wrong TZ, simply wrong time. $ date Sun Jun 30 08:34:52 +04 2019 while it's currently 10:58 There's a weird problem, even when the time is initially set by openntpd it keeps lagging by one second every few seconds: $ sudo /usr/local/etc/rc.d/openntpd restart Performing sanity check on openntpd configuration: configuration OK Stopping openntpd. Waiting for PIDS: 85893. Performing sanity check on openntpd configuration: configuration OK Starting openntpd. $ ssh good-server date; date Sun Jun 30 11:04:17 +04 2019 Sun Jun 30 11:04:17 +04 2019 $ ssh good-server date; date Sun Jun 30 11:04:25 +04 2019 Sun Jun 30 11:04:24 +04 2019 $ ssh good-server date; date Sun Jun 30 11:04:32 +04 2019 Sun Jun 30 11:04:31 +04 2019 $ ssh good-server date; date Sun Jun 30 11:04:39 +04 2019 Sun Jun 30 11:04:37 +04 2019 $ ssh good-server date; date Sun Jun 30 11:04:48 +04 2019 Sun Jun 30 11:04:45 +04 2019 Really weird. But this isn't a PG problem at all, just a server glitch maybe. sorry again.
Re: Postgresql 12 Beta2 Crashes for any Insert/Update
I've created a new database, and started to copy current data into it. it seems to work. it seems that the problem relates to upgrade process of database catalogs from Beta1 to Beta2. if the problem persists, it will investigate the stacktrace. Thanks On Thu, Jun 27, 2019 at 9:40 PM Peter Geoghegan wrote: > On Thu, Jun 27, 2019 at 1:28 AM Mohsen Bande > wrote: > > i have a working database in PG 12 Beta 1. today i upgraded it to Beta > 2. everything goes fine and server is up and running. but trying to > INSERT/UPDATE anything, server crashes: > > Is it possible for you to send us a stacktrace? > > > https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend > > Thanks > -- > Peter Geoghegan >
Re: Postgresql 12 Beta2 Crashes for any Insert/Update
After Investigating deeper, I found the root cause. Actually, the problem exists in certain tables, which i have created a trigger on them calling a function from a custom dynamic extension. the extension needs to rebuild (make && make install) against new PG development header files. On Sun, Jun 30, 2019 at 3:29 PM Mohsen Bande wrote: > I've created a new database, and started to copy current data into it. it > seems to work. > it seems that the problem relates to upgrade process of database catalogs > from Beta1 to Beta2. > if the problem persists, it will investigate the stacktrace. > Thanks > > On Thu, Jun 27, 2019 at 9:40 PM Peter Geoghegan wrote: > >> On Thu, Jun 27, 2019 at 1:28 AM Mohsen Bande >> wrote: >> > i have a working database in PG 12 Beta 1. today i upgraded it to Beta >> 2. everything goes fine and server is up and running. but trying to >> INSERT/UPDATE anything, server crashes: >> >> Is it possible for you to send us a stacktrace? >> >> >> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend >> >> Thanks >> -- >> Peter Geoghegan >> >
Re: "Time of latest checkpoint" stays too old on both master and slave
> "rihad" == rihad writes: rihad> There's a weird problem, even when the time is initially set by rihad> openntpd it keeps lagging by one second every few seconds: rihad> $ sudo /usr/local/etc/rc.d/openntpd restart What OS is this? I've seen this kind of thing with FreeBSD where the kernel timecounter source has been chosen badly (i.e. choosing TSC when the TSC isn't actually invariant enough). Forcing TSC not to be used fixes it. The configuration I've especially noticed it on is when running in a VM with a single virtual CPU. -- Andrew (irc:RhodiumToad)
Re: "Time of latest checkpoint" stays too old on both master and slave
On 06/30/2019 09:45 PM, Andrew Gierth wrote: "rihad" == rihad writes: rihad> There's a weird problem, even when the time is initially set by rihad> openntpd it keeps lagging by one second every few seconds: rihad> $ sudo /usr/local/etc/rc.d/openntpd restart What OS is this? I've seen this kind of thing with FreeBSD where the kernel timecounter source has been chosen badly (i.e. choosing TSC when the TSC isn't actually invariant enough). Forcing TSC not to be used fixes it. The configuration I've especially noticed it on is when running in a VM with a single virtual CPU. Exactly. You're right. It's on FreeBSD 11.2. After some googling earlier I changed kern.timecounter.hardware=HPET and solved the problem. The default chosen value TSC-low seems to misbehave for this box, although it works on others (running the same FreeBSD version).
