On Sat, Nov 23, 2024 at 4:39 PM Bruce Momjian wrote:
> On Sat, Nov 23, 2024 at 03:24:47PM -0500, Ron Johnson wrote:
> > On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
> > [snip]
> >
> > I have to admit, for this question, we just point people to:
> >
> > https://www.postgr
On 11/23/24 16:20, Steeve Boulanger wrote:
Apologies for the late reply.
> I'm guessing shutting down Netdata did not stop the resets?
There was a hiccup yesterday, so I had to redo the test and wait until
today to see if there were any stats resets ... and NONE today!!
reset_status
Apologies for the late reply.
> I'm guessing shutting down Netdata did not stop the resets?
There was a hiccup yesterday, so I had to redo the test and wait until
today to see if there were any stats resets ... and NONE today!!
reset_status| cnt
+-
reset before t
On Sat, Nov 23, 2024 at 03:24:47PM -0500, Ron Johnson wrote:
> On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
> [snip]
>
> I have to admit, for this question, we just point people to:
>
> https://www.postgresql.org/support/versioning/
>
> and say bounce the database
On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
[snip]
> I have to admit, for this question, we just point people to:
>
> https://www.postgresql.org/support/versioning/
>
> and say bounce the database server and install the binaries. What I
> have never considered before, and I shou
Hello all!
I have a primary+replica PostgreSQL that I think work fine.
I created the replica's data directory using::
pg_basebackup -D $datadir -h $primary_host -U $replicauser \
--write-recovery-conf \
--create-slot --slot=$slotname
after creating the u
On 11/23/24 10:57, Bruce Momjian wrote:
On Sat, Nov 23, 2024 at 01:30:13PM -0500, Greg Sabino Mullane wrote:
On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
and say bounce the database server and install the binaries. What I
have never considered before, and I should have, is t
Greg Sabino Mullane writes:
> On Mon, Nov 11, 2024 at 6:23 AM David Lynam
> wrote:
>> Are there any plans or discussions about adding native support for
>> SQL:2011 temporal tables, so we don’t need extensions?
> No concrete plans I've heard of (but see below).
See this long-running thread:
ht
On Sat, Nov 23, 2024 at 01:30:13PM -0500, Greg Sabino Mullane wrote:
> On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
>
> and say bounce the database server and install the binaries. What I
> have never considered before, and I should have, is the complexity of
> doing this for
On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian wrote:
> and say bounce the database server and install the binaries. What I
> have never considered before, and I should have, is the complexity of
> doing this for many remote servers. Can we improve our guidance for
> these cases?
>
Hmm I'm not
On Mon, Nov 11, 2024 at 6:23 AM David Lynam
wrote:
> Are there any plans or discussions about adding native support for
> SQL:2011 temporal tables, so we don’t need extensions?
No concrete plans I've heard of (but see below). For the record, "so we
don't need extensions" is not a winning argume
On Fri, Nov 22, 2024 at 09:00:18AM +0100, Matthias Apitz wrote:
> El día viernes, noviembre 22, 2024 a las 05:52:34 +0100, Laurenz Albe
> escribió:
>
> > On Fri, 2024-11-22 at 10:01 +0530, Subhash Udata wrote:
> > > Currently, my environment is running PostgreSQL 15.0. I understand that
> > > ve
As a superuser, rename pg_stat_reset inside one of the commonly affected
databases:
alter function pg_stat_reset rename to
hey_stop_running_pg_stat_reset_already;
Then see who starts complaining. Additionally, your server log will get
helpful entries like this:
ERROR: function pg_stat_reset() d
On 11/23/24 05:16, Steeve Boulanger wrote:
Here (Ireland) we sometimes say "common-or-garden variety" It means a
normal, everyday variety. :-)
I'm afraid that my Irish dialect is limited to "sláinte" only ;-) In
any case, thanks for taking the time to help with this issue. I'm
still inves
On 11/23/24 05:16, Steeve Boulanger wrote:
Here (Ireland) we sometimes say "common-or-garden variety" It means a
normal, everyday variety. :-)
I'm afraid that my Irish dialect is limited to "sláinte" only ;-) In
any case, thanks for taking the time to help with this issue. I'm
still inves
Hi
so 23. 11. 2024 v 16:01 odesílatel napsal:
> I get get this same error
>
> syntax error at or near "$1" at character 15
>
> if I feed "const char *command" with the following texts.
>
> SET TIME ZONE $1
> SET TIME ZONE $1::TEXT
>
> For some reasons, I can not add quotes around $1 as follows.
I get get this same error
syntax error at or near "$1" at character 15
if I feed "const char *command" with the following texts.
SET TIME ZONE $1
SET TIME ZONE $1::TEXT
For some reasons, I can not add quotes around $1 as follows.
SET TIME ZONE '$1'
SET TIME ZONE '$1'::TEXT
Statements like "S
> Here (Ireland) we sometimes say "common-or-garden variety" It means a
> normal, everyday variety. :-)
I'm afraid that my Irish dialect is limited to "sláinte" only ;-) In
any case, thanks for taking the time to help with this issue. I'm
still investigating, but I think that calling the "gh
On 23/11/2024 13:06, Steeve Boulanger wrote:
> The above is some garden variety select?
Not 100% sure what the expression "garden variety select" means lol,
but I'll take a guess that it means an "select from an in-house
application" .. and yes it is.
Here (Ireland) we sometimes say "commo
> What is the [2] referring to?
Number of the log line for each session or process, starting at 1
> My guess is the difference in time it takes to log the action and set
> the log timestamp. Whereas the stats_reset value is the timestamp when
> the stats system actually did the reset.
Very plaus
Yes! Absolutely true. Thanks for the advice 🙂
On 2024-11-22 3:36 p.m., Ron Johnson wrote:
On Fri, Nov 22, 2024 at 3:07 PM Arbol One wrote:
Two different SELECT sql statement don't behave the same way.
The below sql statement produces the right output
SELECT nickname, password FROM
Oops!
I am putting too many hours in front of the computer, better take a break 😳
On 2024-11-22 3:12 p.m., David G. Johnston wrote:
On Fri, Nov 22, 2024 at 1:07 PM Arbol One wrote:
The below sql statement produces the right output
SELECT nickname, password FROM password WHERE id='09381
22 matches
Mail list logo
