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
over time, the use of the older serial
> mechanisms would go away.
I think that would be great.
That might generate some confusion among users who follow old tutorials
and are surprised that the eventual table definition differs, but I'd say
that is a good thing.
Yours,
Laurenz Albe
een, the optimizer always used the statistics of the partitions.
Yours,
Laurenz Albe
From 5209f228f09e52780535edacfee5f7efd2c25081 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 5 Oct 2022 10:31:47 +0200
Subject: [PATCH] Improve autovacuum doc on partitioned tables
The documentation mention
as a full-fledged EXPLAIN (ANALYZE, BUFFERS),
but it can definitely be helpful.
I tied that behavior to the setting of "plan_cache_mode" where you
are guaranteed to get a generic plan; I couldn't think of a better way.
Yours,
Laurenz Albe
From 2bc91581acd478d4648176b58745cadb835d5fbc
hould not be encouraged.
Anybody who knows enough about PostgreSQL to be sure that what they are
doing is correct should be smart enough to know how to edit the copied file.
Yours,
Laurenz Albe
have to go to great lengths
> trying to "unjumble" such queries, so having a way to easily get the answer
> for
> a generic plan would be great.
Thanks for the suggestions and the encouragement. Here is a patch that
implements it with an EXPLAIN option named GENERIC_PLAN.
Yours,
o query ID, no Heap Fetches, no Sort details, ...
Why not add this functionality to the GUC?
0005 suppresses "rows removed by filter", but how is that machine dependent?
> BTW, I think it may be that the GUC should be marked PGDLLIMPORT ?
I think it is project policy to apply this mark wherever it is needed. Do you
think
that third-party extensions might need to use this in C code?
Yours,
Laurenz Albe
On Tue, 2022-10-25 at 19:03 +0800, Julien Rouhaud wrote:
> On Tue, Oct 25, 2022 at 11:08:27AM +0200, Laurenz Albe wrote:
> > Here is a patch that
> > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> I only have a quick look at the patch for now. Any reason why yo
0003 go in, but it currently depends on 0001, which
I am not so sure about.
I understand that you did that so that "explain_regress" can turn off BUFFERS
and there is no extra churn in the regression tests.
Still, it would be a shame if resistance against "explain_regress" would
be a show-stopper for 0003.
If I could get my way, I'd want two separate patches: first, one to turn
BUFFERS on, and second one for "explain_regress" with its current functionality
on top of that.
Yours,
Laurenz Albe
gger. Is this just an incremental patch? If yes, it would
be nice to have a "grand total" patch, so that I can read it all
in one go.
Yours,
Laurenz Albe
eak
configured with "autovacuum_vacuum_cost_delay". Reduce that parameter for more
autovacuum speed.
Yours,
Laurenz Albe
Row-level read and write locks are recorded directly in locked
> +rows and can be inspected using the
> +extension. Row-level read locks might also require the assignment
> +of multixact IDs (mxid). Mxids are recorded in
> +the pg_multixact directory.
"are recorded directly in *the* locked rows"
I think the mention of multixacts should link to
. Again, I would not
specifically mention the directory, since it is already described in
"storage.sgml", but I have no strong optinion there.
> +
> +
> + Subtransactions
> +The word subtransaction is often abbreviated as
> +subxact.
I'd use , not .
> +If a subtransaction is assigned a non-virtual transaction ID,
> +its transaction ID is referred to as a subxid.
Again, I would use , since we don't "subxid"
elsewhere.
+ Up to
+64 open subxids are cached in shared memory for each backend; after
+that point, the overhead increases significantly since we must look
+up subxid entries in pg_subtrans.
Comma before "since". Perhaps you should mention that this means disk I/O.
Yours,
Laurenz Albe
On Mon, 2022-11-07 at 23:04 +0100, Laurenz Albe wrote:
> On Sat, 2022-11-05 at 10:08 +, Simon Riggs wrote:
> > Agreed; new compilation patch attached, including mine and then
> > Robert's suggested rewordings.
>
> Thanks. There is clearly a lot of usefule info
ctions. How is that?
It is better. Did you take my suggestions from [1] into account in your
latest cumulative patch in [2]? Otherwise, it will be difficult to
integrate both.
Yours,
Laurenz Albe
[1]:
https://postgr.es/m/3603e6e85544daa5300c7106c31bc52673711cd0.camel%40cybertec.at
[2]: https://postgr.es/m/Y2nP04/3BHQOviVB%40momjian.us
On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
> > Some comments:
> >
>
> > > --- a/doc/src/sgml/ref/release_savepoint.sgml
> > > +++ b/doc/src/sgml/ref/release_savepoint.sgml
> >
On Thu, 2022-11-10 at 12:17 +0100, Alvaro Herrera wrote:
> On 2022-Nov-10, Laurenz Albe wrote:
> > On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> > > > > - If AND CHAIN is specified, a new
> > > > > transaction is
> > > >
e fault of this patch that the collation isn't there,
but I think it is surprising. What good is a database collation that does not
exist in the database?
What might be the fault of this patch, however, is that "daticurules" is not
set in "pg_database". Looking at the code, that column seems to be copied
from the template database, but cannot be overridden.
Perhaps this only needs more documentation, but I am confused.
Yours,
Laurenz Albe
> What do you think of "--load-via-partition-root=on/off/auto", where
> auto means "not with hash partitions" or the like?
That's perhaps the best way. So users who know that their hash
partitions won't change and want the small speed benefit can have it.
Yours,
Laurenz Albe
On Tue, 2023-01-31 at 13:49 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > [ 0001-Add-EXPLAIN-option-GENERIC_PLAN.v4.patch ]
>
> I took a closer look at this patch, and didn't like the implementation
> much. You're not matching the behavior of PREPARE at all:
On Fri, 2023-02-03 at 09:44 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I played around with it, and I ran into a problem with partitions that
> > are foreign tables:
> > ...
> > EXPLAIN (GENERIC_PLAN) SELECT * FROM looppart WHERE key = $1;
> > ERROR
On Sat, 2023-02-04 at 14:41 +0100, Daniel Verite wrote:
> Laurenz Albe wrote:
>
> > Cool so far. Now I created a database with that locale:
> >
> > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone
> > LOCALE "de_AT.utf8" TE
ag EXEC_FLAG_EXPLAIN_GENERIC.
To avoid having to change all the places that check EXEC_FLAG_EXPLAIN_ONLY
to also check for the new flag, I decided that the new flag can only be
used as "add-on" to EXEC_FLAG_EXPLAIN_ONLY.
Yours,
Laurenz Albe
From cd0b5a1a4f301bb7fad9088d5763989f5dde4636
can change in the
meantime. Think of prepared statements using a generic plan.
Yours,
Laurenz Albe
On Mon, 2023-02-13 at 16:33 -0800, Andres Freund wrote:
> On 2023-02-05 18:24:03 +0100, Laurenz Albe wrote:
> > Anyway, attached is v7 that tries to do it that way.
>
> This consistently fails on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42
tabase
with "ICU_LOCALE x", the rules are not copied over.
I don't know if that is intended or not, but it surprises me.
Should that be a WARNING? Or, since creating a database with a collation
that does not exist in "template0" doesn't make much sense (or does it?),
is there a way to forbid that?
Yours,
Laurenz Albe
o with the default choice of ICU, you should configure your
package manager not to upgrade the ICU library.
Yours,
Laurenz Albe
ons, as far as I know.
Yours,
Laurenz Albe
It adds some value by being simpler and uniform across all platforms.
I'll mark the patch as "ready for committer".
Yours,
Laurenz Albe
> Right, that would be an initdb option. Is that too many initdb options
> then? It would be easy to add, if we think it's worth it.
An alternative would be to document that you can drop "template1" and
create it again using the ICU collation rules you need.
But I'd prefer an "initdb" option.
Yours,
Laurenz Albe
rmats? Maybe there are people using special
> delimiters/terminators and they need them to be treated a certain way
> during comparisons?
I regularly see complaints about the sort order; recently this one:
https://postgr.es/m/cafcrh--xt-j8awoavhb216kom6tqnap35ttveqqs5bhh7gm...@mail.gmail.com
So being able to influence the sort order is useful.
Yours,
Laurenz Albe
but
that can be expected).
I checked the documentation, tested "pg_dump" support, everything fine.
I'll mark it as "ready for committer".
Yours,
Laurenz Albe
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
d the current error message is more crypric than a plain
"you must have a signal file to start from a backup", so perhaps
your patch is a good idea.
Yours,
Laurenz Albe
On Sat, 2023-10-14 at 02:45 +0200, Erik Wienhold wrote:
> On 2023-10-09 09:54 +0200, Laurenz Albe write:
> >
> > I tinkered a bit with your documentation. For example, the suggestion to
> > "\pset null" seemed to be in an inappropriate place. Tell me what you
&
that file will
be
included in the backup. How do you handle that during recovery? Ignore it if
another signal file is present? And if the user forgets to create a signal
file
for recovery, how do you prevent PostgreSQL from performing crash recovery?
Yours,
Laurenz Albe
nything at
> all was very weak. Nobody was being forced to use them, and they broke
> nothing for people who didn't.
+1
Yours,
Laurenz Albe
data directory.
I think it won't meet with favor if there are cases that require manual
intervention
for starting the server. That was the main argument for getting rid of the
exclusive
backup API, which had a similar problem.
Also, how do you envision two concurrent backups with your setup?
Yours,
Laurenz Albe
co-authors, if the patch ever
gets committed.
I'd still like to wait for feedback from David before I change anything.
Yours,
Laurenz Albe
).
So it is clear that we don't have a consensus.
I don't think I want to go ahead with my version of the patch unless
there is more support for it. I can review Erik's original code, if
that design meets with more favor.
> We should probably post on that thread that this one exists and post a link
> to it.
Perhaps a good idea, yes.
Yours,
Laurenz Albe
2 rows)
But that was weird. The operators seem wrong. Look at that
query:
SELECT * FROM tx WHERE t >= 'a' AND t < 'd';
t
═══
a
c
(2 rows)
But the execution plan is identical...
I am not sure what is the problem here, but in my opinion the
operators sh
uot; chapter, and I'd say that the regression tests should be
in "psql.sql" (not that it is very important).
I am not sure how to proceed. Perhaps it would indeed be better to have
two competing commitfest entries. Both could be "ready for committer",
and the committers can decide what they prefer.
Yours,
Laurenz Albe
the locale definition
of the regression test database. If you use "make installcheck", that could
be a different locale.
I think that these tests are not absolutely necessary, and the other tests
are sufficient. Consequently, I took the simple road of removing them.
I also tried to
On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> On Monday, October 23, 2023, Laurenz Albe wrote:
> >
> > --- a/src/bin/psql/describe.c
> > +++ b/src/bin/psql/describe.c
> > @@ -6718,7 +6680,13 @@ static void
> > printACLColumn(PQE
s
"(default)", but are you for or against "\pset null" to have its normal effect
on
the output of backslash commands in all other cases?
Speaking of consensus, it seems to me that Tom, Erik and me are in consensus.
Yours,
Laurenz Albe
the user.
The correct way to do that would be to fake an ACL entry like
"laurenz=arwdDxt/laurenz"
if there is a NULL in the catalog, but that would add a ton of special-case
code to psql, which does not look appealing at all.
So we cannot completely hide the implementation, but perhaps "(default)" would
be less confusing than a NULL value.
If everybody agrees, I can modify the patch to do that.
Yours,
Laurenz Albe
On Mon, 2023-10-23 at 22:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I do believe that we should be against exposing, like in this case, any
> > > internal
> > > implementation detail t
ertainly not to check new rows.
Yours,
Laurenz Albe
TE should not make
a row seem to vanish.
I cannot buy into the constraint argument. If the table owner wanted to
prevent you from causing a constraint violation error with a row you
cannot see, she wouldn't have given you a FOR UPDATE policy that allows
you to perform such an UPDATE.
Anyway, it is probably too late to change a behavior that has been like
that for a while and is not manifestly buggy.
Yours,
Laurenz Albe
want it to fall between the cracks.
Yours,
Laurenz Albe
On Mon, 2023-01-09 at 16:40 +0100, Laurenz Albe wrote:
> > "Using ONLY to add or drop a constraint on only the partitioned table is
> > supported as long as there are no partitions. Once partitions exist, using
> > ONLY will result in an error. Instead, constraints on the pa
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-02 at 19:29 +, David Burns wrote:
> >
> > > Some additional clarity in the versions 14/15 documentation would be
> > > helpf
hould. 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
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-
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
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 09:49 -0400, Tom
like "table" 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
nce, at which point the
same
"that the locking" --> "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
;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
ied. Perhaps:
[...]; if omitted, the current role is used.
Yours,
Laurenz Albe
lt privileges will be changed for objects created by
the current role.
Yours,
Laurenz Albe
imagine that it is a security problem, though.
Yours,
Laurenz Albe
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 AF
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
; !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,
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
401 - 500 of 871 matches
Mail list logo
