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
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 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, b
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:
> > > &
ons
on the foreign table.
I feel that that is no bug, but I'd be curious to know if others disagree.
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
rries:
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
transactions and the effect remains
> after the transaction finished. Is it unacceptable behaviours,
> isn't it?
+1
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
ore 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
g or the databases from drifting apart.
Yours,
Laurenz Albe
of two-phase commit can make this bulletproof.
Is it worth adding additional complexity that is not a complete solution?
Yours,
Laurenz Albe
would
naturally think that the config files in /etc need to be handled manually,
but "postgresql.auto.conf" need not.
I am +1 on Tom's idea.
Yours,
Laurenz Albe
s are
> > certainly welcome. Otherwise, I'm hoping to commit this tomorrow.
>
> LGTM!
Cassandra (not the software) from the sidelines predicts that we will
get some fire from users for this, although I concede the theoretical
sanity of the change.
Yours,
Laurenz Albe
the fine-grained reset, but I am -1 on having that
reset "pg_stat_database.stats_reset". That would make the timestamp
mostly useless.
One could argue that resetting a single counter and *not* resetting
"pg_stat_database.stats_reset" would also be a lie, but at least it is
a
On Wed, 2022-03-23 at 21:31 +, Jacob Champion wrote:
> On Mon, 2022-03-07 at 11:44 +0100, Laurenz Albe wrote:
> > I am all for the idea, but you implemented the reverse of proposal 2.
> >
> > Wouldn't it be better to list the *rejected* authentication methods?
> > T
_str, total_size_str,
> percent);
I think you replied to the wrong thread...
Yours,
Laurenz Albe
that you found the oversight in LOCK - I wasn't even
aware that views could be locked.
Yours,
Laurenz Albe
═══
2022-03-27 21:00:00+02
(1 row)
test=> SELECT TIMESTAMPTZ '2022-03-26 20:00:00 Europe/Vienna' + INTERVAL '1
day';
?column?
2022-03-27 20:00:00+02
(1 row)
Yours,
Laurenz Albe
On Mon, 2022-03-14 at 13:40 +0100, Christoph Heiss wrote:
> On 3/9/22 16:06, Laurenz Albe wrote:
> > This paragraph contains a couple of grammatical errors.
>
> Replaced the two paragraphs with your suggestion, it is indeed easier to
> read.
>
> > Also, this
ND_VIEW
&& RelationHasSecurityInvoker(relation))
user_for_check = InvalidOid;
else
user_for_check = relation->rd_rel->relowner;
setRuleCheckAsUser((Node *) rule->actions, user_for_check);
setRuleCheckAsUser(rule->qual, user_for_check);
This might be easier to read.
Yours,
Laurenz Albe
then: you get to choose exactly one method
> that the client will accept.
I am all for the idea, but you implemented the reverse of proposal 2.
Wouldn't it be better to list the *rejected* authentication methods?
Then we could have "password" on there by default.
Yours,
Laurenz Albe
the same way that
Walter did, namely that this behaves just like security invoker functions.
But if the behavior is well documented, I think that is ok.
Yours,
Laurenz Albe
er 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 Sep 17 00:
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.
&g
E 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
> 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
s_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 went
u suggest instead? pg_stat_all_tables.n_live_tup?
Yours,
Laurenz Albe
mission
+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
h
"Access to tables referenced in the view is determined by permissions of the
view owner."
This looks like the best place to me (and it would need to be adapted anyway).
Yours,
Laurenz Albe
> doubt the claim that the average Postgres user needs this, and
> doubt even more that they need it on all the time.
> So I'm -1 on the idea.
I set "track_io_timing" to "on" all the time, same as "log_lock_waits",
so I'd want them both on by default.
Yours,
Laurenz Albe
tance", fine.
About the back branches, removing the documentation is a good choice.
I think the lack of complaints is because everybody who needs serious
geometry processing uses PostGIS.
Yours,
Laurenz Albe
lusive
> backup to be at all compelling and the lack of huge issues with the new
> way restore works to make it abundently clear that we can, in fact,
> remove exclusive backup in a major version change without the world
> coming down.
I guess the lack of hue and cry was at least to a certain extent because
the exclusive backup API was deprecated, but not removed.
Yours,
Laurenz Albe
On Mon, 2021-11-29 at 09:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > There was one other problem mentioned in the original mail, and that
> > seems to be the most serious one to me:
> > [ HISTCONTROL behavior ]
>
> The actual behavior of that option (whi
line that starts with space
test=> SELECT 42;
?column?
══
42
(1 row)
Now that query is not added to the history file at all.
Yours,
Laurenz Albe
o PostgreSQL, but not
part of it.
Yours,
Laurenz Albe
> A bit of polishing later, maybe like the attached.
That looks good to me.
Yours,
Laurenz Albe
ment was expected before this writing. If we look at the
> nextval_interval more carefully, we can find it would not flush the xlog every
> time even the sequence's cachesize is 1. Currently It happens every 32 times
> on the nextval_internal at the worst case.
Right, I didn't think of that. Still, I'm -1 on this performance regression.
Yours,
Laurenz Albe
oday and found this case].
I think that is a bad idea.
It will have an intolerable performance impact on OLTP queries, doubling
the number of I/O requests for many cases.
Perhaps it would make sense to document that you should never rely on
sequence values from an uncommitted transaction.
Yours,
Laurenz Albe
happening on attaching collation versions
> to indexes). But personally I can't summon the motivation to work
> on that, when ICU is the *only* such infrastructure that offers
> readily program-readable versioning.
Nobody will want to hear that, but the only really good solution would
be for
t be worth worrying about,
and they can always come and make a case for that symbol to be exported.
Yours,
Laurenz Albe
hey can dump with 8.3 and restire that.
Yours,
Laurenz Albe
relfilenode,
relname from pg_class");
int count = 100;
while (rs.next() && count-- > 0) {
System.out.print(".");
}
rs.close();
stmt.close();
System.out.println("");
conn.close();
}
}
Yours,
Laurenz Albe
t for context: the -docs thread that belongs to this is
https://www.postgr.es/m/20211001163938.ifg4ayrsjwd7r6zr%40localhost
Yours,
Laurenz Albe
mplicated questions when
we dig deeper, such as "what about whole-row references?", tilts my vote.
If it were for free, I would say +1. But given the ratio of potential
headache versus added real-life benefit, I find myself voting -1.
Still, it is cute!
Yours,
Laurenz Albe
it to the next commit fest?
Thanks for that work; help with Windows is always welcome.
Please go ahead and add the patch to the commitfest yourself.
Testing will (hopefully) be done by a reviewer who has access to MSVC 2022.
Yours,
Laurenz Albe
On Thu, 2021-09-30 at 18:26 -0400, Chapman Flack wrote:
> On 09/30/21 17:54, Florin Irion wrote:
> > We could also help users get a warning if they set a parameter with the
> > `SET` command.
>
> So I am in favor of patching this.
+1 on the idea.
Yours,
Laurenz Albe
w the statistics.
Yours,
Laurenz Albe
riable pgLastSessionReportTime
- add a comment to explain why we only track normal backends
- pgindent
- an attempt at a commit message
Yours,
Laurenz Albe
From 1fdfac528ec4e75d91b9cf3868eda66a72a41c8f Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 8 Sep 2021 06:06:46 +0200
Subject: [PATCH] Fix
uld
welcome the change. This has bothered me before.
That multi-line statements that contain a line with a space are omitted
from the history when HISTCONTROL is set to "ignorespace" seems like
a bug to me.
So +1 on the idea of the patch, although I didn't scrutinize the
implementation.
Yours,
Laurenz Albe
On Mon, 2021-09-06 at 00:22 -0700, Andres Freund wrote:
> On 2021-09-06 09:12:58 +0200, Laurenz Albe wrote:
> > Reading your patch, I am still confused about the following:
> > There are potentially several calls to "pgstat_send_tabstat" in
> > "pgs
for disconnecting, but perhaps that would be better? Then
> we could get rid of the whole pgStatSessionEndCause variable.
I see your point, but I am not certain if it is worth adding yet another message
for a small thing like that. I have no strong opinion on that though.
Reading your patch, I am still confused about the following:
There are potentially several calls to "pgstat_send_tabstat" in
"pgstat_report_stat".
It seems to me that if it were called more than once, session statistics would
be reported and counted several times, which would be wrong.
Yours,
Laurenz Albe
On Fri, 2021-09-03 at 18:24 +0200, Daniel Gustafsson wrote:
> > On 6 Apr 2021, at 09:46, Amit Langote wrote:
> > On Fri, Apr 2, 2021 at 11:36 PM Laurenz Albe
> > wrote:
>
> > > I don't know if Seamus is still working on that; if not, we might
> >
On Wed, 2021-09-01 at 10:56 +0200, Laurenz Albe wrote:
> On Tue, 2021-08-31 at 21:16 -0700, Andres Freund wrote:
> > On 2021-09-01 05:39:14 +0200, Laurenz Albe wrote:
> > > On Tue, 2021-08-31 at 18:55 -0700, Andres Freund wrote:
> > > > > > On Tue, Aug 31, 20
On Tue, 2021-08-31 at 21:16 -0700, Andres Freund wrote:
> On 2021-09-01 05:39:14 +0200, Laurenz Albe wrote:
> > 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
> > > >
On Wed, 2021-09-01 at 10:33 +0900, Michael Paquier 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?
>
> Perhaps we could do that. Now, increasing an
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
ut 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
erve 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
On Tue, 2021-08-24 at 15:12 +0900, Kyotaro Horiguchi wrote:
> At Wed, 18 Aug 2021 05:16:38 +0200, Laurenz Albe
> wrote in
> > On Tue, 2021-08-17 at 02:14 -0700, Andres Freund wrote:
> > > > > I'm also not all that happy with sen
different from the database encoding.
So I am not too excited about this.
> +1 once that Oracle Database 12.2 and higher, has support for 128 bytes names.
> What possibly, in the future, could impact some migration from Oracle to
> Postgres.
That seems to be a better argument from my point of view.
I have no idea as to how bad the additional memory impact for the catalog
caches would be...
Yours,
Laurenz Albe
On Tue, 2021-08-17 at 02:14 -0700, Andres Freund wrote:
> On 2021-08-17 10:44:51 +0200, Laurenz Albe wrote:
> > On Sun, 2021-08-01 at 13:55 -0700, Andres Freund wrote:
> > > We maintain last_report as GetCurrentTransactionStopTimestamp(), but then
> > > use
t is useful enough to break the standard in a way that may be
incompatible with future extensions of the standard.
Yours,
Laurenz Albe
han what we would want to do at this point in
> the release cycle though. But I think we ought to do something about the
> increased overhead...
If you are talking about the extra GetCurrentTimestamp() call, and my first
suggestion is acceptable, that should be simple.
Yours,
Laurenz Albe
ancel request succeeded) will later turn out to be committed after all,
just like it is now (only later). Where is the advantage?
Besides, there is no room for another transaction status in the
commit log.
Yours,
Laurenz Albe
erformance. But I admit is is not frequently used.
In a data warehouse, which is updated only occasionally, running
CLUSTER after an update can make a lot of sense.
I personally think that it is enough to be able to cluster the table
partiton by partition.
Yours,
Laurenz Albe
s more performance or is complicated would not
be worth the effort.
Yours,
Laurenz Albe
On Thu, 2021-07-15 at 20:16 -0500, Justin Pryzby wrote:
> On Wed, Jul 14, 2021 at 07:42:33AM +0200, Laurenz Albe wrote:
> > Besides, schemas are not physical, but logical containers. So I see a
> > point in
> > measuring the storage used in a certain tablespace, b
a minor inconvenience.
But I don't buy your second point: if it is like that, why do we have
Asserts at all?
Yours,
Laurenz Albe
unctions"
> seems the most logical place to put these.
>
> [1] https://www.postgresql.org/docs/current/catalog-pg-database.html
> [2]
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5eb1d0deb15f2b7cd0051bef12f3e091516c723b
>
> Will add to the next commitfest.
+1
Yours,
Laurenz Albe
nting purposes, though.
But I don't expect it to be in frequent enough demand to add a psql command.
What about inventing a function pg_schema_size(regnamespace)?
Yours,
Laurenz Albe
ding an Assert that gags on NULLs, but still printing them
as "(null)"? That would help find such problems in a debug build.
Yours,
Laurenz Albe
ollowing 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
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
tly 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
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
t; + success_count == 1 ? "The" : "All",
> + success_count,
> + success_count == 1 ? "" : "s");
... and that wouldn't be translatable.
Yours,
Laurenz Albe
ndexscan = 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
t here;
> 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
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 for details.
+
+
Attached i
d 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
explicitly says otherwise (for example, recovery.signal
for archive recovery).
Yours,
Laurenz Albe
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
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-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 but
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
uster
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
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
previous 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 probab
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 with
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
> CL
, and I can measure the lag in bytes.
What more could you want?
Yours,
Laurenz Albe
mode, 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
; 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
s. 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
>
>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
is a procedural language as the name suggests, you probably don't have
to modify PostgreSQL core code to make it work.
Yours,
Laurenz Albe
On Sat, 2021-04-03 at 17:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > Attached is version 6.
>
> Pushed with some mostly-cosmetic fiddling.
>
> One thing I changed that wasn't cosmetic is that as you had it,
> the behavior of "\e file" varied depending
"Either use a later backup, or recover to a point in time before \"wal_level\"
was set to \"minimal\"."
I'd say that we can leave it to the intelligence of the reader to
deduce that recovering to an earlier time means more data loss.
Yours,
Laurenz Albe
301 - 400 of 721 matches
Mail list logo
