Folks,
I am able to perfectly run pgbackrest with Single RepoServer works fine.
( Stanza My_Repo created successfully, info Check runs successfully
, backup perfectly works)
[ PG 16 server(10.1.2.202) , RHEL9.4, Pgbackrest 2.52.1) backup to remote
repo server1 (IP 10.x.4.242, ). works fi
On Sunday, April 27, 2025, Tim Starling wrote:
> thus allowing it to DWIM.
We intentionally choose (or, in any case have established) a SWYM approach
here.
Personally I’d be fine with the reduced helpfulness in trying to prevent
buggy queries in the interest of being more conforming with the b
Regarding upsert syntax.
psql (16.8 (Ubuntu 16.8-0ubuntu0.24.04.1), server 14.13 (Ubuntu
14.13-0ubuntu0.22.04.1))
=> CREATE TABLE t (k INTEGER, v INTEGER);
=> CREATE UNIQUE INDEX t_k ON t (k);
=> INSERT INTO t VALUES (1,1);
INSERT 0 1
=> INSERT INTO t VALUES (1,1) ON CONFLICT (k) DO UPDATE SET
Marcelo Fernandes writes:
> I would have expected that the "RESET lock_timeout;" inside a transaction
> would
> only reset the value of lock_timeout for that specific transaction. Or else,
> there would be an equivalent "RESET LOCAL lock_timeout;" to be used for that.
We don't seem to have bothe
Hi folks,
I have been using:
-- Setting the SESSION lock timeout to 10 seconds
SET lock_timeout = '10s';
-- Setting the TRANSACTION lock timeout to 20 seconds
BEGIN;
SET LOCAL lock_timeout = '20s';
COMMIT;
However, I have been caught by the behaviour of "RESET lock_timeout;" when
in
> On Apr 27, 2025, at 06:54, Ron Johnson wrote:
>
> I agree with him, though, that this a foot-gun: most table's aren't that
> UPDATE heavy.
There is plenty of precedent for GUCs that seem to be useful, but really should
never be touched except in the case of fairly uncommon workloads. Ho
On Sat, Apr 26, 2025 at 10:31 PM Marcelo Fernandes
wrote:
> Hi there,
>
> I have a scenario where virtually all user tables in the database will
> need to
> have a lower fill factor.
>
> It would have been handy to have a way to set this default, but as of now,
> I
> don't think the default can b
