doesn't
> impose any limit.
The message should only be shown if PostgreSQL replays WAL, that is,
after a crash. That would (hopefully) make it a rare message too.
Yours,
Laurenz Albe
that the other notations are
accepted for backward compatibility.
I also think that it would be helpful to emphasize that while dimensionality
does not matter to a column definition, it matters for individual array values.
Perhaps it would make sense to recommend a check constraint if one wants
to make sure that an array column should contain only a certain kind of array.
Yours,
Laurenz Albe
On Thu, 2023-08-17 at 09:37 +0900, Michael Paquier wrote:
> I have just noticed that we do not have a CF entry for this proposal,
> so I have added one with Laurenz as author:
> https://commitfest.postgresql.org/44/4504/
I have changed the author to Fujii Masao.
Yours,
Laurenz Albe
On Thu, 2023-08-24 at 18:23 +0200, Matthias van de Meent wrote:
> On Wed, 19 Jul 2023 at 15:13, Thom Brown wrote:
> >
> > On Wed, 19 Jul 2023, 13:58 Laurenz Albe, wrote:
> > > I agree that the name "max_local_update" could be improved.
> > > Per
pack.
I think this is useful.
To alleviate your concerns, perhaps it would help to describe the use case
and ideas for a good setting in the documentation.
Yours,
Laurenz Albe
artitions are "normal tables".
Agreed, there are differences between partitions and normal tables.
And this is not the place in the documentation where we would like to
get into detail about the differences.
Attached is the next version of my patch.
Yours,
Laurenz Albe
From 33ef30888b5f5
he main
* grammar, rather than here, will still be thrown.
"escontext" is an ErrorSaveContext node, and it is the parser failing.
Not sure if we can do anything about that or if it is worth the effort.
Perhaps the documentation could reflect the implementation.
Yours,
Laurenz Albe
On Mon, 2023-09-18 at 12:22 -0400, Robert Haas wrote:
> On Tue, Sep 5, 2023 at 11:15 PM Laurenz Albe wrote:
> > I don't think that is a good comparison. While most people probably
> > never need to touch "local_update_limit", "work_mem" is something everyb
think that index bloat is a show stopper
these days, when we have REINDEX CONCURRENTLY, so I am not worried.
Yours,
Laurenz Albe
set "local_update_limit" when the
table has shrunk enough. Why not perform that task during vacuum truncation?
If vacuum truncation has taken place, check if the table size is no bigger
than "local_update_limit" * (1 + "autovacuum_vacuum_scale_factor"), and if
it is
ot cool if
something that worked without an error in v15 starts to fail later on.
Yours,
Laurenz Albe
On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
> In v16 and later, the following fails:
>
> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
> COPY boom FROM STDIN;
> ERROR: value too long for type character varying(5)
>
> In Po
On Mon, 2023-09-25 at 17:49 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
> > > On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
> > > > CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
Here is an improved version of the patch with regression tests.
Yours,
Laurenz Albe
From 71744ada1e2c8cfdbb57e03018572a1af623b09e Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 26 Sep 2023 10:09:49 +0200
Subject: [PATCH] Evaluate defaults in COPY FROM only if necessary
Since commit
On Fri, 2023-09-29 at 18:08 -0400, Bruce Momjian wrote:
> On Wed, Sep 6, 2023 at 05:53:56AM +0200, Laurenz Albe wrote:
> > > We may have different mental models here. This relates to the part
> > > that I wasn't keen on in your patch, i.e:
> > >
> > >
tgreSQL behaves differently with other locks.
On the other hand, if nobody has complained about it in these ten years, perhaps
it is just fine the way it is, if by design or not.
Yours,
Laurenz Albe
pulated, and again whenever the distribution of data in
> +their partitions changes significantly.
>
>
>
Yours,
Laurenz Albe
On Sun, 2023-10-01 at 10:55 -0400, Andrew Dunstan wrote:
> Thanks, pushed.
Thanks for taking care of that.
Yours,
Laurenz Albe
);
INSERT INTO parent VALUES (1);
INSERT INTO child VALUES (1);
DELETE FROM parent WHERE id = 1;
TABLE child;
id
1
(1 row)
The trigger function cancels the cascaded delete on "child", and we are left
with
a row in "child" that references no row in "parent".
Yours,
Laurenz Albe
Perhaps it would be enough to run "RI_FKey_noaction_del" after
"RI_FKey_cascade_del", although that would impact the performance.
Yours,
Laurenz Albe
On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> > NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> > silly()
I propose the attached caution.
Yours,
Laurenz Albe
From b6abd7dfdf1e25515ead092489efde0d239f7053 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 3 Oct 2023 09:20:54 +0200
Subject: [PATCH] Document foreign key internals
Warn the user that foreign keys are implemented as triggers, and
tha
batches).
About the UPDATE example:
-
I think that could go, because it is pretty similar to the previous
one. You even use ctid in both examples.
Status set to "waiting for author".
Yours,
Laurenz Albe
re still welcome. One good way to gain experience
is to review others' patches. In fact, you are expected to do that
if you submit your own.
Yours,
Laurenz Albe
sans
> event trigger) be implemented in an extension somehow, or is that not
> technically possible (I suspect not)?
You could perhaps use "object_access_hook" in an extension.
Yours,
Laurenz Albe
On Fri, 2023-10-06 at 12:20 -0400, Bruce Momjian wrote:
> Good points, updated patch attached.
That patch is good to go, as far as I am concerned.
Yours,
Laurenz Albe
NULL are visually indistinguishable and that they may need some
> other way to distinguish them if the difference matters.
>
> So +1 for me fixing \dp to honor "\pset null".
+1
Here is a patch that does away with the special handling of NULL values
in psql backslash commands.
Yours,
Laurenz Albe
On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> Here is a patch that does away with the special handling of NULL values
> in psql backslash commands.
Erm, I forgot to attach the patch.
Yours,
Laurenz Albe
From 6c67f15f011ddf1e309cb7e84580b266d674a1e2 Mon Sep 17 00:00:00 200
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
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
an identity column.
I think this should be backpatched.
Yours,
Laurenz Albe
From ab536da87fa8ffc70469d3dbdaf3e1b84b0ef793 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sun, 14 Apr 2019 17:37:03 +0200
Subject: [PATCH] Make sure identity columns own only a single sequence
If an identity column o
without forbidding anything, since normal OWNED BY dependencies are "auto".
What do you think?
Yours,
Laurenz Albe
a foreign table if the FDW
implements BeginForeignInsert. The attached patch implements that.
I think this should be backpatched to v11.
Yours,
Laurenz Albe
From c4b0e871658c757124dad992578da0b60fccf962 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 20 Apr 2019 13:36:56 +0200
Subject: [PATCH
On Mon, 2019-04-22 at 21:45 +0900, Etsuro Fujita wrote:
Thanks for looking into this!
> (2019/04/20 20:53), Laurenz Albe wrote:
> > On Fri, 2018-04-06 at 23:24 +, Robert Haas wrote:
> > > Allow insert and update tuple routing and COPY for foreign tables.
> > >
On Mon, 2019-04-22 at 16:24 -0400, Robert Haas wrote:
> On Mon, Apr 22, 2019 at 3:37 PM Laurenz Albe wrote:
> > Sure, it is not hard to modify a FDW to continue working with v11.
> >
> > My point is that this should not be necessary.
>
> I'm not sure whether t
On Mon, 2019-04-22 at 13:27 -0700, Andres Freund wrote:
> On 2019-04-22 21:37:25 +0200, Laurenz Albe wrote:
> > Commit 3d956d956a introduced support for foreign tables as partitions
> > and COPY FROM on foreign tables.
> >
> > If a foreign data wrapper supports data mo
FDWs. I think this
> ship simply has sailed.
I can accept that (having fixed my own FDW), but I am worried that it will
cause problems for FDW users. Well, I guess they can always avoid COPY if
they don't want FDWs to crash.
Yours,
Laurenz Albe
mation.
That may wall be a bug in oracle_fdw, since I have no reports of
anybody running it on that operating system.
Maybe you should open an oracle_fdw issue, but I don't know how
much I can help you, since this is the first time I have heard
of SmartOS.
Yours,
Laurenz Albe
broken by that API change as well
if it hasn't been patched.
At the very least, this should have been mentioned in the list of
incompatible changes for v11.
Yours,
Laurenz Albe
y
Multicorn FDW with write support is currently broken.
As Andres has argued above, it is too late to do anything more about
it than to document this and warn FDW authors as good as we can.
Yours,
Laurenz Albe
the problem
> without forbidding anything, since normal OWNED BY dependencies are "auto".
>
> What do you think?
Here is a patch that illustrates the second approach.
I'll add this thread to the next commitfest.
Yours,
Laurenz Albe
From 7f7bae5315b7770f1327a80eb192bb098
t.
>
> These seem a bit redundant to me [...]
>
> OK, how about something like the attached? I reworded this a bit, though.
I like your patch better than my wording.
Thanks for the effort!
Yours,
Laurenz Albe
On Thu, 2019-04-25 at 09:55 +0900, Michael Paquier wrote:
> On Sun, Apr 14, 2019 at 05:51:47PM +0200, Laurenz Albe wrote:
> > test=> INSERT INTO ser (id) VALUES (DEFAULT);
> > ERROR: more than one owned sequence found
>
> Yes this should never be user-triggerable, so
h more intuitive from
the user's perspective.
Correct me if I am wrong, but the sequence behind identity columns
should be an implementation detail that the user doesn't have to know about.
So the error message about "owned sequences" is likely to confuse users.
I have had a report by a confused user, so I think the problem is real.
Yours,
Laurenz Albe
On Sat, 2019-04-27 at 14:16 +0200, Peter Eisentraut wrote:
> On 2019-04-26 15:37, Laurenz Albe wrote:
> > What do you think of the patch I just posted on this thread to
> > remove ownership automatically when the default is dropped, as Michael
> > suggested? I think that w
nfinity',
and adding one to infinity does not change the value.
I propose the attached patch which fixes the problem.
Yours,
Laurenz Albe
I wrote:
> I propose the attached patch which fixes the problem.
I forgot to attach the patch. Here it is.
Yours,
Laurenz Albe
From 6bbad0acf3baae3a08d1f911b7017642c8a8afe9 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 2 May 2019 14:32:27 +0200
Subject: [PATCH] Don't cano
On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
> On 2019-04-29 18:28, Laurenz Albe wrote:
> > I still think thatthat there is merit to Michael's idea of removing
> > sequence "ownership" (which is just a dependency) when the DEFAULT
> > on the col
On Tue, 2019-05-07 at 13:06 +0900, Michael Paquier wrote:
> On Fri, May 03, 2019 at 08:14:35AM +0200, Laurenz Albe wrote:
> > On Thu, 2019-05-02 at 22:43 +0200, Peter Eisentraut wrote:
> >> I think the proper way to address this would be to create some kind of
> >> depe
emote logins
with that user.
But for your application users LDAP authentication is a fine thing, and not
hard to set up if you know a little bit about LDAP.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
subplan, with the correlation vars as the
> cache key.
I like the idea.
I think the cache should be limited in size, perhaps by work_mem.
Also, there probably should be a GUC for this, defaulting to "off".
Yours,
Laurenz Albe
gs nothing.
The attached patch would take care of it, but I'm not sure
if that's the right place to check.
Yours,
Laurenz AlbeFrom d474e7b41298944e43bb9141eb33adbdd9ea1098 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 22 May 2018 18:13:31 +0200
Subject: [PATCH] Don't log
uild the .bc from.
I have been bitten by that when building PostGIS.
A simple patch could fix it, but I agree that it would be better
to not build them.
Yours,
Laurenz Albe
I am worried that there might be loads of Windows installations out there
happily
running productive databases with an unsafe setup, so I'd even suggest
backpatching
such a change.
Yours,
Laurenz Albe
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe wrote:
> > I recently read our documentation about reliability on Windows:
> >
> > > On Windows, if wal_sync_method is open_datasync (the default), write
> > > caching can
> > > be dis
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 8:18 PM, Laurenz Albe wrote:
> > Amit Kapila wrote:
> > > On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> > > wrote:
> > > > I recently read our documentation about reliability on Windows:
> > >
t;
> Thoughts?
I thought of a better way.
pg_test_fsync is properly listed as a server application in the documentation,
so I think it should be built as such, as per the attached patch.
Yours,
Laurenz AlbeFrom 032a0463072097e489f912337ea08f7373a4f107 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
D
Alvaro Herrera wrote:
> On 2018-Mar-01, Laurenz Albe wrote:
>
> > I noticed that commit 25fff40798fc4ac11a241bfd9ab0c45c085e2212 forgot
> > to teach SHOW ALL to show all GUCs when the user belongs to
> > pg_read_all_settings.
> >
> > Patch attached; I think t
and sorry for my long silence.
If I remove the "#ifndef FRONTEND", building with MSVC fails for all
call sites that use the two-argument version of open(2).
If I use the three-argument version throughout, which should be no problem,
PostgreSQL builds just fine with MSVC.
How about chec
he buildfarm thinks about the attached?
>
> +1
I have added it to the July commitfest.
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
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
so important to do it at the end of the relation?
If the answer is "just because we can do it easily", then I think it would be
ok to disable the feature in cases where it causes problems.
Yours,
Laurenz Albe
your hosts list when
> you want prefer-slave.
If you know which is which, certainly.
But in a setup with automated failover you cannot be certain which is which.
That's what the proposed feature targets.
Yours,
Laurenz Albe
uot;? Of course that opens
another way to corrupt your database (by starting it from a backup
without first creating "recovery.conf"), but we could add another
big warning.
I'd say that the people who ignore such a warning are the same
people that happily remove "backup_label" when they see the following
message upon starting a cluster from a backup without recovery:
If you are not restoring from a backup, try removing the file "backup_label".
Yours,
Laurenz Albe
it? That sure wouldn't be unsafe.
If somebody prefers a simpler backup method at the price of having to
manually restart the server after a crash, what's wrong with that?
Why not give them the choice?
I'd say that one could write a server start script that just removes
"backup_label", but I am sure someone will argue that then somebody
will restore a backup and then restart the server without first
recovering the database...
Yours,
Laurenz Albe
t’s a good API while
> ignoring
> the issues that it has doesn’t change that.
I don't think I'm ignoring the issues, I just think there is a valid use case
for
the exclusive backup API, with all its caveats.
Of course I'm not arguing on behalf of organizations running lots of databases
for whom manual intervention after a crash is unacceptable.
I'm arguing on behalf of users that run a few databases, want a simple backup
solution and are ready to deal with the shortcomings.
But I will gladly accept defeat in this matter, I just needed to vent my
opinion.
Yours,
Laurenz Albe
formation, but it sure is
> > inconvenient. Simplicity is good in backup solutions, because complicated
> > things tend to break more easily.
>
> Not sure what communication is necessary here..? The data needed for the
> backup
> label file comes from pg_stop_backup in a non-exclusive backup.
Right, and pg_stop_backup has to be run from the "pre-backup" script.
Yours,
Laurenz Albe
tunately it is not simple to come up with one that doesn't exhibit
the problems of the existing exclusive backup.
Perhaps it's theoretically impossible. The goal is to disambiguate what a file
system backup sees in backup mode and what the startup process sees after a
crash
in backup mode, and I can't see how that could be done.
Yours,
Laurenz Albe
e nonetheless, write into the release notes that certain indexes
have to be rebuilt after upgrade.
Of course, there is no problem to mark pg_config as stable, because
there is little chance it will be used in an index anyway.
Yours,
Laurenz Albe
functions IMMUTABLE
even if they might change owing to bug fixes, I didn't make it clear that
each such occurrence would necessitate a fat warning in the release notes
that indexes using them have to be rebuilt.
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
Peter Eisentraut wrote:
> On 2019-05-08 16:49, Laurenz Albe wrote:
> > I believe we should have both:
> >
> > - Identity columns should only use sequences with an INTERNAL dependency,
> > as in Peter's patch.
>
> I have committed this.
Thanks!
> >
Peter Eisentraut wrote:
> On 2019-05-08 16:49, Laurenz Albe wrote:
> > I believe we should have both:
> >
> > - Identity columns should only use sequences with an INTERNAL dependency,
> > as in Peter's patch.
>
> I have committed this.
Since this is
able, and tuple locks
are *not* maintained there, but in the "xmax" of the row itself.
To see all tuple locks in pg_locks would require a sequential
scan of all tables which have certain locks on them, which is not
going to happen.
Yours,
Laurenz Albe
[CC to -hackers]
Dave Cramer wrote:
> On Mon, 26 Aug 2019 at 13:43,
Laurenz Albe
> wrote:
> > Dave Cramer wrote:
>
> > As I said, I'd entertain a connection parameter that switched the
>
> > CALL to call procedures but ideally you'd complain to the serv
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
501 - 600 of 871 matches
Mail list logo
