Re: Berserk Autovacuum (let's save next Mandrill)

2020-03-27 Thread Laurenz Albe
-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

Re: Berserk Autovacuum (let's save next Mandrill)

2020-03-27 Thread 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

Re: Berserk Autovacuum (let's save next Mandrill)

2020-03-29 Thread Laurenz Albe
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

Re: Creating a database with a non-predefined collation

2020-03-29 Thread 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

Re: Add A Glossary

2020-04-03 Thread 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

Re: [PATCH] Add reloption for views to enable RLS

2022-01-20 Thread 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

Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?

2022-01-27 Thread Laurenz Albe
u suggest instead? pg_stat_all_tables.n_live_tup? Yours, Laurenz Albe

Re: [PATCH] Add reloption for views to enable RLS

2022-02-04 Thread 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

Re: [PATCH] Add reloption for views to enable RLS

2022-02-09 Thread Laurenz Albe
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

Re: [PATCH] Add reloption for views to enable RLS

2022-02-15 Thread 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

Re: [PATCH] Add reloption for views to enable RLS

2022-02-15 Thread 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. > &

Re: [PATCH] Add reloption for views to enable RLS

2022-02-18 Thread Laurenz Albe
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

Re: Postgres auto vacuum - Disable

2022-11-07 Thread Laurenz Albe
eak configured with "autovacuum_vacuum_cost_delay". Reduce that parameter for more autovacuum speed. Yours, Laurenz Albe

Re: New docs chapter on Transaction Management and related changes

2022-11-07 Thread 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

Re: New docs chapter on Transaction Management and related changes

2022-11-07 Thread 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

Re: New docs chapter on Transaction Management and related changes

2022-11-09 Thread Laurenz Albe
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

Re: New docs chapter on Transaction Management and related changes

2022-11-09 Thread Laurenz Albe
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 > >

Re: New docs chapter on Transaction Management and related changes

2022-11-13 Thread Laurenz Albe
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 > > > >

Re: Reducing power consumption on idle servers

2022-11-20 Thread Laurenz Albe
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

Re: Reducing power consumption on idle servers

2022-11-21 Thread 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

Re: Reducing power consumption on idle servers

2022-11-21 Thread Laurenz Albe
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

Re: New docs chapter on Transaction Management and related changes

2022-11-21 Thread Laurenz Albe
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

Re: Reducing power consumption on idle servers

2022-11-21 Thread 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

Re: New docs chapter on Transaction Management and related changes

2022-11-22 Thread Laurenz Albe
already in that status. Yours, Laurenz Albe

Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation

2022-11-26 Thread 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

Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation

2022-11-27 Thread 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

Re: Patch: Global Unique Index

2022-11-29 Thread 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

Re: Patch: Global Unique Index

2022-11-30 Thread 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

Re: Make EXPLAIN generate a generic plan for a parameterized query

2022-12-07 Thread Laurenz Albe
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

Re: Synchronous commit behavior during network outage

2021-04-21 Thread 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

Re: Support tab completion for upper character inputs in psql

2021-04-23 Thread 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

Re: pg_hba.conf.sample wording improvement

2021-04-27 Thread 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

Re: Error in libpq docs for target_session_attrs, prefer-standby mode

2021-04-28 Thread 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

Re: pg_receivewal makes a bad daemon

2021-05-05 Thread Laurenz Albe
a WAL sender process, and I can measure the lag in bytes. What more could you want? Yours, Laurenz Albe

Re: PG 14 release notes, first draft

2021-05-09 Thread 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

Re: PG 14 release notes, first draft

2021-05-10 Thread Laurenz Albe
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

Re: PG 14 release notes, first draft

2021-05-10 Thread Laurenz Albe
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

Re: RFC: Logging plan of the running query

2021-05-12 Thread 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

Re: Support for VACUUMing Foreign Tables

2021-05-14 Thread 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

Commitfest app vs. pgsql-docs

2021-05-19 Thread 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

Re: Improve documentation for pg_upgrade, standbys and rsync

2021-05-19 Thread 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

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

2021-05-20 Thread Laurenz Albe
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

Re: Clarify how triggers relate to transactions

2021-05-20 Thread 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

Re: pg_rewind fails if there is a read only file.

2021-05-25 Thread Laurenz Albe
tion explicitly says otherwise (for example, recovery.signal for archive recovery). Yours, Laurenz Albe

Re: pg_rewind fails if there is a read only file.

2021-05-25 Thread 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

Re: [PATCH] More docs on what to do and not do in extension code

2021-05-30 Thread 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: CALL versus procedures with output-only arguments

2021-05-31 Thread Laurenz Albe
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

Re: document the need to analyze partitioned tables

2023-01-20 Thread 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

Re: ***Conflict with recovery error***

2023-01-20 Thread Laurenz Albe
.com/en/streaming-replication-conflicts-in-postgresql/ Yours, Laurenz Albe

Re: ***Conflict with recovery error***

2023-01-20 Thread Laurenz Albe
few more TB disk storage. Yours, Laurenz Albe

Mutable CHECK constraints?

2023-01-23 Thread 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

Re: Mutable CHECK constraints?

2023-01-24 Thread 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

Re: document the need to analyze partitioned tables

2023-01-24 Thread Laurenz Albe
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

Re: Something is wrong with wal_compression

2023-01-26 Thread Laurenz Albe
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

Re: Allow tailoring of ICU locales with custom rules

2023-01-31 Thread 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

Re: pg_dump versus hash partitioning

2023-02-02 Thread 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

Re: Make EXPLAIN generate a generic plan for a parameterized query

2023-02-03 Thread 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:

Re: Make EXPLAIN generate a generic plan for a parameterized query

2023-02-03 Thread Laurenz Albe
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

Re: Allow tailoring of ICU locales with custom rules

2023-02-04 Thread Laurenz Albe
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

Re: Make EXPLAIN generate a generic plan for a parameterized query

2023-02-05 Thread Laurenz Albe
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

Re: Why cann't simplify stable function in planning phase?

2023-02-08 Thread Laurenz Albe
can change in the meantime. Think of prepared statements using a generic plan. Yours, Laurenz Albe

Re: Make EXPLAIN generate a generic plan for a parameterized query

2023-02-14 Thread 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

Re: Allow tailoring of ICU locales with custom rules

2023-02-14 Thread Laurenz Albe
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

Re: Move defaults toward ICU in 16?

2023-02-16 Thread Laurenz Albe
o with the default choice of ICU, you should configure your package manager not to upgrade the ICU library. Yours, Laurenz Albe

Re: Move defaults toward ICU in 16?

2023-02-17 Thread Laurenz Albe
ons, as far as I know. Yours, Laurenz Albe

Re: postgres_fdw: dead lock in a same transaction when postgres_fdw server is lookback

2022-10-01 Thread Laurenz Albe
say that this is a pretty obvious case of pilot error. Yours, Laurenz Albe

Re: future of serial and identity columns

2022-10-04 Thread 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

Re: document the need to analyze partitioned tables

2022-10-05 Thread 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

Make EXPLAIN generate a generic plan for a parameterized query

2022-10-11 Thread Laurenz Albe
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

Re: [PATCH] Allow usage of archive .backup files as backup_label

2022-10-17 Thread Laurenz Albe
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

Re: Make EXPLAIN generate a generic plan for a parameterized query

2022-10-25 Thread 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,

Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))

2022-10-25 Thread Laurenz Albe
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

Re: Make EXPLAIN generate a generic plan for a parameterized query

2022-10-29 Thread 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

Re: explain_regress, explain(MACHINE), and default to explain(BUFFERS) (was: BUFFERS enabled by default in EXPLAIN (ANALYZE))

2022-11-04 Thread Laurenz Albe
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

Re: New docs chapter on Transaction Management and related changes

2022-11-04 Thread 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

Re: Strangeness with UNIQUE indexes and UTF-8

2021-06-06 Thread 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

Re: Use singular number when appropriate

2021-06-15 Thread Laurenz Albe
), > + success_count == 1 ? "The" : "All", > + success_count, > + success_count == 1 ? "" : "s"); ... and that wouldn't be translatable. Yours, Laurenz Albe

