ing?
> Withholding a commit?
I think it is a good rule. I don't think that it shouldn't lead to putting
people on the pillory or kicking their patches, but I imagine that a committer
looking for somebody else's patch to work on could prefer patches by people
who are doing their share of reviews.
Yours,
Laurenz Albe
is an SQL statement that will run on
a specific database with certain objects in it".
To me, "correct syntax" is the former.
Yours,
Laurenz Albe
On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote:
> Attached is a POC patch that implements that (documentation and
> regression tests are still missing) to form a basis for a discussion.
... and here is a complete patch with regression tests and documentation.
Yours,
Laurenz Alb
would like feedback about:
- is it OK to use "pg_read_all_stats" for that?
- should the check be moved to standard_ExplainOneQuery()?
Yours,
Laurenz Albe
From f31ee5919a9d30f51ff9d54adc7397cb98dfa370 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 6 May 2024 12:43:02 +020
in ordinary backend processes.
Yours,
Laurenz Albe
From 3fe19a7df69d588d6a915450064094ca2066ae33 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Fri, 3 May 2024 14:47:03 +0200
Subject: [PATCH v3] Add parameter log_suppress_errcodes
The parameter contains a list of SQLSTATEs for which
FATAL and
;.
I didn't try it, but I guess that the performance difference will be measurable.
So I wouldn't call it "syntactic sugar".
Perhaps: The behavior of the NOT NULL constraint is like that of a check
constraint with IS NOT NULL.
Yours,
Laurenz Albe
al.
Yes. But I'd argue that that is a shortcoming of logical replication:
there should be a ways to get this information via SQL. Having to look into
the log file is not a very useful option.
The feature will become much less useful if unique voilations keep getting
logged.
Yours,
Laurenz Albe
On Fri, 2024-04-26 at 09:35 +0200, Frédéric Yhuel wrote:
>
> Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
> > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > > I believe that the underlying problem here can be summarized in this
> > > way: just because
convincing. But do we need a GUC for that? What about
making a table eligible for autovacuum as soon as the number of dead
tuples reaches 90% of what you can hold in "autovacuum_work_mem"?
Yours,
Laurenz Albe
here. This can
only improve with buy-in from the committers, and that cannot be forced.
Yours,
Laurenz Albe
ed remote server,
> and I think postgres_fdw is generally intended to work with even
> very old remote servers.
>
> Or we could do both.
I think the first is desirable for reasons of general sanity, and the
second for best compatibility with old versions.
So I vote for "both".
Yours,
Laurenz Albe
On Fri, 2024-03-29 at 14:07 +0100, Laurenz Albe wrote:
> I had a look at patch 0001 (0002 will follow).
Here is the code review for patch number 2:
> diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
[...]
+static bool
+SetupGOutput(PGresult *result, FILE **gfile_fout, bool *i
lies to the change in src/interfaces/libpq/libpq-fe.h
I understand that we need to keep the single-row mode for compatibility
reasons. But I think that under the hood, "single-row mode" should be the
same as "chunk mode with chunk size one".
That should save some code repetition.
Yours,
Laurenz Albe
stuck until they are ready to ugprade to v17.
It is a quite invasive patch, and it adds new features (pg_restore in
bigger transaction patches), so I think this is not for backpatching,
desirable as it may seem from the usability angle.
Yours,
Laurenz Albe
There is no technical content in this mail, but I'd like to
show appreciation for your work on this. I hope this will
eventually remove one of the great embarrassments when using
PostgreSQL: the dependency on operation system collations.
Yours,
Laurenz Albe
ndex op-classes and support
> functions which might be of interest even to non-programmers. I think
> for example that we don't need separate top-level chapters on writing
> procedural language handlers, FDWs, tablesample methods, custom scan
> providers, table access methods, index access methods, and WAL
> resource managers. Some or all of those could be grouped under a
> single chapter, perhaps, e.g. Using PostgreSQL Extensibility
> Interfaces.
I have no strong feelings about that.
Yours,
Laurenz Albe
d in 66 minutes,
so there is some jitter there.
I think the reduced memory footprint and the reduced transaction ID
consumption alone make this patch worthwhile.
Yours,
Laurenz Albe
n's share is the dump file, and that got substantially
smaller. But also the log file shrank considerably, because not every
individual large object gets logged.
I had a look at "perf top", and the profile looked pretty similar in
both cases.
The patch is a clear improvement.
Yours,
Laurenz Albe
ine as the operating system
patches that many companies apply automatically during weekend maintenance
windows. They can also introduce bugs, and everybody knows and accepts that.
Yours,
Laurenz Albe
ption_or_guc), try finding the target block via the FSM, even if
> there's space on the page.
That sounds like a good way forward.
The patch is in state "needs review", but it got review. I'll change it to
"waiting for author".
Yours,
Laurenz Albe
y* place where you can get this information. That
will be a problem for many people, even without "log_suppress_errcodes".
I think that this isformation should be available in some statistics
view.
Yours,
Laurenz Albe
On Sat, 2024-03-09 at 14:03 +0100, Laurenz Albe wrote:
> Here is a patch that implements this.
And here is patch v2 that fixes a bug and passes the regression tests.
Yours,
Laurenz Albe
From 6c72ea7d0aa1df569a4e53f54fcb1a11542ac0ef Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 11
On Thu, 2024-03-07 at 08:30 +0100, Laurenz Albe wrote:
> On Wed, 2024-03-06 at 17:33 -0500, Isaac Morland wrote:
> > I have two questions about this:
> >
> > First, can it be done per role? If I have a particular application which is
> > constantly throwing some par
that role cannot undo or change
the setting. That's just how I plan to implement the new parameter.
Yours,
Laurenz Albe
On Wed, 2024-03-06 at 10:50 -0500, Greg Sabino Mullane wrote:
> On Tue, Mar 5, 2024 at 7:55 AM Laurenz Albe wrote:
> > My experience from the field is that a lot of log spam looks like
> >
> > database/table/... "xy" does not exist
> > duplicate key
names
- ...
I would like to write a simple patch that covers the basic functionality
I described, provided enough people find it useful. That does not
exclude the option for future extensions for this feature.
Yours,
Laurenz Albe
On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> On 11/6/23 14:23, Laurenz Albe wrote:
> > This behavior looks buggy to me. What do you think?
> > I cannot imagine that it is a security problem, though.
>
> How could code getting executed under the wrong role not
ot;log_suppress_sqlstates" that suppresses
logging ERROR and FATAL messages with the enumerated SQL states?
My idea for a default setting would be something like
log_suppress_sqlstates = '23505,3D000,3F000,42601,42704,42883,42P01'
but that's of course bikeshedding territory.
Yours,
Laurenz Albe
e
> still doesn't seem correct even after those words are substituted.
+1
Yours,
Laurenz Albe
On Thu, 2024-02-22 at 10:34 +0900, Michael Paquier wrote:
> This part is done as of 011d60c4352c. I did not evaluate the rest
> yet.
Thanks!
I'm attaching the remaining patch for the Juli commitfest, if you
don't get inspired before that.
Yours,
Laurenz Alb
On Sat, 2024-02-17 at 12:24 -0800, Andres Freund wrote:
> On 2024-02-17 17:48:23 +0100, Laurenz Albe wrote:
> > - Patch 0001 speeds up pq_begintypsend with a custom macro.
> > That brought the binary copy down to 3.7 seconds, which is a
> > speed gain of 15%.
>
> N
%.
- Patch 0003 speeds up array_out a bit by avoiding some zero
byte writes. The measured speed gain is under 2%.
Yours,
Laurenz Albe
From eef8fb5d5a567a1731d8eb6ae24f32a9a0879028 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Sat, 17 Feb 2024 17:12:40 +0100
Subject: [PATCH v1 1/3] Speed up
again and added a new entry in the open commitfest.
Yours,
Laurenz Albe
; I'll defer to the native speaker.
>
> The "in" is more common when spoken. Removed.
The "in" is appropriate for intransitive use:
"I've been here and I've been there and I've been in between."
But: "I have been between here and there."
Do you plan to add it to the commitfest? If yes, I'd set it "ready for
committer".
Yours,
Laurenz Albe
t change
doesn't improve that.
How about:
If a table without a replica identity (explicitly set to
NOTHING,
or set to a primary key or index that doesn't exist) is added ...
Yours,
Laurenz Albe
es. Performing
> a
> + VACUUM operation on the table in between batches can
> help
> + reduce table bloat. The
I think the "in" before between is unnecessary and had better be removed, but
I'll defer to the native speaker.
Yours,
Laurenz Albe
Well, "REPLICA IDENTITY NOTHING" is the same as "has no replica identity".
So is "REPLICA IDENTITY DEFAULT" if there is no primary key, or
"REPLICA IDENTITY USING INDEX ..." if the index is dropped.
See "pg_class": the column "relreplident" is not nullable.
Yours,
Laurenz Albe
ever looks into the log file. The
time when people *do* look into the log file is when they encounter
trouble, and my stance is that the default configuration should be
such that the log contains clues as to what may be the problem.
If a statement sometimes takes unreasonably long, it is very
valuable corroborative information that the statement occasionally
waits more than a second for a lock.
Yours,
Laurenz Albe
On Tue, 2024-01-23 at 16:36 +0100, Christoph Berg wrote:
> Re: Laurenz Albe
> > I am kind of unhappy about this change. It seems awkward and undesirable
> > so have JSON values decorated with weird quoting in JSON output.
> > I understand the motivation, but I bet it's not
ll is as cloudy as anybody's when it comes to guessing the
most likely use cases for the feature, but I'd rather keep it simple and add
features like that later, if there is a demand.
If you import the data into an existing structure, you don't need the metadata.
Yours,
Laurenz Albe
solution would be to omit SQL NULL columns from the output
altogether.
Yours,
Laurenz Albe
allowing us to use incremental-sort to save efforts.
>
> Attached is a patch for this optimization. Any thoughts?
I didn't scrutinize the code, but that sounds like a fine optimization.
Yours,
Laurenz Albe
rom the
output, and the rest left as it currently is?
Yours,
Laurenz Albe
ning 279.779 ms, Optimization 38.395 ms,
Emission 73.105 ms, Total 392.316 ms
Execution Time: 478.257 ms
Yours,
Laurenz Albe
On Tue, 2024-01-16 at 14:12 -0500, Robert Haas wrote:
> On Tue, Jan 16, 2024 at 11:07 AM Laurenz Albe
> wrote:
> > "Round-trip safety" is not so important. If you want to move data from
> > PostgreSQL to PostgreSQL, you use the plain or the binary format.
> >
On Tue, 2024-01-16 at 11:49 -0500, Andrew Dunstan wrote:
> On 2024-01-16 Tu 11:07, Laurenz Albe wrote:
> > On Tue, 2024-01-09 at 16:51 +, Dean Rasheed wrote:
> > > On Tue, 9 Jan 2024 at 14:35, Christoph Berg wrote:
> > > > Getting it print numeric/boolean wi
this
is people who need the result in JSON for further processing somewhere else.
"Round-trip safety" is not so important. If you want to move data from
PostgreSQL to PostgreSQL, you use the plain or the binary format.
The CSV format by default renders NULL and empty strings identical, and
I don't think anybody objects to that.
Yours,
Laurenz Albe
On Thu, 2024-01-11 at 14:44 +0100, Magnus Hagander wrote:
> Thanks, applied and backpatched all the way.
Thanks for taking care of that!
Yours,
Laurenz Albe
On Wed, 2024-01-10 at 13:41 +0100, Magnus Hagander wrote:
> It still reads a bit weird to me. How about the attached wording instead?
Thanks! I am fine with your wording.
Yours,
Laurenz Albe
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
ive with back-patching.
Yours,
Laurenz Albe
ly
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
ermissions 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: Fri, 22 Dec 202
". 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
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
t 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
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
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 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
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_t
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
nows "here is a potential problem, have a closer look".
Yours,
Laurenz Albe
ROM pg_settings WHERE name = 'timezone';
Yours,
Laurenz Albe
ced 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
(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
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
'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
e, 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
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
ng like
redo starts at 12/12345678, taken from control file
or
redo starts at 12/12345678, taken from backup label
Yours,
Laurenz Albe
uery. I would expect the upper planner to know estimates
and other data about the result of the CTE.
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
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
n 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 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 clarify
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 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
tion 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 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
o 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 tests. I did away with the comparison
function, instead
I u
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
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 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 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 co
h solutions.
Kind of a stalemate. Who wants to tip the scales?
Yours,
Laurenz Albe
e when a ==
> 0. So on such platforms, it returns the wrong result.
>
> Patch attached.
The patch looks good to me.
Yours,
Laurenz Albe
hat, 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
>
!privileges of member roles have no affect on object permissions.
> !SET ROLE can be used to change the active user and
> !apply their default privileges.
> !
You don't mean member roles, but roles that the active role is a member of,
right?
How do you like my version, as attach
On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> On 11/6/23 14:23, Laurenz Albe wrote:
> > This behavior looks buggy to me. What do you think?
> > I cannot imagine that it is a security problem, though.
>
> How could code getting executed under the wrong role not
On Mon, 2023-11-06 at 14:23 +0100, Laurenz Albe wrote:
> CREATE FUNCTION trig() RETURNS trigger
> LANGUAGE plpgsql AS
> $$BEGIN
> RAISE NOTICE 'current_user = %', current_user;
> RETURN NEW;
> END;$$;
>
> CREATE CONSTRAINT TRIGGER trig AFTER INSERT
ot imagine that it is a security problem, though.
Yours,
Laurenz Albe
efault privileges will be changed for objects created by
the current role.
Yours,
Laurenz Albe
ied. Perhaps:
[...]; if omitted, the current role is used.
Yours,
Laurenz Albe
;target_role" will *not* be assigned any
privileges.
Perhaps:
Default privileges are changed only for objects created by
target_role. If FOR ROLE
is omitted, the current role is assumed.
Yours,
Laurenz Albe
ot;that locking them"
+statement can be issued without the SKIP LOCKED clause
to ensure
+that no rows were overlooked. This technique has the additional benefit
that it can reduce
+the overal bloat of the updated table if the table can be vacuumed in
between batch updates.
+
"overal" --> "overall"
I don't think you should use "vacuum" as a verb.
Suggestion: "if you perform VACUUM on the table between
individual
update batches".
Yours,
Laurenz Albe
ot; or "not found" in the future.
I agree for names with underscores in them. But I think that quoting
is necessary for names like "timezone" or "datestyle" that might be
mistaken for normal words. My personal preference is to always quote
GUC names, but I think it is OK no
Thanks for having a look at my patch!
On Mon, 2023-10-30 at 15:03 -0700, David G. Johnston wrote:
> On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston
> wrote:
> > On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> > wrote:
> > > On Mon, 2023-10-02 at
On Fri, 2023-10-27 at 16:08 -0700, Jeff Davis wrote:
> On Fri, 2023-10-27 at 08:48 +0200, Laurenz Albe wrote:
> > On Fri, 2023-10-13 at 15:33 -0400, Daniel Fredouille wrote:
> > > sorry it took me some time to reply. Yes, the patch is perfect if
> > > this is indeed
On Fri, 2023-10-27 at 11:34 +0200, Michael Banck wrote:
> On Fri, Oct 27, 2023 at 09:03:04AM +0200, Laurenz Albe wrote:
> > On Fri, 2022-11-04 at 10:49 +0100, Laurenz Albe wrote:
> > > On Thu, 2022-11-03 at 11:32 +0100, Laurenz Albe wrote:
> > > > On Wed, 2022-11-
ertainly should. That is an omission in 482675987b.
Go ahead and write a fix!
> Further to this: it seems that `Alter Subscription X Set(Run_As_Owner=True);`
> has no influence on the `subrunasowner` column of pg_subscriptions.
This seems to have been fixed in f062cddafe.
Yours,
Laurenz Albe
1 - 100 of 676 matches
Mail list logo
