How to understand "because you could
easily get into a situation where *none* of the nodes represent truth."?
In current design, when a user commits, it will first commit on primary,
and then is waiting for slave ack. if slaves and primary are splitted in
the network, then the user commit command
On 1/16/23 15:46, Rob Sargent wrote:
On 1/16/23 14:18, Ron wrote:
On 1/16/23 07:11, Laurenz Albe wrote:
On Mon, 2023-01-16 at 07:48 -0500, Fred Habash wrote:
This is a puzzle I have not been able to crack yet.
We have a single-page table with 28 rows that is purely read-only.
There isn't a w
On 1/16/23 14:18, Ron wrote:
On 1/16/23 07:11, Laurenz Albe wrote:
On Mon, 2023-01-16 at 07:48 -0500, Fred Habash wrote:
This is a puzzle I have not been able to crack yet.
We have a single-page table with 28 rows that is purely read-only.
There isn't a way in postgres to make a table RO, but
On 1/16/23 07:11, Laurenz Albe wrote:
On Mon, 2023-01-16 at 07:48 -0500, Fred Habash wrote:
This is a puzzle I have not been able to crack yet.
We have a single-page table with 28 rows that is purely read-only. There isn't
a way in postgres to make a table RO, but I say this with confidence be
On Sat, 14 Jan 2023, Tom Lane wrote:
Dimitrios Apostolou writes:
Please correct me if I'm wrong, as I'm a newcomer to PostgreSQL, but here
is how I understand things according to posts I've read, and classical
algorithms:
+ The Hash Join is fastest when one side fits in work_mem. Then on on
Hi,
not sure if this is known behavior.
Server version is 14.6 (Debian 14.6-1.pgdg110+1).
In a PITR setup I have these settings:
recovery_target_xid = '852381'
recovery_target_inclusive = 'false'
In the log file I see this message:
LOG: recovery stopping before commit of transaction 852381,
> On Jan 16, 2023, at 09:53, David G. Johnston
> wrote:
>
> I don't see any good way to say: "given this function signature, and the fact
> it cannot be found, what are the next closest function signatures that are
> present".
I can see a use-case for such functionality, though: A "did you
On Mon, Jan 16, 2023 at 10:42 AM arons wrote:
> Why the error happen is clear to me, in the example is also easy to see
> that the 7th parameter is the problem.
> But I'm searching a more general way to find easily which of the parameter
> is the problem.
> Suppose you have a function with 30 par
Hi
po 16. 1. 2023 v 18:42 odesílatel arons napsal:
> Why the error happen is clear to me, in the example is also easy to see
> that the 7th parameter is the problem.
> But I'm searching a more general way to find easily which of the parameter
> is the problem.
> Suppose you have a function with
Why the error happen is clear to me, in the example is also easy to see
that the 7th parameter is the problem.
But I'm searching a more general way to find easily which of the parameter
is the problem.
Suppose you have a function with 30 parameters with mixed sort of types.
They only way I know rig
On 1/16/23 08:17, Adrian Klaver wrote:
On 1/16/23 08:04, arons wrote:
Dear All,
I'm facing a general problem and I'm looking the best, fastest, way
how to identify the problem and solve it.
As example assume we have a function like that:
CREATE OR REPLACE FUNCTION testBinding01 (
p_in01 big
On 1/16/23 08:04, arons wrote:
Dear All,
I'm facing a general problem and I'm looking the best, fastest, way how
to identify the problem and solve it.
As example assume we have a function like that:
CREATE OR REPLACE FUNCTION testBinding01 (
p_in01 bigint,
p_in02 bigint,
p_in03 bigint,
p_
Dear All,
I'm facing a general problem and I'm looking the best, fastest, way how to
identify the problem and solve it.
As example assume we have a function like that:
CREATE OR REPLACE FUNCTION testBinding01 (
p_in01 bigint,
p_in02 bigint,
p_in03 bigint,
p_in04 bigint,
p_in05 bigint,
p_in0
On 1/16/23 08:26, Laurenz Albe wrote:
On Mon, 2023-01-16 at 09:30 +0100, Robert Sjöblom wrote:
We have a fleet of postgres 10 servers (1 primary, 2 replicas) that
we're now planning to upgrade. We've historically been forced to use the
same distro (centos7) and libc version, or rely on pg_dump/
Harmen writes:
> On Sat, Jan 14, 2023 at 11:23:07AM -0500, Tom Lane wrote:
>> If you are running a reasonably recent PG version you should be able to
>> fix that by setting up "extended statistics" on that pair of columns:
> CREATE STATISTICS dist4 (ndistinct) ON deleted, org_id FROM contactsbo
> The database relies on the data being consistent when it performs crash
> recovery.
> Imagine that a checkpoint is running while you take your snapshot. The
> checkpoint
> syncs a data file with a new row to disk. Then it writes a WAL record and
> updates
> the control file. Now imagine tha
> On 16/01/2023 13:48 CET Fred Habash wrote:
>
> This is a puzzle I have not been able to crack yet.
>
> We have a single-page table with 28 rows that is purely read-only. There isn't
> a way in postgres to make a table RO, but I say this with confidence because
> pg_stat_user_tables has always sh
On Fri, 2023-01-13 at 11:23 +, Zwettler Markus (OIZ) wrote:
> > -Ursprüngliche Nachricht-
> > Von: Laurenz Albe
> > Gesendet: Freitag, 13. Januar 2023 11:25
> > An: Zwettler Markus (OIZ) ; pgsql-
> > gene...@lists.postgresql.org
> > Betreff: Re: AW: [Extern] Re: postgres restore & need
On Mon, 2023-01-16 at 09:30 +0100, Robert Sjöblom wrote:
> We have a fleet of postgres 10 servers (1 primary, 2 replicas) that
> we're now planning to upgrade. We've historically been forced to use the
> same distro (centos7) and libc version, or rely on pg_dump/restore,
> across pg versions due
On Mon, 2023-01-16 at 08:41 +, HECTOR INGERTO wrote:
> I have understood I shall not do it, but could the technical details be
> discussed about
> why silent DB corruption can occur with non-atomical snapshots?
The database relies on the data being consistent when it performs crash
recovery.
On Mon, 2023-01-16 at 07:48 -0500, Fred Habash wrote:
> This is a puzzle I have not been able to crack yet.
>
> We have a single-page table with 28 rows that is purely read-only. There
> isn't a way in postgres to make a table RO, but I say this with confidence
> because pg_stat_user_tables has
This is a puzzle I have not been able to crack yet.
We have a single-page table with 28 rows that is purely read-only. There
isn't a way in postgres to make a table RO, but I say this with confidence
because pg_stat_user_tables has always showed 0 updates/deletes/inserts.
Furthermore, the schema
On Sat, Jan 14, 2023 at 11:23:07AM -0500, Tom Lane wrote:
> Harmen writes:
> > Works well enough. However, we now have an org_id which has > 10% of the
> > rows,
> > but only a handful rows where "deleted is null" matches (so the org has a
> > lot
> > of "deleted" contacts). The planner doesn't
I have understood I shall not do it, but could the technical details be
discussed about why silent DB corruption can occur with non-atomical snapshots?
24 matches
Mail list logo