Re: Deadlock risk while inserting directly into partition?

2021-06-28 Thread 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

Re: Removing unneeded self joins

2021-06-30 Thread 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

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

2021-07-02 Thread 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

Re: [PATCH] improve the pg_upgrade error message

2021-07-12 Thread 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

Re: Item compression in the Gist index

2022-05-02 Thread 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

Re: support for MERGE

2022-05-11 Thread 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

Re: Prevent writes on large objects in read-only transactions

2022-05-27 Thread Laurenz Albe
ions and the effect remains > after the transaction finished. Is it unacceptable behaviours, > isn't it? +1 Yours, Laurenz Albe

Re: [PATCH] Support % wildcard in extension upgrade filenames

2022-05-28 Thread 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

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

2022-05-31 Thread 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

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-06 Thread 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

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-07 Thread 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: > > > >

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-07 Thread Laurenz Albe
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

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-08 Thread Laurenz Albe
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

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-09 Thread Laurenz Albe
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

Re: Error from the foreign RDBMS on a foreign table I have no privilege on

2022-06-10 Thread Laurenz Albe
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

Re: Hardening PostgreSQL via (optional) ban on local file system access

2022-06-28 Thread 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

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

2022-06-28 Thread 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

Re: Hardening PostgreSQL via (optional) ban on local file system access

2022-06-29 Thread 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

Re: Wrong provolatile value for to_timestamp (1 argument)

2022-07-05 Thread Laurenz Albe
ng of "timezone" is how that timestamp is converted to a string, but that's a different affair. Yours, Laurenz Albe

Re: Wrong provolatile value for to_timestamp (1 argument)

2022-07-05 Thread 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

Re: Pg stuck at 100% cpu, for multiple days

2021-08-30 Thread 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

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

2021-08-30 Thread 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

Re: pgstat_send_connstats() introduces unnecessary timestamp and UDP overhead

2021-08-31 Thread 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

<    1   2   3   4   5   6   7   8   9   >