Hi Alexander,
On Mon, 4 Dec 2023 at 07:22, Alexander Korotkov
wrote:
>
>
> Now, I think this looks good. I'm going to push this if no objections.
After this commit, I began seeing an unexpected ERROR - see this bug-report.
https://www.postgresql.org/message-id/18852-fb75b88160678f78%40postgresq
Hi,
Thanks for taking a look at the patch, and for your feedback.
On Wed, 5 Mar 2025 at 03:22, Fujii Masao
wrote:
> On 2025/02/16 16:05, Robins Tharakan wrote:
> > This patch introduces a new function pg_accept_connections_start_time().
>
Shouldn't this function also handle
ons_start_time | pg_postmaster_start_time
--+--
2025-02-16 13:57:52.914587+10:30 | 2025-02-16 11:40:37.351776+10:30
(1 row)
```
From 7521d666ce66347f894acf435d67ea69a6ecc677 Mon Sep 17 00:00:00 2001
From: Robins Tharakan
Date: Fri,
s
From fd8c79cf387c1d2ce767314865e4f471a4eea81c Mon Sep 17 00:00:00 2001
From: Robins Tharakan
Date: Sat, 15 Feb 2025 21:09:17 +1030
Subject: [PATCH v1] Add tab completion for ALTER DATABASE RESET
Currently tab completion for ALTER DATABASE RESET shows a list
of all vars that could be set on a dat
On Sat, 25 Jan 2025 at 11:57, Andrew Dunstan wrote:
> On 2025-01-24 Fr 7:50 PM, Andrew Dunstan wrote:
> > Here's the hot fix (which passed my test with a directory with pgsql
> > in its path):
>
> >
> https://github.com/PGBuildFarm/client-code/commit/f6c6dd52d2959814452454890fb9838429c5c3e8
>
>
On Sat, 25 Jan 2025 at 10:11, Tom Lane wrote:
> Yeah, that's about what I expected. As a workaround until Andrew
> updates the BF client, you could do
>
> - $libdir = "$tmp_loc/lib/postgresql";
> + $libdir = "$tmp_loc/lib";
>
> at about line 429 of PGBuild/Utils.pm
>
On Sat, 25 Jan 2025 at 08:59, Tom Lane wrote:
> alligator and lapwing are not reporting the
> relevant log file, but what we do see is an install failure that
> could well be down to a compile failure.
>
You're probably right about that.
This is what I see in the install.log
(/home/postgres/proj
On Tue, 14 Jan 2025 at 12:32, Tom Lane wrote:
> Robins Tharakan writes:
> > The error seems to be around "annobin.so" and so it may be about how
> > gcc is being compiled (not sure). While I figure out if GCC compilation
> > needs work, I thought to bring it u
Hi Alexander,
On Sun, 22 Dec 2024 at 17:57, Robins Tharakan wrote:
>
> So if that's a key reason here, then probably by this time next week
things should
> settle down. I've begun setting it correctly (2 done with a few more to
go) - although
> given that some machines
On Thu, 9 Jan 2025 at 15:30, Alexander Lakhin wrote:
>
> Maybe you could try to reproduce such failures without buildfarm client,
just
> by running select_parallel, for example, with the attached patch applied.
> I mean running `make check` with parallel_schedule like:
> ...
> Or
> TESTS="test_set
Hi Alexander,
Thanks for collating this list.
I'll try to add as much as I know, in hopes that it helps.
On Sun, 22 Dec 2024 at 16:30, Alexander Lakhin wrote:
> I'd like to bring your attention to multiple buildfarm failures, which
> occurred this month, on master only, caused by "could not ope
On Tue, 17 Dec 2024 at 16:59, Michael Paquier wrote:
> +1. Robins, feel free to ping me directly if you need help with this
> host.
>
Much appreciated Michael. Thankfully the new client worked without much
hiccup
(once it got the correct config file).
This is an old instance and IIRC gcc 7.3.1
Hi,
On Thu, 4 Apr 2024 at 05:42, Daniel Gustafsson wrote:
>
> massasauga and snakefly run the ssl_passphrase_callback-check test but
> none of
> these run the ssl-check tests AFAICT, so we have very low coverage as is.
> The
> fact that very few animals run the ssl tests is a pet peeve of mine,
ROLE
postgres=# \drds
Did not find any settings.
Applies on master (b6612aedc53a6) / make check successful.
-
Robins Tharakan
Amazon Web Services
v1-0001-Add-tab-completion-for-ALTER-USER-RESET.patch
Description: Binary data
On Sun, 23 Jun 2024 at 22:30, Alexander Lakhin wrote:
> Unfortunately, the buildfarm log doesn't contain regress_log_002_limits,
> but I managed to reproduce the failure on that my device, when it's storage
> as slow as:
> $ dd if=/dev/zero of=./test count=1024 oflag=dsync bs=128k
> 1024+0 recor
On Sat, 22 Jun 2024 at 18:30, Alexander Lakhin wrote:
> So it doesn't seem impossible for this operation to last for more than two
> minutes.
>
> The facts that SyncDataDirectory() is executed between these two messages
> logged, 008_fsm_truncation is the only test which turns fsync on, and we
>
On Tue, 14 May 2024 at 08:55, David Rowley wrote:
> I've not seen any recent failures from Parula that relate to this
> issue. The last one seems to have been about 4 weeks ago.
>
> I'm now wondering if it's time to revert the debugging code added in
> 1db689715. Does anyone think differently?
On Mon, 15 Apr 2024 at 16:02, Tom Lane wrote:
> David Rowley writes:
> > If GetNowFloat() somehow was returning a negative number then we could
> > end up with a large delay. But if gettimeofday() was so badly broken
> > then wouldn't there be some evidence of this in the log timestamps on
> > f
On Mon, 15 Apr 2024 at 14:55, David Rowley wrote:
> If GetNowFloat() somehow was returning a negative number then we could
> end up with a large delay. But if gettimeofday() was so badly broken
> then wouldn't there be some evidence of this in the log timestamps on
> failing runs?
3 things stand
On Sun, 14 Apr 2024 at 00:12, Tom Lane wrote:
> If we were only supposed to sleep 0.1 seconds, how is it waiting
> for 60 ms (and, presumably, repeating that)? The logic in
> pg_sleep is pretty simple, and it's hard to think of anything except
> the system clock jumping (far) backwards that w
On Mon, 8 Apr 2024 at 21:25, Robins Tharakan wrote:
>
>
> I'll keep an eye on this instance more often for the next few days.
> (Let me know if I could capture more if a run gets stuck again)
HEAD is stuck again on pg_sleep(), no CPU for the past hour or so.
Stack trace seems
On Wed, 10 Apr 2024 at 10:24, David Rowley wrote:
>
> Master failed today for the first time since the compiler upgrade.
> Again reltuples == 48.
Here's what I can add over the past few days:
- Almost all failures are either reltuples=48 or SIGABRTs
- Almost all SIGABRTs are DDLs - CREATE INDEX /
On Wed, 10 Apr 2024 at 10:24, David Rowley wrote:
> Master failed today for the first time since the compiler upgrade.
> Again reltuples == 48.
>From the buildfarm members page, parula seems to be the only aarch64 + gcc
13.2
combination today, and then I suspect whether this is about gcc v13.2
ma
On Tue, 2 Apr 2024 at 15:01, Tom Lane wrote:
> "Tharakan, Robins" writes:
> > So although HEAD ran fine, but I saw multiple failures (v12, v13, v16)
all of which passed on subsequent-tries,
> > of which some were even"signal 6: Aborted".
>
> Ugh...
parula didn't send any reports to buildfarm fo
On Thu, 28 Dec 2023 at 01:48, Tom Lane wrote:
> Robins Tharakan writes:
> > Applying all 4 patches, I also see good performance improvement.
> > With more Large Objects, although pg_dump improved significantly,
> > pg_restore is now comfortably an order of magnitude faste
fe-connect.c:4076
#4 0x7fb7bc097c97 in closePGconn (conn=0x55b191aa9380)
at fe-connect.c:4096
#5 0x7fb7bc097d55 in PQfinish (conn=0x55b191aa9380) at fe-connect.c:4134
#6 0x7fb7bc14a42b in libpqsrv_disconnect (conn=0x55b191aa9380)
at ../../src/include/libpq/libpq-be-fe-helpers.h:117
#7 0x7fb7bc14adf1 in dblink_disconnect (fcinfo=0x55b193894f00)
at dblink.c:357
Thanks to SQLSmith for helping with this find.
-
Robins Tharakan
Amazon Web Services
he above use-case. Thanks to SQLSmith
for indirectly leading me to this scenario.
-
Robins Tharakan
Amazon Web Services
Patch applied to commit - 80d690721973f6a031143a24a34b78a0225101a2
SQL repro script
CREATE EXTENSION IF NOT EXISTS pg_trgm;
set statement_timeout = '1s&
ontrib/pg_prewarm/autoprewarm.c
@@ -82,7 +82,7 @@ typedef struct AutoPrewarmSharedState
int prewarmed_blocks;
} AutoPrewarmSharedState;
-void autoprewarm_main(Datum main_arg);
+PGDLLEXPORT void autoprewarm_main(Datum main_arg);
void autoprewarm_database_main(Datum main_arg);
PG_FUNCTION_INFO
544
#25 0x55bf9fb52e93 in BackendRun (port=0x55bfa19218a0) at postmaster.c:4504
#26 0x55bf9fb52778 in BackendStartup (port=0x55bfa19218a0) at
postmaster.c:4232
#27 0x55bf9fb4ea5e in ServerLoop () at postmaster.c:1806
#28 0x000055bf9fb4e1f7 in PostmasterMain (argc=3, argv=0x55bfa18e9830)
at postmaster.c:1478
#29 0x55bf9fa3f864 in main (argc=3, argv=0x55bfa18e9830) at main.c:202
-
Robins Tharakan
Amazon Web Services
On Fri, 9 Apr 2021 at 16:12, Thomas Munro wrote:
> From your description it sounds like signals are not arriving at all,
> rather than some more complicated race. Let's go back to basics...
> what does the attached program print for you? I see:
>
> tmunro@x1:~/junk$ cc test-signalfd.c
> tmunro@x
r try out other options if required).
On Wed, 7 Apr 2021 at 21:49, Andrew Dunstan wrote:
> On 4/7/21 2:16 AM, Thomas Munro wrote:
> > On Wed, Apr 7, 2021 at 5:44 PM Robins Tharakan
wrote:
> >> Bichir's been stuck for the past month and is unable to run regression
tests since 6a
Hi Thomas,
Thanks for taking a look at this promptly.
On Wed, 7 Apr 2021 at 16:17, Thomas Munro wrote:
> On Wed, Apr 7, 2021 at 5:44 PM Robins Tharakan wrote:
> > It is interesting that that commit's a month old and probably no other
client has complained since, but diving in,
Hi,
Bichir's been stuck for the past month and is unable to run regression
tests since 6a2a70a02018d6362f9841cc2f499cc45405e86b.
It is interesting that that commit's a month old and probably no other
client has complained since, but diving in, I can see that it's been unable
to even start regress
king both References and In-reply-to headers.
>
Thanks for highlighting the cause here. Hopefully switching mail clients
would help.
-
Robins Tharakan
On Fri, 12 Jul 2019 at 14:04, Michael Paquier wrote:
> On Fri, Jul 12, 2019 at 01:42:59PM +1000, Robins Tharakan wrote:
> So 2019b has been released on the 1st of July. Usually tzdata updates
> happen just before a minor release, so this would get pulled in at the
> beginning of A
Hi,
The 2019b DST update [1] disables DST for Brazil. This would take effect
starting November 2019. The last DST update in Postgres was 2019a in v11.3
(since this update came in after the recent-most Postgres release).
Since a ~3 month release cycle may be too close for some users, are there
any
On 9 December 2017 at 16:11, Magnus Hagander wrote:
>
>
> Thanks, fixed for the report.
>
>
Thanks Magnus.
However, although it was backpatched correctly, looks like the fix on
master missed out identity.out related fix.
Ref:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/
Hi,
Looks like a minor typo in the recent commit.
s/identify/identity/
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a2c6cf36608e10aa223fef49323b5feba344bfcf
-
robins | mobile
38 matches
Mail list logo
