ion would surely have told me what else I
have to do to avoid that scary eventuality.
I'd be OK with writing "necessary and sufficient". Or is that too much
legalese?
Yours,
Laurenz Albe
eral terror at the idea of anyone actually
using this procedure.
Yours,
Laurenz Albe
[1]:
https://www.postgresql.org/message-id/flat/22f129004bb66cd91e1dfd3345a9787f5039f3ae.camel%40cybertec.at
how long the
bigger patch would take.
I am OK with Michael's suggestion to just remove the wrong line,
although it wouldn't be bad to have an explanation of what we mean
by "asynchronous" here.
Yours,
Laurenz Albe
gt; sounds good as it highlights from the beginning that there is some
> variety.
Hm, yes, we could add "by default".
Yours,
Laurenz Albe
On Mon, 2025-09-01 at 13:51 +0200, Artem Gavrilov wrote:
> As I understand in configuration `Master
> -> Upstream -> Downstream` replication between Master And Upstream
> still can be synchronous, while between Upstream and Downstream is't
> always async. Am I wrong here?
don't quite understand. Sure, you can have synchronous replication
between the master and upstream. It is the "isn't always async" part
that confuses me. Do you mean that WAL can reach downstream before
the master commits? That is certainly the case.
Yours,
Laurenz Albe
On Mon, 2025-09-01 at 08:20 +0900, Michael Paquier wrote:
> On Wed, Aug 27, 2025 at 02:13:21PM +0200, Laurenz Albe wrote:
> > Here is a patch for that.
> > --- a/doc/src/sgml/high-availability.sgml
> > +++ b/doc/src/sgml/high-availability.sgml
> > @@ -527,8 +527,8 @@ p
On Mon, 2025-08-25 at 09:58 +0200, Laurenz Albe wrote:
> On Thu, 2025-08-21 at 15:20 +, PG Doc comments form wrote:
> > Page: https://www.postgresql.org/docs/17/warm-standby.html
> >
> > The documentation page about Log-Shipping Standby Servers after describing
> >
better be
It should be noted that by default, log shipping is asynchronous, i.e.,
the primary server does not wait until the standby receives the data.
Yours,
Laurenz Albe
ibutions that I am aware of don't
ship with tutorial binaries, so you have to build it from source.
I think that it would make sense to have a binary "tutorial" package,
but that is for the packager lists rather than for the bugs list.
Yours,
Laurenz Albe
List of tables
Schema │ Name │ Type │ Owner
═╪╪═══╪═
laurenz │ new ↵│ table │ laurenz
│ line │ │
laurenz │ newtab │ table │ laurenz
(2 rows)
Yours,
Laurenz Albe
ned anywhere.
That has nothing to do with privileges, that's just psql's standard
way of displaying newlines. See
https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-META-COMMAND-PSET-LINESTYLE
Yours,
Laurenz Albe
plain why "create database db_name;" works for you,
because that is an SQL statement.
Yours,
Laurenz Albe
that is best put forth in a separate
> thread / patch.
Makes sense, and I have no objection to the patch as it is.
Yours,
Laurenz Albe
reading the VACUUM reference page, I get the
feeling that the new syntax with parentheses should be favored.
After all, the old syntax doesn't support any of the recently
added options and restricts the option order.
So perhaps we should start propagating the parentheses more, and
the documentation is the perfect place to do that.
Yours,
Laurenz Albe
> though. So about like this?
+1
This thread doesn't look like we're going to find a wording that will
make everyone happy, but I believe that this patch is a clear improvement.
Quite contrary to David, I would have liked the word "protocol" with
the message, because it gives me personally the right idea, but I am
fine with "message" alone. After all, a message in PostgreSQL jargon
is a protocol message.
Yours,
Laurenz Albe
d expanding on SPI and the client-server protocol isn't what's
asked for here. The documentation should be detailed, but there is a fine
line that you shouldn't cross if you don't want to confuse the reader.
The parenthetical remark is hopefully enough to get the interested reader
on the right track.
Yours,
Laurenz Albe
On Sun, 2025-07-13 at 11:27 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > After looking at the code, I guess what made Tom add the remark in commit
> > eaf8f312c754 was the fact that an SQL statement is not necessarily processed
> > in a single go: with the extende
ement is parsed than when it is executed.
However, what matters to the client is the value when the statement starts
executing, because that's the value that will be reported.
So I'd argue that we should remove the parenthetical remark. It confuses
more than it enlightens, and whoever needs to know that level of detail
had better read the code anyway.
Yours,
Laurenz Albe
rase is "in the default configuration".
The default value for 'search_path' is '"$user", public'.
Now by default there is no schema with the same name as the database user, so
the effective default search path is just the 'public' schema.
Yours,
Laurenz Albe
RROR: permission denied to grant role "pg_create_subscription"
> DETAIL: Only roles with the ADMIN option on role "pg_create_subscription"
> may grant this role.
+1
That looks like a clear oversight.
Yours,
Laurenz Albe
On Thu, 2025-06-05 at 11:19 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Thu, 2025-06-05 at 15:29 +0200, Patrick Stählin wrote:
> > > I noticed that we don't document that you need to own the object being
> > > modified by SECURITY LABEL.
>
> Y
ay that you have to be a member of the owning
role?
But perhaps that would be complicated enough to confuse many users.
In general, +1 for documenting that.
Yours,
Laurenz Albe
error on the COMMIT.
We have been there before:
https://postgr.es/m/b9fb50dc-0f6e-15fb-6555-8ddb86f4aa71%40postgresfriends.org
Nothing came of that discussion though.
Yours,
Laurenz Albe
CK. Do you want to suggest a patch?
Yours,
Laurenz Albe
══
f
(1 row)
Can you show examples of what you mean?
Yours,
Laurenz Albe
oes work like this.
>From the above:
To create a unique or primary key constraint on a partitioned table,
[...] the constraint's columns must include all of the partition key columns.
You seem to read it the other way around. Your example confirms what the
documentation says.
Yours,
Laurenz Albe
On Tue, 2025-04-15 at 15:54 +0200, Daniel Gustafsson wrote:
> Going over the docs with a spellchecker now that v18 closed found a few typos
> as per the attached. I'll apply that shortly unless objected to.
+1
These are all obvious typos.
Yours,
Laurenz Albe
be great if you could put on both of your hats and come up with
a patch that implements the rather invasive change you are envisioning.
Then we can see if it feels better overall, and we have a concrete basis
for a discussion.
Yours,
Laurenz Albe
= 'Bill';
schedule
{{meeting},{training}}
(1 row)
Admittedly, there is no exact definition, but the example makes clear that
the boundaries are inclusive.
I don't think that we need to repeat that information.
Yours,
Laurenz Albe
d idea.
On the other hand, PostgreSQL will protest if the directory isn't
empty...
Yours,
Laurenz Albe
k? Should I post the expected text somewhere?
The code makes no sense, but what about this:
DO $$BEGIN RAISE EXCEPTION SQLSTATE '0'; END;$$;
ERROR: 0
CONTEXT: PL/pgSQL function inline_code_block line 1 at RAISE
Yours,
Laurenz Albe
d should not be a mount
point. The directory will be created (including missing parents) if
necessary.
Yours,
Laurenz Albe
database,
and can be used both for point-in-time recovery (see Section 25.3)
^
the link that I mean
and as the starting point for a log-shipping or streaming-replication
standby server (see Section 26.2).
So I don't really see how that could be any better.
Yours,
Laurenz Albe
On Wed, 2025-03-05 at 13:11 +0400, Anatoly Pugachev wrote:
> On Tue, Mar 4, 2025 at 12:02 AM Laurenz Albe wrote:
> > On Sun, 2025-03-02 at 09:27 +, PG Doc comments form wrote:
> > > Is there any way to restore pg_basebackup ? Reading current documentation
> > > on
/continuous-archiving.html#BACKUP-PITR-RECOVERY
Yours,
Laurenz Albe
reported problem in all the back branches through
> 14 --- PG 13 did not have the problem.
>
> Patches attached.
Thanks! These patches look good to me.
Yours,
Laurenz Albe
--
*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den
bezeichneten Adressaten bestimmt. W
anch and if we decide to keep the new default, we will
> change the docs later. I didn't want to interfere with that.
Hmpf. The documentation should always be in sync with the code, right?
So I think it should be left alone in HEAD, and if the checksum change
gets reverted, your patch should be
enabled or disabled at a later time as an offline
> operation. Data checksums are enabled or disabled at the full cluster
The change looks good for the back branches, but the default has changed
in v18: now checksums are the default. So "can be enabled" doesn't sound
right
> Hopefully these suggestions are helpful. Thanks again!
Your understanding is correct.
I personally think of "timestamp with time zone" as an "absolute timestamp".
To preserve the original time zone that was entered, you'd have to store it
in a separate database column.
We welcome a documentation patch!
Yours,
Laurenz Albe
e PL/pgSQL documentation, but that would be a different
list.
Yours,
Laurenz Albe
serializable if the execution is consistent with one serial
execution.
Yours,
Laurenz Albe
PostgreSQL, like in most other database
> systems, are based on data actually accessed by a transaction." which
> implies if transaction 2 can't see the data it can't predicate lock the
> data, And I believe the application code should not have been triggering a
> background process (Transaction 2) before Transaction 1 commits because it
> could rollback.
The transactions you show above are serializable: if you execute transaction 2
strictly before transaction 1, you would end up with the same result.
So there is an equivalent serial execution.
Yours,
Laurenz Albe
stgreSQL
> internally taking a snapshot of the data on the publisher database and
> copying that to the subscriber.
Yours,
Laurenz Albe
ceed in that.
PostgreSQL depends on people that contribute, and your contribution
is valued.
Yours,
Laurenz Albe
LEL
> UNSAFE.
What makes you think that INSERT ... ON CONFLICT takes a savepoint?
Yours,
Laurenz Albe
perhaps active voice can make it even
clearer:
Ordinarily, when logical replication of a table starts,
PostgreSQL takes a snapshot of the table's
data on the publisher database and copies these data to the subscriber
Yours,
Laurenz Albe
depends on or uses
several
columns can be said to be "on the table row". I'd say that the documentation is
correct, but if it gives you trouble, perhaps it should be improved.
And what would you say about this (silly) example:
CREATE TABLE x (a integer, b integer);
CREATE INDEX ON
umentation describes the
"streaming replication protocol" and the "logical streaming replication
protocol".
This is confusing, and I am also sometimes confused in the way you described
above.
I think the mess is too well established to be really cleaned up. But adding
some clarity is a good thing, so +1.
Yours,
Laurenz Albe
for a tutorial rather than for the documentation.
Yours,
Laurenz Albe
On Tue, 2024-09-03 at 11:54 -0400, Greg Sabino Mullane wrote:
> How about something like this?
This patch looks good to me.
Yours,
Laurenz Albe
type" is not the same as "the table has changed
persistence"
and at the same time "a column has changed a default value".
Perhaps "a bitmap of reasons" should simply become "the reason".
Yours,
Laurenz Albe
n time.
+1
Here is a patch for that; it may be the smallest patch I've ever
written for PostgreSQL.
Yours,
Laurenz Albe
From 68eedd01c754ffd2dfbb11cd29f568841d7db7a6 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 24 Jul 2024 12:50:49 +0200
Subject: [PATCH v1] Fix a missing article i
havior in more detail?
It is difficult to help you if you are that unspecific about what exactly
you fail to understand. Sure, there are some complicated concepts involved.
If you can't understand *anything* about that text, perhaps you should
start reading the whole chapter about concurrency.
Yours,
Laurenz Albe
ind new patch version fix_doc_raise_v4.patch,
> please check it out.
Thanks. I have marked the patch as "ready for committer".
Yours,
Laurenz Albe
be more complete.
Suggestions:
Here is a variation of the above example:
A variation of the above example is:
Yours,
Laurenz Albe
..and as far as I could test, in Oracle the IS NULL and IS NOT NULL
> operators are truly dual
That only goes to say that Oracle is not very standard compliant, but
I wouldn't expect anything else from a system where '' IS NULL.
Yours,
Laurenz Albe
documentation. That is, the implementation should behave like the
> documentation suggests.
You are right. I find this in the standard:
COALESCE (V1, V2) is equivalent to the following :
CASE WHEN V1
IS NOT NULL THEN
V1 ELSE
V2 END
That would mean that coalesce(ROW(1,NULL), ROW(2,1)) should return
the second argument. Blech. I am worried about the compatibility pain
such a bugfix would cause...
Yours,
Laurenz Albe
nction returns the first of its arguments that is distinct
> from null. Null is returned only if all arguments are not distinct from null.
+1
Do you want to write a documentation patch?
Yours,
Laurenz Albe
input: use of
> > > upper-case digits
Hexadecimal digits, also known as letters.
Yours,
Laurenz Albe
bout“ the operating system's default
> value in the linux is tcp_keepalive_time kernel parameter”
Documenting the defaults for each supported operating system is not
PostgreSQL's task.
In this article[1], I figured out the defaults for Linux, MacOS
and Windows.
Yours,
Laurenz
ot;? It is perhaps not accurate,
because a Datum need not be stored in a column, but it might be readily
understandable.
Yours,
Laurenz Albe
backup file.
> + least one schema/table in the file to be restored.
>
> Would it make sense to use "import" in some cases instead?
What about calling it "dump file" instead of "file to be restored"?
Yours,
Laurenz Albe
any columns added to the table later
> are automatically replicated.
>
> ~~
>
> I attached a small patch to make the above change.
+1 on that change.
Yours,
Laurenz Albe
EGIN NULL; END;';
SELECT prokind FROM pg_proc WHERE proname = 'noop';
prokind
═
p
(1 row)
Yours,
Laurenz Albe
remote TCP connections.
Then "listen_addresses" could hyperlink to the parameter's documentation.
Yours,
Laurenz Albe
and have
been
granted the predefined role with the ADMIN option)
can GRANT these roles to users and/or other roles ...
Yours,
Laurenz Albe
LECT ('{"a": 1}'::jsonb)['a'];
>
> -- Extract nested object value by key path
> SELECT ('{"a": {"b": {"c": 1}}}'::jsonb)['a']['b']['c'];
>
> -- Extract array element by index
> SELECT ('[1, "2", null]'::jsonb)[1];
You must be using an old PostgreSQL version where that is not yet supported.
Yours,
Laurenz Albe
e, ACCESS SHARE MODE is
permitted."
Yours,
Laurenz Albe
On Tue, 2024-03-19 at 11:04 -0400, Greg Sabino Mullane wrote:
> On Mon, Mar 18, 2024 at 11:58 AM Laurenz Albe
> wrote:
> > I think it is still a good idea to put data files and WAL on different file
> > systems. Perhaps not so much with the intention of distributing I/O ac
rray. Is this the
> intended behavior?
>
> SELECT '{3,1,1,2,2,2}'::int[] - 1; --> {3,2,2,2} as you would expect
> SELECT '{3,1,1,2,2,2}'::int[] - '{1}'::int[]; --> {2,3} instead of
> {3,2,2,2}
There is no harm in documenting that; I propose the at
g I/O across
different disks, but to prevent the data files from filling the WAL disk.
Yours,
Laurenz Albe
ent
version.
Yours,
Laurenz Albe
patch for that page that demonstrates
the lost update and shows how to avoid it using the REPEATABLE READ
isolation level?
Yours,
Laurenz Albe
ted version of the row that is
locked
and returned to the client.
Yours,
Laurenz Albe
lue relative to seq_page_cost will cause the system to
> prefer index scans; reducing it will make index scans look relatively more
> expensive."
The documentation is correct. If the cost of a random I/O operation is
higher, index scans look more expensive, because they perform random I/O.
Yours,
Laurenz Albe
d
2024-02-29 12:00:00 - 1 year = 2024-02-28 12:00:00 - 1 year
I'd say that there is simply no way to make all this consistent,
and the current implementation is what I would intuitively expect.
Yours,
Laurenz Albe
server.'
I think that applies to all options. It would be better to have a general
statement to that effect at the beginning of the "Options" section.
Yours,
Laurenz Albe
On Mon, 2024-02-19 at 09:37 +, PG Doc comments form wrote:
> Page: https://www.postgresql.org/docs/16/sql-security-label.html
>
> FOREIGN TABLE object_name
>
> ...probably should have a following "|", I think?
Absolutely!
Yours,
Laurenz Albe
; That sentence in that location is correct. See “birthday paradox”.
To be more precise: if 15 other transactions are currently running, there
is a bigger chance that at least one of them will want to flush WAL before
"commit_delay" has expired than if there are only 3 other transactions.
Yours,
Laurenz Albe
On Wed, 2024-01-31 at 12:11 +0100, Peter Eisentraut wrote:
> Sprinkled in some of David's suggestions, and pushed.
Thanks; your text is great.
Yours,
Laurenz Albe
gt; What are the differences in privilege checks?
>
> How are the two commands the same and different, semantically?
The difference is revealed by "SELECT session_user".
I think that is pretty clearly described in the SET SESSION AUTHORIZATION
documentation page.
Yours,
Laurenz Albe
On Fri, 2024-01-26 at 19:01 +0530, vignesh C wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
There was a conflict with 46a0cd4cefb.
Updated version attached.
Yours,
Laurenz Albe
From 193d6d6c20f0c2976e0b63f1896978545def3fe8 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
D
On Wed, 2024-01-24 at 15:26 +0100, Daniel Gustafsson wrote:
> > On 24 Jan 2024, at 15:23, Laurenz Albe wrote:
> >
> > On Wed, 2024-01-24 at 11:08 +0100, gp...@free.fr wrote:
> > > for this "ALTER DATABASE" form, it should be mentioned that after
> >
/rewrite/plan/optimize the subsequent (pipelined) queries
> (issued from the same transaction). Neither chapter 55 nor 52 expand on it
> (or it’s hard to spot at least).
No, PostgreSQL is single-threaded (with the exception of parallel query
execution).
Yours,
Laurenz Albe
to the new role; leaving the old role without any direct
> privileges on the object.
> + Multiple privilege entries with the same grantor and grantee are
> consolidated into a single entry.
>
This change is fundamentally OK, although I doubt that we need to get as
detailed
as to how multiple access control items get consolidated.
I think we should say "owner" instead of "recorded owner". Also, is it
necessary
to detail to the level of system catalog columns?
Yours,
Laurenz Albe
Policies
╪═══╪═══╪═╪═══╪══
public │ mytab │ table │ laurenz=arwdDxt/laurenz │ │
(1 row)
Yours,
Laurenz Albe
new owner along with the ownership
But that is what happens.
The permissions are transferred to the new owner, so the old owner doesn't
have any privileges on the object (and, in your case, cannot connect to
the database any more).
Yours,
Laurenz Albe
For months now, I have received this automated reply whenever I post to
this list:
Forwarded Message
From: 471266196 <471266...@qq.com>
To: Laurenz Albe
Subject: 自动回复: Re: SQL command : ALTER DATABASE OWNER TO
Date: 01/24/2024 03:23:31 PM
邮件已收到，我会尽
re transferred to the new owner
+ along with the ownership.
Yours,
Laurenz Albe
On Thu, 2024-01-18 at 15:54 +0100, Peter Eisentraut wrote:
> On 27.11.23 03:30, Laurenz Albe wrote:
> > True; I don't find it documented that all objects in pg_class share a
> > namespace and that constraints are implemented by indexes of the same
> > name. But I thin
e to apply this to PG 16 and master.
I had to read the text twice before I understood it, but I cannot think
of a simpler way to write it.
Yours,
Laurenz Albe
In 99% of all cases, don't create a tablespace in PostgreSQL. Just use
the default tablespace.
In a virtualized environment, don't ever create a tablespace.
Tablespaces were more important back what people had physical boxes
with physical disks of limited size.
There are still some use cases, but they are extremely rare.
Yours,
Laurenz Albe
ronounced "juneek", which
does not start with a vowel.
> I personally thought this part is obscure.
True; I don't find it documented that all objects in pg_class share a
namespace and that constraints are implemented by indexes of the same
name. But I think that the first
On Fri, 2023-11-24 at 13:14 -0500, Bruce Momjian wrote:
> On Thu, Nov 23, 2023 at 08:36:34AM +0100, Laurenz Albe wrote:
> > On Wed, 2023-11-22 at 14:49 -0800, Peter Geoghegan wrote:
> > > I don't think that your proposed wording for this is an improvement.
> >
>
On Fri, 2023-11-24 at 12:29 -0500, Bruce Momjian wrote:
> On Thu, Nov 23, 2023 at 09:29:39AM +0100, Laurenz Albe wrote:
> > On Wed, 2023-11-22 at 11:58 -0500, Bruce Momjian wrote:
> > > Okay, I moved it into the "Note" section that talked about ISO 8601
> > > o
On Wed, 2023-11-22 at 11:58 -0500, Bruce Momjian wrote:
> Okay, I moved it into the "Note" section that talked about ISO 8601
> output with "T", in the attached patch.
Fine by me, except that I would rather have "returns" or "produces"
instead of th
On Wed, 2023-11-22 at 14:49 -0800, Peter Geoghegan wrote:
> I don't think that your proposed wording for this is an improvement.
Well, the existing wording is impenetrable even for someone with some
PostgreSQL knowledge, like me.
Yours,
Laurenz Albe
agree that the paragraph you are trying to improve needs it.
I am not sure about that last sentence you added:
The modification of
EXCLUDED columns has similar interactions.
How do you modify an EXCLUDED column? Are you talking about a BEFORE
INSERT trigger? Reading the original text, I get the impression that
it means "the behavior is obvious if you modify a column that is used
with EXCLUDED in the DO UPDATE clause, but it can also happen if that
column is not user with EXCLUDED".
Perhaps you should omit that sentence for clarity.
Yours,
Laurenz Albe
On Tue, 2023-11-21 at 22:27 -0500, Bruce Momjian wrote:
> I like this six year old patch so would like to apply it to master,
> attached.
+1, since it is arguably a bug fix.
Yours,
Laurenz Albe
1 - 100 of 294 matches
Mail list logo
