nks for the wording ;)
Why not just leave it at plain "done"?
After all, the server was started successfully.
The second message should make sufficiently clear that the server has stopped.
I didn't like the code duplication introduced by the patch, so I rewrote
that part a bit.
Attached is m
order and other locale aspects.
But they care a lot about index corruption.
So I'd argue that we should not have any breaking changes at all, even in
cases where the provider is clearly wrong.
Yours,
Laurenz Albe
.
Based on that, the patch should be rejected.
Since there were a couple of other opinions early in the thread, I'll let
it sit like that for now, and judgement can be passed at the end of the
commitfest. Perhaps somebody else wants to chime in.
Yours,
Laurenz Albe
On Sat, 2024-06-22 at 17:50 -0400, Joseph Koshakow wrote:
> On Mon, Jun 10, 2024 at 1:00 PM Laurenz Albe wrote:
> > Like you, I was surprised by the current behavior. There is a design
> > principle that PostgreSQL tries to follow, called the "Principle of
> > least ast
as designed, but if it is, I think it
should be documented.
Yours,
Laurenz Albe
hink we can safely rule out option 3.
Even if it is a bug, it is not one that has bothered anybody so far that a
backpatch
is indicated.
Yours,
Laurenz Albe
ior and leave it as it is?
Concerning the latter, I am hoping for a detailed description of our
customer's use case some time soon.
Yours,
Laurenz Albe
nformation should go somewhere here:
https://www.postgresql.org/support/versioning/
Yours,
Laurenz Albe
solar year?
- 365, because we don't consider leap years?
- 360, because we use the usual conversion of 1 month -> 30 days?
Yours,
Laurenz Albe
ing from serious
problems and fill up the disk.
But you are probably right that it would be hard to find a default setting
that nobody has quibbles with, and the default can always be changed with
a future patch.
Yours,
Laurenz Albe
From 8e1eeb9cbcb94d9b15eb9ee97956cc4044ff7964 Mon Sep 17 00:00:00
On Fri, 2024-06-14 at 10:10 +0200, Daniel Gustafsson wrote:
> > On 14 Jun 2024, at 10:06, Laurenz Albe wrote:
>
> > So you think we should ignore that compiler warning?
>
> We already do using this in meson.build:
>
> # Similarly disable useless truncation warni
ed buggy and need to take the length into account, as per the
> attached. This only happens when in the undocumented regression test debug
> mode which may be why it's gone unnoticed.
So you think we should ignore that compiler warning?
What about using memcpy() instead of strncpy()?
Yours,
Laurenz Albe
*s in fprintf(), or we could make the "sqlstate" one byte longer.
I think that the second option would be less error-prone.
Yours,
Laurenz Albe
h. Whichever direction
> we go, I think it's worth updating the documentation to make the
> behavior around triggers and roles clear.
I agree: adding a sentence somewhere won't hurt.
I'll do that once the feedback has given me the feeling that I am on
the right track.
Yours,
Laurenz Albe
changes were trimmed only in the below file
> modified: configure
> modified: configure.ac
Did you forget an attachment?
Yours,
Laurenz Albe
son to keep it in the PostgreSQL source tree?
With PostgreSQL's extensibility features, it should be possible to write your
job scheduler as an extension and maintain it outside the PostgreSQL source.
I am sure that the PostgreSQL community will be happy to use the extension
if it is any good.
Yours,
Laurenz Albe
ersion-upgrade
> > extension breakages, so we can judge what caused them.
>
> Yes, that could be a fruitful discussion.
Digging through my commits brought up 6214e2b2280462cbc3aa1986e350e167651b3905,
for one.
Yours,
Laurenz Albe
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
1 - 100 of 693 matches
Mail list logo