I think that
users care more about data corruption than about exact Unicode-compliant
behavior. Anybody who does can use ICU.
People routinely create indexes that involve upper() or lower(), so I'd
say changing their behavior would be a problem.
Perhaps I should moderate my statement: if a change affects only a newly
introduced code point (which is unlikely to be used in a database), and we
think that the change is very important, we could consider applying it.
But that should be carefully considered; I am against blindly following the
changes in Unicode.
Yours,
Laurenz Albe
On Fri, 2024-07-19 at 16:03 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2024 at 2:41 PM Laurenz Albe wrote:
> > I'd be alright with the hint, but I'd say "during making an *incremental*
> > standby backup", because that's the only case where it can h
>
> I moved this feature to a separate patch. It can be committed optionaly or
> later.
>
> pg_restore has options -P, -T, and pg_dump does not have these options. These
> options (functionality) can
> be implemented in pg_dump too, but unfortunately -T is used for different
> purposes (exclude table).
Ah! I didn't realize that -P and -T are the same. So no objections, although
I'm
not sure if anyone will ever want to restore a single variable from a backup.
Yours,
Laurenz Albe
between the first backup and the incremental
backup, and that was not enough to make it work. I had to run
a CHECKPOINT on the primary server.
Does CHECKPOINT on the standby not trigger a restartpoint, or do
I simply misremember?
Yours,
Laurenz Albe
option.
If what you mean is just add some documentation that tells people not
to use unassigned code points if they want to avoid a reindex, I'd say
that is not enough.
Yours,
Laurenz Albe
On Mon, 2024-07-22 at 13:55 -0400, Robert Haas wrote:
> On Mon, Jul 22, 2024 at 1:18 PM Laurenz Albe wrote:
> > I understand the difficulty (madness) of discussing every Unicode
> > change. If that's unworkable, my preference would be to stick with some
> > Unicode v
ly
+qualify the source object by syntax table.column or
+variable.column.
+
I think you mean schema.variable, not
variable.column.
Yours,
Laurenz Albe
t; anything else? :-)
I am somewhat against this feature.
It is too much magic for my taste.
It might be handy for interactive use, but I would frown at an application
that uses code like that, much like I'd frown at "SELECT *" in application code.
Yours,
Laurenz Albe
On Tue, 2024-07-23 at 16:34 +0200, Laurenz Albe wrote:
> CREATE VARIABLE command:
>
> This is buggy:
>
> CREATE VARIABLE str AS text NOT NULL DEFAULT NULL;
>
> Ugh.
>
> SELECT str;
> ERROR: null value is not allowed for NOT NULL session variable
On Mon, 2024-07-22 at 09:37 -0400, Robert Haas wrote:
> On Fri, Jul 19, 2024 at 6:07 PM Laurenz Albe wrote:
> > Here is a patch.
> > I went for both the errhint and some documentation.
>
> Hmm, the hint doesn't end up using the word "standby" anywhere. That
of cache.
> This cache is protected against unwanted repeated write - and can help with
> detection of this situation.
We can leave it as it is. The IMMUTABLE feature need not go into the first
release, so that can be discussed some more later.
Thanks for the new patch set; I'll look at it soon.
Yours,
Laurenz Albe
On Wed, 2024-07-24 at 15:27 -0400, Robert Haas wrote:
> On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote:
> > An incremental backup is only possible if replay would begin from a later
> > checkpoint than the checkpoint that started the previous backup upon
> > wh
e order of the patches in the patch set match such a process?
I'd guess that temporary session variables or ON TRANSACTION END RESET
would be things that can be committed later on, but PL/pgSQL support
should be in the first commit.
What is your approach to that?
Yours,
Laurenz Albe
detail("error codes can only contain digits and ASCII letters.");
> goto failed;
> }
> and we can do this in the beginning after the len check.
isalnum() operates on a single character and depends on the current locale.
See my comments to 3. above.
Please let me know what you think, particularly about the locale problem.
Yours,
Laurenz Albe
On Thu, 2024-07-25 at 16:12 -0400, Robert Haas wrote:
> On Thu, Jul 25, 2024 at 8:51 AM Laurenz Albe wrote:
> > The attached patch uses your wording for the first sentence.
> >
> > I left out the last sentence from your suggestion, because it sounded
> > like it is l
On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote:
> Probably you didn't attach new files - the second patch is not complete. Or
> you didn't make changes there?
Hm. What is missing?
Yours,
Laurenz Albe
e tables on this side
> of the documentation should look alike.
There are only four hypothetical-set aggregate functions, so it is no problem
to find a function in that list.
I would say that it makes sense to apply the proposed patch, even if we
don't sort that short list.
Yours,
Laurenz Albe
clients. We should give them that choice.
I think that you are right.
But what do you tell the users who would not accept that risk?
Yours,
Laurenz Albe
tmt(date) AS SELECT $1;
> EXECUTE stmt(var);
> ERROR: paramid of PARAM_VARIABLE param is out of range
Or does a later patch take care of that?
Yours,
Laurenz Albe
mpany that has a bad idea of security
and cannot be dissuaded from it, you point that out loudly and then
keep going. Trying to subvert the principles of an architecture
very often leads to pain in my experience.
Yours,
Laurenz Albe
ganization says
you should trust.
Yours,
Laurenz Albe
reeze "pg_database".
That caused later updates to the table to fail with
"Could not open file "pg_xact/": No such file or directory."
I think it would increase the robustness of pg_upgrade to
force "vacuum_defer_cleanup_age" to 0 on the
On Mon, 2020-06-15 at 20:59 -0400, Bruce Momjian wrote:
> On Sat, Jun 13, 2020 at 08:46:36AM -0400, Bruce Momjian wrote:
> > On Wed, Jun 10, 2020 at 04:07:05PM +0200, Laurenz Albe wrote:
> > > A customer's upgrade failed, and it took me a while to
> > > figure ou
just as well
imply expert knowledge (think academic degree), and it can denote someone
with the authority to command (there is nothing wrong with "servant", right?
Or do we have to abolish the term "server" too?).
I appreciate that other people's sensitivities might be differe
rant.com
I gave the patch a spin, and it passes regression tests and didn't
cause any problems when I played with it.
No upgrade or dump considerations, of course.
This is a clear improvement.
I'll mark the patch as "ready for committer".
Yours,
Laurenz Albe
index.
That would need special processing for pg_upgrade.
I'd like to hear your opinions.
Yours,
Laurenz Albe
by the restore script. The patch
> does not currently make this change, but it could be added pretty easily
> if that overcomes this objection.
That would be interesting improvements that would make the non-exclusive
backup API easier to use.
Yours,
Laurenz Albe
7;re not going to do that then we should remove it.
Well, it doesn't need fixing, since it is working just fine (for certain
values of "just fine").
I agree with the need to document the problems better.
Yours,
Laurenz Albe
quot;recovery.signal" makes the New Way no
easier than the Old Way - perhaps something like "pg_ctl start_in_recovery"
would have been smarter.
But one instance where we made users unhappy is not justification
for making them unhappy again.
Yours,
Laurenz Albe
pooling is working.
It also helps to estimate the size of the connection pool
required to keep the database busy, which depends on the
percentage of the transaction time that is spent idling.
Yours,
Laurenz Albe
From: Laurenz Albe
Date: Wed, 8 Jul 2020 13:12:42 +0200
Subject: [PATCH] Add session
less than 100
so we het HOT updates there.
That would be less invasive.
Yours,
Laurenz Albe
ansactions is certainly a good thing if it is done
right.
The trade off is the need for a transaction manager, and implementing that
correctly is a high price to pay.
Yours,
Laurenz Albe
in the original patch.
Yours,
Laurenz Albe
2
9 |2
10 |2
(10 rows)
I would have expected either the Fibonacci sequence or
ERROR: aggregate functions are not allowed in a recursive query's recursive
term
Yours,
Laurenz Albe
On Thu, 2020-04-30 at 04:37 +0100, Andrew Gierth wrote:
> "Laurenz" == Laurenz Albe writes:
>
> Laurenz> I played with a silly example and got a result that surprises
> Laurenz> me:
>
> Laurenz> WITH RECURSIVE fib AS (
> Laurenz> SELECT
rom commit 4dded12faad, before which COPY TO also
released the lock immediately.
The early lock release was added in commit bd272cace63, but that
only reflected how the indexes were locked before.
So this behavior seems to go back all the way.
Yours,
Laurenz Albe
On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
> On Fri, May 8, 2020 at 4:58 AM Laurenz Albe wrote:
> > I happened to notice that COPY TO releases the ACCESS SHARE lock
> > on the table right when the command ends rather than holding it
> > until the end of the transac
On Tue, 2020-05-12 at 11:50 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2020-05-11 at 15:43 -0400, Robert Haas wrote:
> > > On Fri, May 8, 2020 at 4:58 AM Laurenz Albe
> > > wrote:
> > > > I happened to notice that COPY TO releases the ACCES
BC.
> >
> > David J.
Since "to_date" is an Oracle compatibility function, here is what Oracle 18.4
has to say to that:
SQL> SELECT to_date('', '') FROM dual;
SELECT to_date('', '') FROM dual
*
ERROR at line 1:
ORA-01841: (full) year must be between -4713 and +, and not be 0
SQL> SELECT to_date('-0001', '') FROM dual;
SELECT to_date('-0001', '') FROM dual
*
ERROR at line 1:
ORA-01841: (full) year must be between -4713 and +, and not be 0
SQL> SELECT to_date('-0001', 'S') FROM dual;
TO_DATE('-0001','S
--
0001-05-01 00:00:00 BC
Yours,
Laurenz Albe
On Wed, 2020-05-13 at 19:29 +0530, Amit Kapila wrote:
> > > > > On Fri, May 8, 2020 at 4:58 AM Laurenz Albe
> > > > > wrote:
> > > > > > I happened to notice that COPY TO releases the ACCESS SHARE lock
> > > > > > on the table ri
and somebody truncated the
> table in the meantime.
I would use "case" rather than "cases" here.
Yours,
Laurenz Albe
On Fri, 2020-05-15 at 10:11 +0530, Amit Kapila wrote:
> Okay, changed, and pushed.
Thank you!
Yours,
Laurenz Albe
the existing data. This seems to be superfluous.
>
> I can work around this by specifying the format per result column instead of
> specifying
> binary for all but this performance bug / anomaly seemed worth reporting.
Did you profile your benchmark?
It would be interesting to know where the time is spent.
Yours,
Laurenz Albe
rgon. The term "client-server
architecture"
that you quote emphasized that.
Perhaps "machine" would be the preferable term, because "host" is more prone to
misunderstandings (except in a networking context).
Yours,
Laurenz Albe
reason for the current behavior,
but I'd favor the second solution. I think as extensions as belonging
to the database rather than the schema; the schema is just where the
objects are housed.
Yours,
Laurenz Albe
ambiguous usage, the definition of "server" must
> clarify the allowed meanings. What's about:
>
> server: Depending on the context, the term *server* denotes:
>
> An IP-port which is offered by any OS. ?
A port is a server? No way.
> A - possibly virtualized - machine
It might be good to disambiguate that, but I don't think that the PostgreSQL
documentation should use the word "server" to mean "machine".
> An abbreviation for the slightly longer term
> "database(s)/cluster server" ??? this will support the
> readability, but not the clarity ???
"Server" is short for "database server" and is a set of processes that listen
for and handle incoming database client requests.
I think that covers all the meanings you quoted from the documentation,
except c), where it is used as shorthand for "server executable".
Yours,
Laurenz Albe
FFERS enabled by default?
> Those who don't need it, always can say BUFFERS OFF — the say as for TIMING.
+1
Yours,
Laurenz Albe
ndamental problem seems that you have got the system wrong.
If you don't trust WE ISSUE TO EVERYBODY, then you shouldn't use
it as a certification authority.
Yours,
Laurenz Albe
t; back-branches, but as an illustration of what the latter could look like I've
> implemented this in 0001.
An important question will be: if we convert to functions that are not
deprecated,
what is the earliest OpenSSL version we can support?
Yours,
Laurenz Albe
unmodified.
I don't know if that is a good enough argument, though.
Currently there is "orafce" which provides DUAL, and it might be
good enough if it defines DUAL as a view on DUMMY.
Yours,
Laurenz Albe
ld be discarded as being overly pedantic.
Yours,
Laurenz Albe
des there's a similarly-named autovacuum_enabled option.
I like "shrink_enabled".
It may sound weird in the ears of PostgreSQL hackers, but will make sense to
users.
Perhaps "vacuum_shrink_enabled" would be even better.
Yours,
Laurenz Albe
oints active at the same time.
Yours,
Laurenz Albe
informal:
3.1.6.8 distinct (of a pair of comparable values): Capable of being
distinguished within a given context.
Informally, not equal, not both null. A null value and a non-null value are
distinct.
Yours,
Laurenz Albe
or just keep looking at the other functions in pg_proc and
> leakproof the ones that can be, I would be happy to write the corresponding
> patches.
Thanks, and I think that every function that can safely be marked leakproof
is a progress!
Yours,
Laurenz Albe
ink that is a good idea and will do the trick for many people.
It will be harder for those whose backup solution is driven by
a central backup software that backs up the file system and just offers
"pre-backup" and "post-backup" hooks.
Yours,
Laurenz Albe
te the backup_label file...
Yours,
Laurenz Albe
o annoy you. I see the problems
with the exclusive backup, and I see how it can hurt people.
I just think that removing exclusive backup without some kind of help
like Andres sketched above will make people unhappy.
Yours,
Laurenz Albe
nging them is as quite a no-brainer as the vacuum_cost_limit, so
> the attached patch just does the vacuum_cost_limit.
>
> I decided to do the times by 10 option that I had mentioned Ensue
> debate about that...
>
> I'll add this to the March commitfest and set the target v
up is in my opinion the safest variant: it refuses
to create a corrupted cluster without manual intervention and gives you a dire
warning to consider if you are doing the right thing.
Yours,
Laurenz Albe
Robert Haas wrote:
> Not sure exactly what value would accomplish that goal.
I think autovacuum_vacuum_cost_limit = 2000 is a good starting point.
Yours,
Laurenz Albe
d to know the contents of "backup_label" *before*
pg_stop_backup(). Is there a good reason why it is pg_stop_backup()
and not pg_start_backup() that provides that information?
Yours,
Laurenz Albe
That's the way it
(mostly) is, so why complicate matters unnecessarily?
Yours,
Laurenz Albe
ostgresql/safe-backup
This just uses bash and psql.
Does that look reasonably safe?
It's probably too big to be introduced into the documentation, but maybe
we could add it to the Wiki.
Yours,
Laurenz Albe
ite
it, I could do it in the "pre" script. But since I have no idea how the
actual backup is performed and how the "backup_label" file is going to
be saved, I thought it best to return the information to the caller and
persist it somewhere, and only the "post" script can actually return the
information.
Yours,
Laurenz Albe
blem in waiting for the customary 5 years.
And yes, a prominent warning in the next major release notes would be
a good thing.
Yours,
Laurenz Albe
database is the best place to persist
data for a database extension, I'd use a table in the extension schema, so I'd
go for 3.
Why is that heavier than 2?
Yours,
Laurenz Albe
we must rush to remove it.
>
> It's not all there is to it though.
>
> This issue leads to extended downtime regularly and is definitely a huge
> 'gotcha' for users, even if you don't want to call it outright broken,
Only if PostgreSQL crashes regularly, right?
Yours,
Laurenz Albe
server is a primary or a standby.
I think that transaction_read_only is good.
If it is set to false, we are sure to be on a replication primary or
stand-alone server, which is enough to know for the load balancing use case.
I deem it unlikely that someone will set default_transaction_read_only to
FALSE and then complain that the feature is not working as expected, but again
I cannot prove that claim.
As Robert said, transaction_read_only might even give you the option to
use the feature for more than just load balancing between replication master
and standby.
Yours,
Laurenz Albe
Tsunakawa, Takayuki wrote:
> From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> > I think that transaction_read_only is good.
> >
> > If it is set to false, we are sure to be on a replication primary or
> > stand-alone server, which is enough to know for the load
WHERE id < 100;
QUERY PLAN
--
Update on laurenz.ios
-> Index Scan using ios_id_idx on laurenz.ios
Output: id, ''::text, ctid
Index Cond: (ios.id < 100)
(4 rows)
Is this low hanging fruit? If yes, I might take a stab at it.
Yours,
Laurenz Albe
On Mon, 2020-02-03 at 14:43 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I noticed that "ctid" in the select list prevents an index only scan:
> > This strikes me as strange, since every index contains "ctid".
>
> There's no provision for an IOS
d_buffers, whereas positive
> values are absolute sizes, and 0 disables the use of ringbuffers.
Sounds reasonable.
I feel that it should be as few GUCs as possible, so I think that
having one per type of operation might be too granular.
This should of course also be a storage parameter that can be
e index or otherwise verifying its
consistency. Be aware that incorrect use of this command can hide
index corruption.
I didn't study the patch in detail, but do I get it right that there will be no
warnings about version incompatibilities with libc collations?
Yours,
Laurenz Albe
superstition like Oracle did.
Yours,
Laurenz Albe
andle ERROR in
> response to an attempted COMMIT would be broken already.
I agree with that.
There is always some chance that someone relies on COMMIT not
throwing an error when it rolls back, but I think that throwing an
error is actually less astonishing than *not* throwing one.
So, +1 for the proposal from me.
Yours,
Laurenz Albe
but not one
of the others, lauch autovacuum with index_cleanup=off.
How would you feel about that?
Yours,
Laurenz Albe
patch is included yet, and perhaps the new counter should
be shown in "pg_stat_user_tables".
Yours,
Laurenz Albe
From fee7443b4b8d965c77f90a631f1245217624bd44 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 3 Mar 2020 16:21:01 +0100
Subject: [PATCH] Autovacuum tables that have re
On Tue, 2020-03-03 at 16:28 +0100, Laurenz Albe wrote:
> As a more substantial base for discussion, here is a patch that:
>
> - introduces a GUC and reloption "autovacuum_vacuum_insert_limit",
> default 1000
>
> - introduces a statistics counter "inserts
ctor to 0.2 so that it
> only has an effect on larger tables, of which generally people only
> have a smallish number of.
Yes, I think that disabling this by default defeats the purpose.
Knowledgeable people can avoid the problem today by manually scheduling
VACUUM runs on insert-only tables
Thanks, Justin, for the review.
I have applied the changes where still applicable.
On Fri, 2020-03-06 at 10:52 +1300, David Rowley wrote:
> On Fri, 6 Mar 2020 at 03:27, Laurenz Albe wrote:
> > On Thu, 2020-03-05 at 19:40 +1300, David Rowley wrote:
> > > 1. I'd go for 2
There is already something about "--synchronous" in the "Description"
section. It might make sense to add the additional information there.
How about the attached patch?
Yours,
Laurenz Albe
From c18b4b384a963e04cc5b5b50537c150858824f0a Mon Sep 17 00:00:00 2001
From
Jesper Pedersen wrote:
> Thanks for the review, and the changes.
>
> However, I think it belongs in the --synchronous section, so what about
> moving it there as attached ?
Works for me.
Marked as "ready for committer".
Yours,
Laurenz Albe
work around the problem
in a way that few people would find surprising.
Yours,
Laurenz Albe
2013 or later on Windows (Andres Freund)
+
+
+
+
+ Use the same functions to open files in frontend and backend code
+ on Windows, thus fixing the "open_datasync"
+ test in "pg_test_fsync" (Laurenz Albe)
+
+
+
.
Similarly, if pg_receivewal is part of
a quorum-based set of synchronous standbys, it won't count towards
the quorum if is set to
remote_apply.
Yours,
Laurenz Albe
e problem, and pg_receivewal
> is not the only synchronous standby in this configuration. The patch
> does not cover that case properly.
I understand the concern, I'm just worried that too much accuracy may
render the sentence hard to read.
How about adding "or priority-based" after "quorum-based"?
Yours,
Laurenz Albe
applies it, so
must not be set to
remote_apply if pg_receivewal
is the only synchronous standby.
Similarly, it is no use adding pg_receivewal to a
priority-based (FIRST) or a quorum-based
(ANY) synchronous replication setup if
is set to
remote_apply.
Yours,
Laurenz Albe
On Thu, 2019-07-18 at 13:56 -0700, Jeff Davis wrote:
> I went ahead and committed this using Thomas's suggestion to remove the
> parentheses.
Thanks for the review and the commit!
Yours,
Laurenz Albe
ynchronous. I am
> finishing with the attached that I would be fine to commit and
> back-patch as needed. Does that sound fine?
It was my first reaction too that this had better be at the top.
I'm happy with the patch as it is.
Yours,
Laurenz Albe
code on the
> way?
Can you explain what the "log file constraints" are?
If it is in any way related, and I can handle it, sure.
Yours,
Laurenz Albe
ection that allows read-write
transactions will be accepted.
- I think the construction with "read_write_host_index" makes the code even more
complicated than it already is.
What about keeping the first successful connection open and storing it in a
variable if we are in "prefer-read" mode.
If we get the read-only connection we desire, close that cached connection,
otherwise use it.
Yours,
Laurenz Albe
Haribabu Kommi wrote:
> > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe
> > wrote:
> > > Haribabu Kommi wrote:
> > >
> > > - I think the construction with "read_write_host_index" makes the code
> > > even more
> > > complica
Windows Server 2012 R2
>
> I think this is a bug.
> I think it has not been fixed in the latest version, is my understanding
> correct?
> If it is correct, I will fix it.
I agree that this is not nice.
How do you propose to fix it?
Yours,
Laurenz Albe
ature like that before, so +1 on the idea.
ALTER USER MAPPING has to be restricted to superusers as well.
Yours,
Laurenz Albe
Thomas Munro wrote:
> It looks like initdb is failing with this patch:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.6732
>
> Unfortunately cfbot is not clever enough to print out the contents of
> the initdb log so I don't have any more information...
Sorry for the d
nits from the last_report for all subsequent reports.
Yes, that would make for better statistics, since client connections
can last quite long.
> * We would need to bump the catalog version since we have made
> changes to system views. Refer: #define CATALOG_VERSION_NO
Again, I think that's up to the committer.
Thanks again!
Yours,
Laurenz Albe
On Wed, 2020-09-30 at 16:27 +0900, Michael Paquier wrote:
> On Fri, Sep 04, 2020 at 01:59:47PM +0200, Laurenz Albe wrote:
> > I'll set the commitfest entry to "waiting for author".
>
> This review, as well as any of the follow-up emails, have not been
> answere
On Fri, 2020-10-02 at 15:10 -0700, Soumyadeep Chakraborty wrote:
> On Tue, Sep 29, 2020 at 2:44 AM Laurenz Albe wrote:
> > > * Are we trying to capture ONLY client initiated disconnects in
> > > m_aborted (we are not handling other disconnects by not accounting for
> &
Thanks for the --- as always --- valuable review!
On Tue, 2020-10-13 at 17:55 -0500, Justin Pryzby wrote:
> On Tue, Oct 13, 2020 at 01:44:41PM +0200, Laurenz Albe wrote:
> > Attached is v3 with improvements.
>
> +
> + Time spent in database sessions in this databas
601 - 700 of 830 matches
Mail list logo
