-2 should be documented, other than that it looks
good to me.
I'll accept the new semantics, but they don't make me happy. People are
used to -1 meaning "use the GUC value instead".
I still don't see why we need that. Contrary to Andres' opinion, I don't
think that disabling a parameter by setting it to a value high enough that
it does not take effect is a bad thing.
I won't put up a fight though.
Yours,
Laurenz Albe
On Sat, 2020-03-28 at 11:59 +1300, David Rowley wrote:
> On Fri, 27 Mar 2020 at 22:40, Laurenz Albe wrote:
> > The new meaning of -2 should be documented, other than that it looks
> > good to me.
>
> But the users don't need to know anything about -2. It's not p
On Sat, 2020-03-28 at 19:21 +1300, David Rowley wrote:
> Thank you. Pushed.
Thanks for your efforts on this, and thanks for working on the fallout.
How can it be that even after an explicit VACUUM, this patch can cause
unstable regression test results?
Yours,
Laurenz Albe
ence was trying to
improve
things, but enough obstacles surfaced that it didn't make it.
It is less trivial that it looks at first glance.
Yours,
Laurenz Albe
ould say "It represents the absence of *a definite* value."
Usually it is better to think of NULL as "unknown".
- Function
I don't know if "transformation of data" describes it well.
Quite a lot of functions in PostgreSQL have side effects.
How about:
Procedural code stored in the database that can be used in SQL statements.
Yours,
Laurenz Albe
e used to provide stricter permission
+checking to the underlying tables than by default.
Since you are talking about use cases here, RLS might deserve a mention.
--- a/src/backend/access/common/reloptions.c
+++ b/src/backend/access/common/reloptions.c
+ {
+ {
+ "security_invoker",
+ "View subquery in invoked within the current security context.",
+ RELOPT_KIND_VIEW,
+ AccessExclusiveLock
+ },
+ false
+ },
That doesn't seem to be proper English.
Yours,
Laurenz Albe
u suggest instead? pg_stat_all_tables.n_live_tup?
Yours,
Laurenz Albe
ss_rls_bob;
DROP USER IF EXISTS regress_rls_carol;
DROP USER IF EXISTS regress_rls_dave;
+DROP USER IF EXISTS regress_rls_grace;
But the name has to start with "e"!
I also see no reason to split a small patch like this into three parts.
In the attached, I dealt with the above and
security
> definer and security invoker views - but this would be a big breaking
> change, which I don't think is acceptable.
I agree that changing the current behavior is not acceptable.
I guess more documentation how this works would be a good idea.
Not sure if this is the job of this patch, but since it exposes this
in new ways, it might as well clarify how all this works.
Yours,
Laurenz Albe
hat USAGE privileges on schemas are not
checked
+when referencing the underlying base relations, even if they are part of a
+different schema.
"referencing" is a bit unclear.
Perhaps "when checking permissions on the underlying base relations".
Otherwise, this looks good!
Yours,
Laurenz Albe
On Tue, 2022-02-15 at 16:07 +0100, walt...@technowledgy.de wrote:
> Laurenz Albe:
> > > I converted the option to run_as_owner=true|false in the attached v7.
> > > It now definitely seems like the right way to move forward and getting
> > > more feedback.
> &
better to read. I
> wouldn't associate that with CHECK OPTION either. +1
Here is a new version, with improved documentation and the option renamed
to "check_permissions_owner". I just prefer the shorter form.
Yours,
Laurenz Albe
From e31ea3de2838dcfdc8c364fc08e54e5d37f00882 Mon
eak
configured with "autovacuum_vacuum_cost_delay". Reduce that parameter for more
autovacuum speed.
Yours,
Laurenz Albe
Row-level read and write locks are recorded directly in locked
> +rows and can be inspected using the
> +extension. Row-level read locks might also require the assignment
> +of multixact IDs (mxid). Mxids are recorded in
> +the pg_multixact directory.
"are recorded directly in *the* locked rows"
I think the mention of multixacts should link to
. Again, I would not
specifically mention the directory, since it is already described in
"storage.sgml", but I have no strong optinion there.
> +
> +
> + Subtransactions
> +The word subtransaction is often abbreviated as
> +subxact.
I'd use , not .
> +If a subtransaction is assigned a non-virtual transaction ID,
> +its transaction ID is referred to as a subxid.
Again, I would use , since we don't "subxid"
elsewhere.
+ Up to
+64 open subxids are cached in shared memory for each backend; after
+that point, the overhead increases significantly since we must look
+up subxid entries in pg_subtrans.
Comma before "since". Perhaps you should mention that this means disk I/O.
Yours,
Laurenz Albe
On Mon, 2022-11-07 at 23:04 +0100, Laurenz Albe wrote:
> On Sat, 2022-11-05 at 10:08 +, Simon Riggs wrote:
> > Agreed; new compilation patch attached, including mine and then
> > Robert's suggested rewordings.
>
> Thanks. There is clearly a lot of usefule info
ctions. How is that?
It is better. Did you take my suggestions from [1] into account in your
latest cumulative patch in [2]? Otherwise, it will be difficult to
integrate both.
Yours,
Laurenz Albe
[1]:
https://postgr.es/m/3603e6e85544daa5300c7106c31bc52673711cd0.camel%40cybertec.at
[2]: https://postgr.es/m/Y2nP04/3BHQOviVB%40momjian.us
On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
> > Some comments:
> >
>
> > > --- a/doc/src/sgml/ref/release_savepoint.sgml
> > > +++ b/doc/src/sgml/ref/release_savepoint.sgml
> >
On Thu, 2022-11-10 at 12:17 +0100, Alvaro Herrera wrote:
> On 2022-Nov-10, Laurenz Albe wrote:
> > On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> > > > > - If AND CHAIN is specified, a new
> > > > > transaction is
> > > >
meter, but I don't think that it is a good idea to deviate from our
usual standard of deprecating a feature for about five years before
actually removing it.
Yours,
Laurenz Albe
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chan
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyon
sactions
> + will have virtualxids but NULL
> + transactionids, while read-write transactions
> + will have both as non-NULL.
> +
Perhaps the following will be prettier than "have both as non-NULL":
..., while both columns will be set in read-write transactions.
Yours,
Laurenz Albe
sible use-case where this'd be a
> difficult change to deal with, I concur that we don't need to
> deprecate it ahead of time.
Since I am the only one that seems to worry, I'll shut up. You are probably
right that it the feature won't be missed by many users.
Yours,
Laurenz Albe
already in that status.
Yours,
Laurenz Albe
aparound cutoffs were chosen because they're
> easy to understand and remember, which is fairly arbitrary.
The target is a table that receives no DML at all, right?
I think that is a good idea.
Wouldn't it make sense to trigger that at *half* "autovacuum_freeze_max_age"?
Yours,
Laurenz Albe
e. On the other hand, it might happen that after this, people start
worrying about normal autovacuum runs because they occasionally experience
a table age autovacuum that is much heavier than the other ones. And
they can no longer tell the reason, because it doesn't show up anywhere.
Yours,
Laurenz Albe
y without thinking too hard about it,
only to discover later that dropping old partitions has become a problem,
I would not be too happy either.
Yours,
Laurenz Albe
On Wed, 2022-11-30 at 10:09 +0100, Vik Fearing wrote:
> On 11/29/22 17:29, Laurenz Albe wrote:
> > On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> > > I disagree. A user does not need to know that a table is partitionned,
> > > and if the user wants a unique c
On Tue, 2022-12-06 at 10:17 -0800, Andres Freund wrote:
> On 2022-10-29 10:35:26 +0200, Laurenz Albe wrote:
> > > > Here is a patch that
> > > > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> This fails to build the docs:
>
> https://cirrus-c
>
>1
>2
> (2 rows)
It is well known that synchronous replication is sublect to that problem,
since it doesn't use the two-phase commit protocol.
What surprises me is that this is a warning.
In my opinion it should be an error.
Yours,
Laurenz Albe
I (or English
> alphabet?). That's interesting.
Yes. In languages other than Turkish, "i" is the lower case version of "I",
and both are ASCII. Only Turkish has an "ı" (U+0131) and an "İ" (U+0130).
That causes annoyance for Turks who create a table named KADIN and find
that PostgreSQL turns it into "kadin".
Yours,
Laurenz Albe
t; inaccurate for example in that the current wording for "host" appears to
> say that it does not apply to GSS-encrypted connections.
+1
Thanks for taking care of things like that.
Yours,
Laurenz Albe
de, it says "... but if
> none of the listed hosts is a standby server, try again in all mode".
> There is no such "all" mode. It should instead say "any" mode.
> Patch is attached.
You are right, and the patch is good.
Yours,
Laurenz Albe
a WAL sender process, and I can measure the lag in bytes.
What more could you want?
Yours,
Laurenz Albe
On Mon, 2021-05-10 at 02:03 -0400, Bruce Momjian wrote:
> When using \e in psql, if the buffer is not modified by the editor, ignore
> the editor contents and leave the buffer unchanged (Laurenz Albe)
> The \ef and \ev commands also now have this behavior. DOCS SAY BUFFER IS
> CLEA
On Mon, 2021-05-10 at 12:38 -0400, Bruce Momjian wrote:
> I came up with this release note text:
>
>
>
>
>
> When editing the previous query or a file with psql's \e, ignore the
> contents if the editor exits
ous query or a file with psql's \e, or using \ef
> and \ev, ignore the contents if the editor exits without saving (Laurenz Albe)
>
>
>
> Previously, such edits would still execute the editor contents.
>
>
That is fine with me and p
server log which is a risky thing
> from security standpoint.
I think that is irrelevant.
A superuser can already set "log_statement = 'all'" to get this.
There is no protection from superusers, and it is pointless to require that.
Yours,
Laurenz Albe
r. Each database cluster
is in charge of vacuuming its own tables, so the better approach would
be to tune autovacuum on the remote side so that it does the right thing.
Yours,
Laurenz Albe
I would like to add a thread on pgsql-docs to the commitfest, but I
found that that cannot be done.
What is the best way to proceed?
Since we have a "documentation" section in the commitfest, it would
be useful to allow links to the -docs archives.
Yours,
Laurenz Albe
On Wed, 2021-05-19 at 10:31 -0400, Stephen Frost wrote:
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > I revently tried to upgrade a standby following the documentation,
> > but I found it hard to understand, [...]
>
> Haven't had a chance to look at this in depth
On Wed, 2021-05-05 at 12:03 +0200, Laurenz Albe wrote:
> On Mon, 2021-05-03 at 13:48 -0300, Martín Marqués wrote:
> > We should add a line that indicates that there is a limitation (that
> > should be IMO, backported to documentation of earlier versions as it
> > affects a
On Wed, 2021-05-05 at 11:55 +0200, Laurenz Albe wrote:
> On Wed, 2021-04-28 at 13:24 +0200, Laurenz Albe wrote:
> > On Tue, 2021-04-27 at 14:26 +, PG Doc comments form wrote:
> > > https://www.postgresql.org/docs/current/sql-createtrigger.html mentions
> > > the
&g
tion
explicitly says otherwise (for example, recovery.signal
for archive recovery).
Yours,
Laurenz Albe
for writing and issue a warning.
That is simple, but coarse.
A slightly more sophisticated version would first check if files
are the same on both machines and skip the warning for those.
- Paul's idea to try and change the mode on the read-only file
and reset it to the original state after pg_rewind is done.
Yours,
Laurenz Albe
ing any
+syscache cache entries, as this can cause subtle bugs. See
Subtle? Perhaps "bugs that are hard to find".
+src/backend/utils/cache/syscache.c,
+src/backend/utils/cache/relcache.c,
+ src/backend/access/common/relation.c and their
+headers fo
re;
> and I do not see why being spec-compliant for one case when we are not
> for the other is a good situation to be in.
+1
Yours,
Laurenz Albe
On Thu, 2023-01-19 at 15:56 -0500, Bruce Momjian wrote:
> On Thu, Jan 19, 2023 at 01:50:05PM +0100, Laurenz Albe wrote:
> > On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> > > Is it possible to document when partition table statistics helps?
> >
> > I think
.com/en/streaming-replication-conflicts-in-postgresql/
Yours,
Laurenz Albe
few more TB disk storage.
Yours,
Laurenz Albe
t wouldn't catch all abuse,
but it would be better than nothing.
There is of course the worry of breaking upgrade for unsafe constraints, but is
there any other reason not to enforce immutability?
Yours,
Laurenz Albe
On Tue, 2023-01-24 at 01:38 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > We throw an error if the expression in a CREATE INDEX statement is not
> > IMMUTABLE.
> > But while the documentation notes that expressions in CHECK constraints are
> > not
> > to be
On Wed, 2023-01-25 at 16:26 +1300, David Rowley wrote:
> On Wed, 18 Jan 2023 at 22:15, Laurenz Albe wrote:
> > Attached is a new version of my patch that tries to improve the wording.
>
> I had a look at this and agree that we should adjust the paragraph in
> question if peo
he existence of pg_xact_status, so I suspect that it
is not a widely known and used feature. After reading the documentation,
I'd say that anybody who uses it will want it to give a reliable answer.
So I'd agree that it is better to make it more expensive, but live up to
its promise.
Yours,
Laurenz Albe
e fault of this patch that the collation isn't there,
but I think it is surprising. What good is a database collation that does not
exist in the database?
What might be the fault of this patch, however, is that "daticurules" is not
set in "pg_database". Looking at the code, that column seems to be copied
from the template database, but cannot be overridden.
Perhaps this only needs more documentation, but I am confused.
Yours,
Laurenz Albe
> What do you think of "--load-via-partition-root=on/off/auto", where
> auto means "not with hash partitions" or the like?
That's perhaps the best way. So users who know that their hash
partitions won't change and want the small speed benefit can have it.
Yours,
Laurenz Albe
On Tue, 2023-01-31 at 13:49 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > [ 0001-Add-EXPLAIN-option-GENERIC_PLAN.v4.patch ]
>
> I took a closer look at this patch, and didn't like the implementation
> much. You're not matching the behavior of PREPARE at all:
On Fri, 2023-02-03 at 09:44 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I played around with it, and I ran into a problem with partitions that
> > are foreign tables:
> > ...
> > EXPLAIN (GENERIC_PLAN) SELECT * FROM looppart WHERE key = $1;
> > ERROR
On Sat, 2023-02-04 at 14:41 +0100, Daniel Verite wrote:
> Laurenz Albe wrote:
>
> > Cool so far. Now I created a database with that locale:
> >
> > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone
> > LOCALE "de_AT.utf8" TE
ag EXEC_FLAG_EXPLAIN_GENERIC.
To avoid having to change all the places that check EXEC_FLAG_EXPLAIN_ONLY
to also check for the new flag, I decided that the new flag can only be
used as "add-on" to EXEC_FLAG_EXPLAIN_ONLY.
Yours,
Laurenz Albe
From cd0b5a1a4f301bb7fad9088d5763989f5dde4636
can change in the
meantime. Think of prepared statements using a generic plan.
Yours,
Laurenz Albe
On Mon, 2023-02-13 at 16:33 -0800, Andres Freund wrote:
> On 2023-02-05 18:24:03 +0100, Laurenz Albe wrote:
> > Anyway, attached is v7 that tries to do it that way.
>
> This consistently fails on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42
tabase
with "ICU_LOCALE x", the rules are not copied over.
I don't know if that is intended or not, but it surprises me.
Should that be a WARNING? Or, since creating a database with a collation
that does not exist in "template0" doesn't make much sense (or does it?),
is there a way to forbid that?
Yours,
Laurenz Albe
o with the default choice of ICU, you should configure your
package manager not to upgrade the ICU library.
Yours,
Laurenz Albe
ons, as far as I know.
Yours,
Laurenz Albe
say that this is a pretty obvious case of pilot error.
Yours,
Laurenz Albe
over time, the use of the older serial
> mechanisms would go away.
I think that would be great.
That might generate some confusion among users who follow old tutorials
and are surprised that the eventual table definition differs, but I'd say
that is a good thing.
Yours,
Laurenz Albe
een, the optimizer always used the statistics of the partitions.
Yours,
Laurenz Albe
From 5209f228f09e52780535edacfee5f7efd2c25081 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 5 Oct 2022 10:31:47 +0200
Subject: [PATCH] Improve autovacuum doc on partitioned tables
The documentation mention
as a full-fledged EXPLAIN (ANALYZE, BUFFERS),
but it can definitely be helpful.
I tied that behavior to the setting of "plan_cache_mode" where you
are guaranteed to get a generic plan; I couldn't think of a better way.
Yours,
Laurenz Albe
From 2bc91581acd478d4648176b58745cadb835d5fbc
hould not be encouraged.
Anybody who knows enough about PostgreSQL to be sure that what they are
doing is correct should be smart enough to know how to edit the copied file.
Yours,
Laurenz Albe
have to go to great lengths
> trying to "unjumble" such queries, so having a way to easily get the answer
> for
> a generic plan would be great.
Thanks for the suggestions and the encouragement. Here is a patch that
implements it with an EXPLAIN option named GENERIC_PLAN.
Yours,
o query ID, no Heap Fetches, no Sort details, ...
Why not add this functionality to the GUC?
0005 suppresses "rows removed by filter", but how is that machine dependent?
> BTW, I think it may be that the GUC should be marked PGDLLIMPORT ?
I think it is project policy to apply this mark wherever it is needed. Do you
think
that third-party extensions might need to use this in C code?
Yours,
Laurenz Albe
On Tue, 2022-10-25 at 19:03 +0800, Julien Rouhaud wrote:
> On Tue, Oct 25, 2022 at 11:08:27AM +0200, Laurenz Albe wrote:
> > Here is a patch that
> > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> I only have a quick look at the patch for now. Any reason why yo
0003 go in, but it currently depends on 0001, which
I am not so sure about.
I understand that you did that so that "explain_regress" can turn off BUFFERS
and there is no extra churn in the regression tests.
Still, it would be a shame if resistance against "explain_regress" would
be a show-stopper for 0003.
If I could get my way, I'd want two separate patches: first, one to turn
BUFFERS on, and second one for "explain_regress" with its current functionality
on top of that.
Yours,
Laurenz Albe
gger. Is this just an incremental patch? If yes, it would
be nice to have a "grand total" patch, so that I can read it all
in one go.
Yours,
Laurenz Albe
t; SET enable_indexscan = off;
> SET enable_bitmapscan = off;
>
> And then the data was returned properly.
Sounds like data corruption.
REINDEX the index and see if that fixes the problem.
Try to figure out the cause (bad hardware?).
Yours,
Laurenz Albe
),
> + success_count == 1 ? "The" : "All",
> + success_count,
> + success_count == 1 ? "" : "s");
... and that wouldn't be translatable.
Yours,
Laurenz Albe
ways to
avoid them.
I think reducing functionality should be the last route to consider.
If we introduce new syntax to access partitions, we will end up with a lot
of new syntax, and we might well have an endless stream of requests for
ways to do X with a partition.
Yours,
Laurenz Albe
famous OFFSET 0, partly because it saves planning time,
partly because those can be useful tools.
Generally I have the impression that we are not too keen on spending
planning time on optimizing cases that can be trivially improved by rewriting
the query.
Yours,
Laurenz Albe
nk?
>
> [1]
> https://www.postgresql.org/message-id/514fe5ce4714b7b33cb0a611f0c7b72df413bef5.camel%40cybertec.at
I think that is much better.
I am fine with that patch.
Yours,
Laurenz Albe
ow I get following error:
> "All non-template0 databases must allow connections, i.e. their
> pg_database.datallowconn must be true; database "mydb" has datallowconn set
> to false."
I am in favor of that in principle, but I think that additional information
should be separate line.
Yours,
Laurenz Albe
to store in the node a common prefix
> for all tuples in the node.
> Thanks for any advice,
Perhaps the PostGIS source will inspire you. They are compressing an
entry to its bounding box.
Yours,
Laurenz Albe
4
> or
> Tuples: inserted=1 updated=2 deleted=3 skipped=4
>
> Note double spaces and capitals.
> That's separate from the question about eliding zeros.
+1 on one of the latter versions, I don't care which one.
Yours,
Laurenz Albe
ions and the effect remains
> after the transaction finished. Is it unacceptable behaviours,
> isn't it?
+1
Yours,
Laurenz Albe
I don't think this idea is fundamentally wrong, but I have two worries:
1. It would be a good idea good to make sure that there is not both
"extension--%--2.0.sql" and "extension--1.0--2.0.sql" present.
Otherwise the behavior might be indeterministic.
2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
their PostGIS 1.1 installation with it? Would that work?
Having a lower bound for a matching version might be a good idea,
although I have no idea how to do that.
Yours,
Laurenz Albe
pported.
+1 on the general idea.
At least, it will makes these operations simpler, but probably also less
invasive (no need to detach the affected partitions).
I didn't read the patch, but what lock level does that place on the
partitioned table? Anything more than ACCESS SHARE?
Yours,
Laurenz Albe
n the foreign table.
I feel that that is no bug, but I'd be curious to know if others disagree.
Yours,
Laurenz Albe
On Wed, 2022-06-08 at 11:12 +0900, Kyotaro Horiguchi wrote:
> At Tue, 07 Jun 2022 11:24:55 -0300, "Euler Taveira" wrote
> in
> > On Tue, Jun 7, 2022, at 12:03 AM, Laurenz Albe wrote:
> > > On Sat, 2022-06-04 at 21:18 +, Phil Florent wrote:
> > > >
On Wed, 2022-06-08 at 13:06 +0900, Kyotaro Horiguchi wrote:
> At Wed, 08 Jun 2022 12:09:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe
> > wrote in
> > > If anything, it should be done in the FDW, because it is o
On Wed, 2022-06-08 at 19:06 +0900, Etsuro Fujita wrote:
> On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi
> wrote:
> > At Wed, 08 Jun 2022 07:05:09 +0200, Laurenz Albe
> > wrote in
> > > diff --git a/doc/src/sgml/postgres-fdw.sgml
> > > b/doc/src/sgml/post
On Thu, 2022-06-09 at 21:55 +0900, Etsuro Fujita wrote:
> On Thu, Jun 9, 2022 at 9:49 AM Laurenz Albe wrote:
> > On Wed, 2022-06-08 at 19:06 +0900, Etsuro Fujita wrote:
> > > On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi
> > > wrote:
> > > > At Wed, 0
ht notice unexpected behavior on account of the timing of
permission checks. Other than that, I consider this below the threshold for
user-facing documentation.
I'm ok with just doing nothing here, I just wanted it discussed in public.
Yours,
Laurenz Albe
ot being needed at all.
I also disagree with that. Not having a superuser is one of the pain
points with using a hosted database: no untrusted procedural languages,
no untrusted extensions (unless someone hacked up PostgreSQL or provided
a workaround akin to a SECURITY DEFINER function), etc.
Yours,
Laurenz Albe
ption", which should already be warning enough.
Perhaps some stronger wording in the documetation would be beneficial.
I have little sympathy with people who set unusual parameters without
even glancing at the documentation.
Yours,
Laurenz Albe
On Wed, 2022-06-29 at 00:05 -0700, Andres Freund wrote:
> On 2022-06-29 08:51:10 +0200, Laurenz Albe wrote:
> > On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > > > Experience shows that 99% of the time one can run PostgreSQL just fine
> > > > without a
ng of "timezone" is how that timestamp is converted to a
string, but that's a different affair.
Yours,
Laurenz Albe
#x27;-TMMonth-DD');
to_timestamp
2022-07-05 00:00:00+02
(1 row)
test=> SET lc_time = 'de_DE.utf8';
SET
test=> SELECT to_timestamp('2022-July-05', 'YYYY-TMMonth-DD');
ERROR: invalid value "July-05" for "Month"
DETAIL: The given value did not match any of the allowed values for this field.
Yours,
Laurenz Albe
, but to serve your immediate need:
After calling pg_terminate_backend(), you can attach gdb to the backend and
then run
print ProcessInterrupts()
That will cause the backend to exit normally without crashing the server.
Yours,
Laurenz Albe
n out the increase
in statistics messages, except in the case of lots of short-lived
sessions. But in that scenario you cannot have session statistics
without lots of extra messages, and such a workload has enough performance
problems as it is, so I don't think we have to specifically worry about it.
Yours,
Laurenz Albe
On Tue, 2021-08-31 at 18:55 -0700, Andres Freund wrote:
> > > On Tue, Aug 31, 2021 at 04:55:35AM +0200, Laurenz Albe wrote:In the view
> > > of that, how about doubling PGSTAT_STAT_INTERVAL to 1000
> >
> > > milliseconds? That would mean slightly less up-to-d
401 - 500 of 853 matches
Mail list logo