somewhat, so if
you don't like the repetition, I'm alright with that. I just thought it might
be worth stating it explicitly.
I think your patch is fine and ready to go.
Yours,
Laurenz Albe
>
possible when a ==
> 0. So on such platforms, it returns the wrong result.
>
> Patch attached.
The patch looks good to me.
Yours,
Laurenz Albe
h solutions.
Kind of a stalemate. Who wants to tip the scales?
Yours,
Laurenz Albe
On Thu, 2023-11-09 at 03:40 +0100, Erik Wienhold wrote:
> On 2023-11-08 13:23 +0100, Laurenz Albe wrote:
> > I wonder how to proceed with this patch. The main disagreement is
> > whether default privileges should be displayed as NULL (less invasive,
> > but more confus
On Wed, 2023-10-25 at 09:45 +0200, Laurenz Albe wrote:
> I can accept that the error is intentional, even though it violated the
> POLA for me. I can buy into the argument that an UPDATE should not make
> a row seem to vanish.
>
> I cannot buy into the constraint argument. If
On Thu, 2023-11-09 at 15:59 +, Dean Rasheed wrote:
> On Thu, 9 Nov 2023 at 15:16, Laurenz Albe wrote:
> > I have thought some more about this, and I believe that if FOR SELECT
> > policies are used to check new rows, you should be allowed to specify
> > WITH CHECK on FOR
On Fri, 2023-11-10 at 09:39 +, Dean Rasheed wrote:
> On Thu, 9 Nov 2023 at 18:55, Laurenz Albe wrote:
> > I think it can be useful to allow a user an UPDATE where the result
> > does not satisfy the USING clause of the FOR SELECT policy.
> >
> > The idea that an
rt" and
"range_contains_elem_support", only to branch based on the function type.
I think the code would be simpler if you did away with "match_support_request"
at all.
I adjusted your patch according to my comments; what do you think?
I also went over the regression t
On Sun, 2023-11-12 at 18:15 +0100, Laurenz Albe wrote:
> I adjusted your patch according to my comments; what do you think?
I have added the patch to the January commitfest, with Jian and Kim as authors.
I hope that is OK with you.
Yours,
Laurenz Albe
g in
code to mitigate the impact of data corruption caused by a crash, invest
in quality code that doesn't crash in the first place.
Euphemistically naming a crash "ORA-600 error" seems to be part of
their strategy.
Yours,
Laurenz Albe
On Mon, 2023-11-13 at 12:57 -0500, Robert Haas wrote:
> On Fri, Nov 10, 2023 at 7:43 AM Laurenz Albe wrote:
> > So, from my perspective, we should never have let FOR SELECT policies
> > mess with an UPDATE. But I am too late for that; such a change would
> > be way too invas
On Mon, 2023-11-13 at 14:28 -0500, Bruce Momjian wrote:
> Patch applied back to PG 16.
Great thanks!
I am hopeful that that will reduce people's confusion about this feature.
Yours,
Laurenz Albe
On Mon, 2023-11-13 at 11:27 +0100, Erik Wienhold wrote:
> On 2023-11-09 20:19 +0100, Tom Lane wrote:
> > Laurenz Albe writes:
> > > Thanks for the feedback. I'll set the patch to "ready for committer"
> > > then.
> >
> > So, just to cl
index column \"%s\" must match collation of the partitioning key
column
This will be backpatched, right? What if somebody already created an index
like that?
Does this warrant an entry in the "however" for the release notes, or is the
case
exotic enough that we can assume that nobody is affected?
Yours,
Laurenz Albe
On Mon, 2023-11-13 at 15:49 -0500, Tom Lane wrote:
> Patch pushed with minor adjustments, mainly rewriting some comments.
Thank you!
Yours,
Laurenz Albe
e could add an INCLUDE clause...
The risk here would be extending standard syntax in a way that might
possibly conflict with future changes to the standard.
Yours,
Laurenz Albe
f a query. I would expect the upper planner to know estimates
and other data about the result of the CTE.
Yours,
Laurenz Albe
essage, something like
redo starts at 12/12345678, taken from control file
or
redo starts at 12/12345678, taken from backup label
Yours,
Laurenz Albe
mittee
might one day come up with a feature like that using a syntax that conflicts
with whatever we introduced on our own.
Yours,
Laurenz Albe
y mode, right?
So why not write "continuing to recover from base backup"?
If we add a message for starting with "backup_label", shouldn't
we also add a corresponding message for starting from a checkpoint
found in the control file? If you see that in a problem report,
you immediately know what is going on.
Yours,
Laurenz Albe
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
; if (pqGetErrorNotice3(conn, true))
> continue;
> status = PGRES_FATAL_ERROR;
> + fprintf(stderr, "Got 'E'\n");
> break;
> case 'A': /* notify message */
> /* handle notify and go back to processing
> return values */
That looks like a leftover debugging message.
Yours,
Laurenz Albe
t I noticed that you use
EXPLAIN in the regression tests. I think that makes the tests vulnerable
to changes in the parameters or in the block size.
Perhaps you can write a function that runs EXPLAIN and extracts just the
row count. That should be stable enough.
Yours,
Laurenz Albe
ROM pg_settings WHERE name = 'timezone';
Yours,
Laurenz Albe
) is that the user
knows "here is a potential problem, have a closer look".
Yours,
Laurenz Albe
I forgot to add that the problem will remain a problem until the
day we start keeping our own copy of the ICU library in the source
tree...
Yours,
Laurenz Albe
On Tue, 2023-11-28 at 07:53 +0900, Michael Paquier wrote:
> On Mon, Nov 27, 2023 at 01:35:44AM -0500, Tom Lane wrote:
> > Laurenz Albe writes:
> > > On Mon, 2023-11-27 at 13:41 +1100, Peter Smith wrote:
> > > > In the documentation and in the guc_tabl
On Thu, 2023-11-30 at 19:22 +0530, Ashutosh Bapat wrote:
> May be attach the patch to hackers thread (this) as well?
If you want, sure. I thought it was good enough if the thread
is accessible via the commitfest app.
Yours,
Laurenz Albe
From ecdce740586e33eeb394d47564b10f813896ff11 Mon Sep
retty clear that CREATE INDEX should be considered
DDL, since it defines (creates) and object. The same should apply to
REINDEX.
Yours,
Laurenz Albe
On Fri, 2023-12-01 at 18:49 +0530, Ashutosh Bapat wrote:
> On Thu, Nov 30, 2023 at 10:29 PM Laurenz Albe
> wrote:
> >
> > On Thu, 2023-11-30 at 19:22 +0530, Ashutosh Bapat wrote:
> > > May be attach the patch to hackers thread (this) as well?
> >
> > If
; What do you think?
I like the idea. But what will happen if the SQL statement references
tables or other objects, since we have no database?
Yours,
Laurenz Albe
Here is a patch to implement this.
Being stuck behind a lock for more than a second is almost
always a problem, so it is reasonable to turn this on by default.
Yours,
Laurenz Albe
From a767e69c724fbbff14114729272be5d29c3d69d8 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 21 Dec 2023 14
to
"deadlock_timeout". So if we want that, we'd need a separate "live
lock detector". I don't know if we want to go there.
Yours,
Laurenz Albe
the required permissions from
herself) is not really about breaking foreign keys. You hit a
surprising error, but referential integrity will be maintained.
Patch v3 is attached.
Yours,
Laurenz Albe
From f47c149edd529dc7f1f39977b3d01ee501e19fab Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date:
nly
useful for certain processing of append-only tables.
Is it worth creating a new SQL statement for that, which could lead to
a conflict with future editions of the SQL standard? Couldn't we follow
the PostgreSQL idiosyncrasy of providing a function with side effects
instead?
Yours,
Laurenz Albe
conservative with back-patching.
Yours,
Laurenz Albe
-side is doomed to failure.
Perhaps. But maybe "printTableContent" could be extended to contain
a boolean array "quote_for_json" that is set in "printTableAddHeader"
based on the underlying data type, similar to how "aligns" is set now.
Detecting array types might be a challenge.
Domains might not be a problem, since "PQftype()" seems to return the
base data type for domain values.
Yours,
Laurenz Albe
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
On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote:
> 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.
I just re
impression that there was more support for
honoring "\pset null" rather than unconditionally displaying "(none)".
The simple attached patch does it like that. What do you think?
Yours,
Laurenz Albe
From 6c67f15f011ddf1e309cb7e84580b266d674a1e2 Mon Sep 17 00:00:00 2001
From: L
On Sat, 2023-10-07 at 05:07 +0200, Erik Wienhold wrote:
> On 2023-10-06 22:32 +0200, Laurenz Albe write:
> > On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > > I wrote a patch to change psql's display of zero privileges after a user's
> > > report
privileges at all, even for the object owner"
would be a better wording.
Perhaps it would also be good to mention this in the psql documentation.
Yours,
Laurenz Albe
On Mon, 2023-10-09 at 03:53 +0200, Erik Wienhold wrote:
> On 2023-10-08 06:14 +0200, Laurenz Albe write:
> > On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > > If you are happy enough with my patch, shall we mark it as ready for
> > > > committer?
>
ta-command's execution
> if the
> user's setting is incompatible.
I am not certain I understood you correctly.
Are you advocating for adding a mention of "\pset null" to every backslash
command
that displays privileges? That is excessive, in my opinion.
Yours,
Laurenz A
On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe wrote:
> > On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> >
> > > The built-in default privileges are only in effect if the object has not
> >
On Mon, 2023-10-09 at 15:13 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > The whole point of this patch is to make psql behave consistently with
> > respect to
> > NULLs in meta-commands.
>
> Yeah. There is a lot of attraction in having \pset null affect the
bjects, reg* data types, ...).
What is inconvenient about storing the output of regprocedure?
Yours,
Laurenz Albe
Index Only Scans for 3 days. The DBAs don't have a lot of control
> over this.
>
> I think we can help users with that by giving them a bit more control
> over when auto-vacuum will run for the table. scale_factor and
> threshold.
Oh, that's a good point.
I only thought about anti-wraparound vacuum, but the feature might be useful
for index-only scans as well.
Yours,
Laurenz Albe
left in the explanation of the purpose of this setting.
Understanding the purpose of the GUCs will make it easier to tune them
correctly.
> 6. Please run the regression tests and make sure they pass. The
> "rules" test is currently failing due to the new column in
ince the parameters have similar semantics, a different wording
would confuse.
Yours,
Laurenz Albe
able_age = freeze_table_age;
> tab->at_params.multixact_freeze_min_age = multixact_freeze_min_age;
> tab->at_params.multixact_freeze_table_age =
> multixact_freeze_table_age;
>
> I think we can set multixact_freeze_min_age to 0 as well.
Ugh, yes, that is a clear oversight.
I have fixed it in the latest version.
Yours,
Laurenz Albe
s?
If you have an insert-only table that has 10 entries, it will get
vacuumed roughly every 2 new entries. The impact is probably too
little to care, but it will increase the contention for the three
autovacuum workers available by default.
Yours,
Laurenz Albe
d party LLVM may be required to build the server's
> llvmjit support. Work around by skipping the default .bc generation if
> no clang is found by PGXS, as if $(with_llvm) was false.
+1
I have struggled with this, as have several users trying to build oracle_fdw.
Yours,
Laurenz Albe
d a paragraph to the documentation that tells people how to
configure the parameters if they want to use it to get index-only scans.
Yours,
Laurenz Albe
hold and high scale factor.
I think all three are viable.
If nobody else wants to weigh in, throw a coin.
Yours,
Laurenz Albe
e a knob then, and patch is laid out already.
>
> > 3. introduce the new parameters with low base threshold and high scale
> > factor.
>
> This looks bad to me. "the bigger the table, the longer we wait" does
> not look good for me for something designed as a measure preventing
> issues with big tables.
Thanks for the feedback.
It looks like we have a loose consensus on #2, i.e. my patch.
Yours,
Laurenz Albe
cuum_cleanup_index_scale_factor uses max: 1e10
> See 4d54543efa5eb074ead4d0fadb2af4161c943044
By setting the threshold very high, or by setting the scale factor to 100.
Yours,
Laurenz Albe
high a
> threshold. If autovacuum runs without FREEZE, I don't see why it couldn't be
> much lower (10?) or use (0.2 * n_ins + 50) like the other autovacuum GUC.
There is the concern that that might treat large table to seldom.
I am curious - what were the findings that led you to think that 1000
is too high?
Yours,
Laurenz Albe
more parameters :^( But your reasoning is good.
How about we go with what we have now and leave that for future
discussion and patches?
Yours,
Laurenz Albe
ws have reached vacuum_freeze_table_age yet.
Then some time later you will get a really large vacuum run.
It seems to me that if we keep trying finding the formula that will vacuum
every table just right and never so the wrong thing, we will never get to
anything.
Yours,
Laurenz Albe
a case for a table having a "really large vacuum run".
Ah, yes, you are right.
So it actually would not be worse if we use the normal freeze_min_age
for insert-only vacuums.
So do you think the patch would be ok as it is if we change only that?
Yours,
Laurenz Albe
uum their table after a bulk insert.
The idea of autovacuum is to do these things for you atomatically.
Yours,
Laurenz Albe
#x27;d have the
> potential for a lot more contention.
I think I got it.
Here is a version of the patch that does *not* freeze more tuples than
normal, except if a prior tuple on the same page is already eligible for
freezing.
lazy_check_needs_freeze() is only called for an aggressive vacuum,
the context of vacuum, it usually
> means "visit all pages, even those which are allvisible".
This is gone in the latest patch.
Updated patch attached.
Perhaps we can reach a consensus on this reduced functionality.
Yours,
Laurenz Albe
From 547481033898f6e8e028
* live_tuples < newly_inserted_tuples
becomes
1000 + 2 * (n + m) < m
which can never be true for non-negative n and m.
So a scale factor >= 1 disables the feature.
Yours,
Laurenz Albe
disabled the feature, it wouldn't make much sense to allow factor up to
> 100.
True, we could set the upper limit to 2, but it doesn't matter much.
Note that this is different from autovacuum_vacuum_scale_factor,
because inserted tuples are live, while dead tuples are not.
Yours,
Laurenz Albe
nsert_scale_factor to 1e10.
Yours,
Laurenz Albe
From cc44042d4a07804a21abe7ad54a8dfafd3162228 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 17 Mar 2020 22:51:46 +0100
Subject: [PATCH] Autovacuum tables that have received only inserts
Add "autovacuum_vacuu
On Tue, 2020-03-17 at 17:26 -0700, Andres Freund wrote:
> On 2020-03-17 01:14:02 +0100, Laurenz Albe wrote:
> > lazy_check_needs_freeze() is only called for an aggressive vacuum, which
> > this isn't.
>
> Hm? I mean some of these will be aggressive vacuums,
eeze_min_age (unless explicitly overridden
for the table)? That might still be high enough not to needlessly
freeze too many tuples that will still be modified, but it will
reduce the impact on insert-only tables.
Yours,
Laurenz Albe
v8 patch.
> With that, and pending one final look, I'd like to push this during my
> Monday (New Zealand time). So if anyone strongly objects to that,
> please state their case before then.
Thanks!
I have rolled your edits into the attached patch v9, rebased against
current master.
Yo
On Thu, 2020-03-19 at 15:17 -0700, Andres Freund wrote:
> I am doubtful it should be committed with the current settings. See below.
>
> > From 3ba4b572d82969bbb2af787d1bccc72f417ad3a0 Mon Sep 17 00:00:00 2001
> > From: Laurenz Albe
> > Date: Thu, 19 Mar 2020 20:26:43 +
her causes for vacuuming).
>
> What am I missing?
Nothing that I can see, and these are good examples why eager freezing
may not be such a smart idea after all.
I think your idea of freezing everything on a page when we know it is
going to be dirtied anyway is the smartest way of going about that.
My only remaining quibbles are about scale factor and threshold, see
my other mail.
Yours,
Laurenz Albe
if you have large
> indexes - which is very common for gin/gist.
Ok, ok. Thanks for the explanation.
In the light of that, I agree that we should increase the scale_factor.
Yours,
Laurenz Albe
On Fri, 2020-03-20 at 14:43 +0100, Laurenz Albe wrote:
> I.e. with the default settings we will perform a whole-index scan
> > (without visibility map or such) after every 10% growth of the
> > table. Which means that, even if the visibility map prevents repeated
> > tables
On Mon, 2020-03-23 at 14:27 +0100, Laurenz Albe wrote:
> Here is version 10 of the patch, which uses a scale factor of 0.2.
This patch should be what everybody can live with.
It would be good if we can get at least that committed before feature freeze.
Yours,
Laurenz Albe
ce new semantics like a reloption value of -2
to disable a feature in this patch right before feature freeze.
I believe there are enough options to disable insert-only vacuuming for
an individual table:
- Set the threshold to 2147483647. True, that will not work for very
large tables, but I think that there are few tables that insert that
many rows before they hit autovacuum_freeze_max_age anyway.
- Set the scale factor to some astronomical value.
Yours,
Laurenz Albe
301 - 400 of 852 matches
Mail list logo
