On Tue, Jan 11, 2022 at 10:50:50AM +0300, Sergey Shinderuk wrote:
> A few comments after a quick glance...
Thanks!
> + * Returns a static string providing errors about an error that happened
>
> "errors about an error" looks odd.
Sure, that could be reworded. What about "providing details
Hi,
On 2022-01-10 10:57:00 -0500, Andrew Dunstan wrote:
> On 10/5/21 15:30, Andres Freund wrote
> > The above ends up dumping all crashes into a single file, but that can
> > probably be improved. But cdb is so gnarly that I wanted to stop looking
> > once
> > I got this far...
FWIW, I figured
Hi,
On 11.01.2022 07:56, Michael Paquier wrote:
> Thoughts?
A few comments after a quick glance...
+ * Returns a static string providing errors about an error that happened
"errors about an error" looks odd.
+static const char *
+SSLerrmessage(unsigned long ecode)
+{
+ if (ecode == 0)
On Mon, Jan 03, 2022 at 03:44:24PM -0600, Justin Pryzby wrote:
> +
> +
> + --no-table-am
> +
> +
> +Do not output commands to select table access methods.
> +With this option, all objects will be created with whichever
> +table access method is
Hi All,
for us also, logs are applying at slave server but very very slow. While
checking we also have seen same set of locks to Master and Slave servers.
Please suggest the solution for that.
Many Thanks in Advance !!
Thanks
On Tue, Jan 11, 2022 at 2:12 AM Allie Crawford <
On Sat, Jan 08, 2022 at 12:48:57PM -0600, Justin Pryzby wrote:
> I fixed it by calling get_restricted_token() before parseCommandLine().
> There's precedent for that in pg_regress (but the 3 other callers do it
> differently).
>
> It seems more ideal to always call get_restricted_token sooner than
On Wed, Jan 05, 2022 at 05:12:41PM +0900, Michael Paquier wrote:
> Rebased patch to cool down the CF bot, as per the addition of
> --no-sync to pg_upgrade.
The CF bot is unhappy, so here is a rebase, with some typo fixes
reported by Justin offlist.
--
Michael
From
Please see attached a small patch to document why some text-processing
functions are marked as leakproof, while some others are not.
This is more or less a verbatim copy of Tom's comment in email thread at
[1].
I could not find an appropriate spot to place these comments, so I placed
them on
On Mon, Jan 10, 2022 at 02:31:38PM -0500, Tom Lane wrote:
>
> So I think we need to fix it to capture the target WAL position
> at the start, as I've done in the attached patch.
+1, it looks sensible to me.
> In principle
> this might make things a bit slower because of the extra
> transaction
On Tue, Jan 11, 2022 at 8:52 AM Masahiko Sawada wrote:
>
> On Mon, Jan 10, 2022 at 8:50 PM Amit Kapila wrote:
> >
> > I was thinking what if we don't advance origin explicitly in this
> > case? Actually, that will be no different than the transactions where
> > the apply worker doesn't apply any
On Tue, Jan 11, 2022 at 11:22 AM Amit Kapila wrote:
>
> On Mon, Jan 10, 2022 at 2:57 PM vignesh C wrote:
> >
> > 2) Can we have an option to specify last_error_xid of
> > pg_stat_subscription_workers. Something like:
> > alter subscription sub1 skip ( XID = 'last_subscription_error');
> >
> >
Hi,
On 2022-01-10 23:44:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
> >> Without the patch, it fails under windows like:
>
> > Ah, yea. It's about matching the declarations in ltree.h with the
> > PG_FUNCTION_INFO_V1() one.
>
> >
On Mon, Jan 10, 2022 at 10:22 AM Amit Kapila wrote:
>
> On Mon, Jan 10, 2022 at 9:42 AM Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > It looks like there's a typo, attaching a tiny patch to fix it.
> >
> > *
> > * When doing logical decoding - which relies on using cmin/cmax of catalog
> >
Hi all,
This is a follow-up of the work done in b69aba7 for cryptohashes, but
this time for HMAC. The main issue here is related to SCRAM, where we
have a lot of code paths that have no idea about what kind of failure
is happening when an error happens, and this exists since v10 where
SCRAM has
Andres Freund writes:
> On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
>> Without the patch, it fails under windows like:
> Ah, yea. It's about matching the declarations in ltree.h with the
> PG_FUNCTION_INFO_V1() one.
> What is bugging me is that I am fairly sure that my local compilers at
On Tue, Jan 11, 2022 at 6:52 AM Peter Smith wrote:
>
> e.g. Perhaps there should be an entirely new page (section 31 ?)
> devoted just to "Logical Replication Filtering" - with subsections for
> "Row-Filtering" and "Col-Filtering".
>
+1. I think we need to be careful to avoid any duplicate
Hi,
On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
> On Mon, Jan 10, 2022 at 07:01:36PM -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
> >
> > This seems like a good idea, but it's failing to apply right now,
> >
On Mon, Jan 10, 2022 at 8:50 PM Amit Kapila wrote:
>
> On Thu, Dec 16, 2021 at 11:12 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> > >
> > > >
> > > > So if skip_xid is already changed, the apply worker would do
> > > > replorigin_advance() with WAL
On Mon, Jan 10, 2022 at 07:01:36PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
>
> This seems like a good idea, but it's failing to apply right now,
> mainly because of some cleanup I did in e04a8059a. As far as I can
>
Hi,
On 2022-01-10 19:01:36 -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
>
> This seems like a good idea, but it's failing to apply right now,
> mainly because of some cleanup I did in e04a8059a. As far as I can
> tell
On Tue, Jan 11, 2022 at 7:52 AM Amit Kapila wrote:
>
> On Mon, Jan 10, 2022 at 2:57 PM vignesh C wrote:
> >
> > 2) Can we have an option to specify last_error_xid of
> > pg_stat_subscription_workers. Something like:
> > alter subscription sub1 skip ( XID = 'last_subscription_error');
> >
> >
On Mon, Jan 10, 2022 at 2:57 PM vignesh C wrote:
>
> 2) Can we have an option to specify last_error_xid of
> pg_stat_subscription_workers. Something like:
> alter subscription sub1 skip ( XID = 'last_subscription_error');
>
> When the user specified last_subscription_error, it should pick
>
Hi justin,
On 2022/01/08 6:56, Justin Pryzby wrote:
On Fri, Jan 07, 2022 at 08:08:57PM +0900, Michael Paquier wrote:
On Fri, Jan 07, 2022 at 06:30:30PM +0900, Tatsuro Yamada wrote:
We should prefix them with pg_catalog as well.
Are you planning to make a patch?
If not, I'll make a patch later
The current documentation updates (e.g. in the v61 patch) for the
Row-Filter are good, but they are mostly about syntax changes and
accompanying notes for the new WHERE clause etc. There are also notes
for subscription tablesync behaviour etc.
But these new docs feel a bit like scattered
I agree, Renaming "index_vacuum_count" can be taken up in a separate discussion.
I have attached the 3rd revision of the patch which also includes the
documentation changes. Also attached is a rendered html of the docs for review.
"max_index_vacuum_cycle_time" has been removed.
On Thu, Sep 23, 2021 at 10:33 PM Tomas Vondra
wrote:
>
> Hi,
>
> I finally had time to take a closer look at the patch again, so here's
> some review comments. The thread is moving fast, so chances are some of
> the comments are obsolete or were already raised in the past.
>
>
...
> 10) WHERE
On 2022-Jan-07, Peter Eisentraut wrote:
> ATExecReplicaIdentity(): Regarding the question of how to handle
> REPLICA_IDENTITY_NOTHING: I see two ways to do this. Right now, the
> approach is that the user can set the replica identity freely, and we
> decide later based on that what we can
I noticed this thread and thought I'd share my experiences building
something similar for Multi-AZ DB clusters [0]. It's not a strict RPO
mechanism, but it does throttle backends in an effort to keep the
replay lag below a configured maximum. I can share the code if there
is interest.
I wrote
On Wed, Apr 14, 2021 at 8:42 AM Dave Page wrote:
> Attached is a patch to clean this up. It will log denials as such
> regardless of whether or not either selinux or sepgsql is in
> permissive mode. When either is in permissive mode, it'll add "
> permissive=1" to the end of the log messages.
Andres Freund writes:
> [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
This seems like a good idea, but it's failing to apply right now,
mainly because of some cleanup I did in e04a8059a. As far as I can
tell given the now-clarified meanings of PGDLLIMPORT/PGDLLEXPORT,
this
On Sun, Jan 9, 2022 at 6:45 PM Zhihong Yu wrote:
>
>
> On Sun, Jan 9, 2022 at 1:27 PM Zhihong Yu wrote:
>
>>
>>
>> On Sun, Jan 9, 2022 at 12:38 PM Zhihong Yu wrote:
>>
>>>
>>>
>>> On Sun, Jan 9, 2022 at 8:48 AM Noah Misch wrote:
>>>
On Sun, Jan 09, 2022 at 04:37:32AM -0800, Zhihong Yu
I have attached a v3 which includes two commits -- one of which
implements the directmgr API and uses it and the other which adds
functionality to use either directmgr or bufmgr API during index build.
Also registering for march commitfest.
On Thu, Dec 9, 2021 at 2:33 PM Andres Freund wrote:
>
On 1/5/22 19:05, Mark Dilger wrote:
>
>> On Jan 4, 2022, at 12:47 PM, Joshua Brindle
>> wrote:
>>
>>> I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
>>> itself. Is that how you did it, or is there yet another way to get into
>>> that state?
>> I did:
>> ALTER
On Sun, Jan 09, 2022 at 11:57:44AM -0800, Andres Freund wrote:
> On 2022-01-09 13:16:50 -0600, Justin Pryzby wrote:
> > diff --git a/contrib/test_decoding/Makefile b/contrib/test_decoding/Makefile
> > index 9a31e0b8795..14fd847ba7f 100644
> > --- a/contrib/test_decoding/Makefile
> > +++
Peter Eisentraut writes:
> I don't think preserving timestamps should be the default behavior, but
> I would support organizing things so that additional options can be
> passed to "install" to make it do whatever the user prefers. But that
> won't work if some installations don't go through
In this version I have addressed these points, except the REPLICA
IDENTITY NOTHING stuff.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"The eagle never lost so much time, as
when he submitted to learn of the crow." (William Blake)
>From
Thomas Munro writes:
> Hmm, one thing I'm still unclear on: did this problem really start
> with 6051857fc/ed52c3707? My initial email in this thread lists
> similar failures going back further, doesn't it? (And what's tern
> doing mixed up in this mess?)
Well, those earlier ones may be
On 1/10/22 15:52, Thomas Munro wrote:
>
> Hmm, one thing I'm still unclear on: did this problem really start
> with 6051857fc/ed52c3707? My initial email in this thread lists
> similar failures going back further, doesn't it? (And what's tern
> doing mixed up in this mess?)
Your list
On Tue, Jan 11, 2022 at 6:00 AM Alexander Lakhin wrote:
> 10.01.2022 12:40, Thomas Munro wrote:
> > This is super quick-and-dirty code (and doesn't handle some errors or
> > socket changes correctly), but does it detect the closed socket?
> Yes, it fixes the behaviour and makes the 002_standby
Thank you so much for your help on this Satya. I have detailed right below the
output of the query you asked me to run.
Master
postgresql@ ~>psql
psql (13.5)
Type "help" for help.
postgresql=# select * from pg_locks;
locktype | database | relation | page | tuple | virtualxid |
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Tue, 2022-01-04 at 22:24 -0500, Stephen Frost wrote:
> > On Tue, Jan 4, 2022 at 18:56 Jacob Champion wrote:
> > >
> > > Could you talk more about the use cases for which having the "actual
> > > user" is better? From an auditing
Seems there is a problem with the replay on your standby. Either it is too
slow or stuck behind some locks ( replay_lag of 20:38:47.00904 indicates
this and the flush_lsn is the same as lsn on primary ) . Run pg_locks to
see if the replay is stuck behind a lock.
On Mon, Jan 10, 2022 at 11:53 AM
Hi All,
I have implemented Stream replication in one of my environments, and for some
reason even though all the health checks are showing that the replication is
working, when I run manual tests to see if changes are being replicated, the
changes are not replicated to the standby postgresql
While trying to make sense of some recent buildfarm failures,
I happened to notice that the default query issued by
the TAP sub wait_for_catchup looks like
SELECT pg_current_wal_lsn() <= replay_lsn AND state = 'streaming' FROM
pg_catalog.pg_stat_replication WHERE application_name = '';
ISTM
On 1/7/22, 12:27 PM, "Robert Haas" wrote:
> On Fri, Jan 7, 2022 at 1:09 PM Bossart, Nathan wrote:
>> While that approach would provide a way to safely retrieve the value,
>> I think it would do little to prevent the issue in practice. If the
>> size of the patch is a concern, we could also
Hi Hackers,
I am trying to migrate my postgres to linux, as we are moving away from
windows.
I am trying both dump/restore and logical decoding, but people are not
happy with performance.
Is there a way/tooling I can use around WAL shipping/physical replication
here ?
thanks
Rajesh
Thanks much for your suggestions,
I am exploring logical decoding because I have two different platforms and
versions as well.
So my best bet is logical decoding, but I am also wondering if somebody has
done replication/migration from windows to linux or vise-a-versa at
physical level with some
On 1/6/22, 6:14 PM, "Imseih (AWS), Sami" wrote:
> I am hesitant to make column name changes for obvious reasons, as it breaks
> existing tooling. However, I think there is a really good case to change
> "index_vacuum_count" as the name is confusing.
> "index_vacuum_cycles_completed" is the
On 10/1/2022 15:39, Julien Rouhaud wrote:
On Mon, Jan 10, 2022 at 03:24:46PM +0500, Andrey Lepikhov wrote:
On 10/1/2022 13:56, Julien Rouhaud wrote:
Yes. the same input query string doesn't prove that frozen query plan can be
used, because rewrite rules could be changed. So we use only a query
Ronan Dunklau writes:
> This has been already discussed a long time ago, and the idea was rejected at
> the time since there was no demand for it:
> https://www.postgresql.org/message-id/flat/BANLkTi%3DaGxDbGPSF043V2K-C2vF2YzGz9w%40mail.gmail.com#da4826d2cbbaca20e3440aadb3093158
I see that one
10.01.2022 12:40, Thomas Munro wrote:
> This is super quick-and-dirty code (and doesn't handle some errors or
> socket changes correctly), but does it detect the closed socket?
Yes, it fixes the behaviour and makes the 002_standby test pass (100 of
100 iterations). I'm yet to find out whether the
Hello,
A colleague of mine was surprised to discover the following statements raised
an error:
postgres=# CREATE TYPE abc_enum AS ENUM ('a', 'b', 'c');
CREATE TYPE
postgres=# CREATE DOMAIN abc_domain AS abc_enum;
CREATE DOMAIN
postgres=# SELECT 'a'::abc_domain = 'a'::abc_domain;
On 10/5/21 15:30, Andres Freund wrote
>
> To actually get the crash reports I ended up doing the following on the OS
> level [5]:
>
> Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows
> NT\CurrentVersion\AeDebug' -Name 'Debugger' -Value '\"C:\Windows
>
On Sun, Jan 9, 2022 at 10:39:58PM -0800, Andres Freund wrote:
> Hi,
>
> On 2022-01-10 01:14:32 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > Fun! That seems to me to be a strong argument for not letting
> > the behavior vary depending on isatty().
>
> Yea.
>
>
> > I think I'd vote
I wrote:
> Aleksander Alekseev writes:
>> 1. Should this behavior be documented in the 9.9.4. AT TIME ZONE
>> section or maybe it's documented elsewhere and I just missed it?
> https://www.postgresql.org/docs/current/datetime-invalid-input.html
... and reading that again, I realize that I
On Mon, Jan 10, 2022 at 4:14 PM Andrew Dunstan wrote:
>
> Pushed, and backpatched.
>
> Great, thanks.
Regards,
Juan José Santamaría Flecha
Aleksander Alekseev writes:
> Due to DST and also changes in local laws, there could be gaps in
> local time [1].
Yup.
> 1. Should this behavior be documented in the 9.9.4. AT TIME ZONE
> section or maybe it's documented elsewhere and I just missed it?
On Mon, Jan 10, 2022 at 03:45:47PM +0100, Daniel Verite wrote:
>
> By that I understand that CREATE DATABASE is limited to copying a template
> database and then not write anything into it beyond that, as it's
> not even connected to it.
Yes.
> I guess there's still the possibility of requiring
On 1/10/22 06:53, Juan José Santamaría Flecha wrote:
>
> On Mon, Jan 10, 2022 at 12:51 PM Juan José Santamaría Flecha
> wrote:
>
> Please find attached a patch for so.
>
> The patch.
>
>
>
>
Pushed, and backpatched.
cheers
andrew
--
Andrew Dunstan
EDB:
Peter Eisentraut writes:
> I think this patch is necessary:
> - if (literallen == 2) /* "U&" */
> + if (literallen == 0)
Seems sensible, and matches the corresponding code in scan.l.
+1.
regards, tom
On 2022-Jan-10, Andrey Borodin wrote:
> 3. The tuple seems to be updated in a high-contention concurrency
> trigger function, autovacuum keeks in ~20-30 seconds after the message
> in logs
Hmm, I bet this is related.
> [ 2022-01-10 09:07:17.671 MSK [unknown],,_s,310759,XX001
Julien Rouhaud wrote:
> > The lack of these fields overall suggest the idea that when CREATE
> > DATABASE is called with a global ICU collation, what if it somehow
> > inserted the collation into pg_collation in the new database?
> > Then pg_database would just store the collation oid and
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Wouldn't using opt_or_replace rule be a better option?
The new
Andres Freund writes:
> On 2022-01-10 01:14:32 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> Fun! That seems to me to be a strong argument for not letting
>> the behavior vary depending on isatty().
> Yea.
> I think just coupling it to verbose mode makes the most sense, for now?
WFM.
I think this patch is necessary:
diff --git a/src/interfaces/ecpg/preproc/pgc.l
b/src/interfaces/ecpg/preproc/pgc.l
index 07fee80a9c..3529b2ea86 100644
--- a/src/interfaces/ecpg/preproc/pgc.l
+++ b/src/interfaces/ecpg/preproc/pgc.l
@@ -753,7 +753,7 @@ cppline
On Mon, Jan 10, 2022 at 12:49:07PM +0100, Daniel Verite wrote:
>
> The "daticucol" column also suggests that we don't expect to add
> other collation providers in the future. Maybe a pair of columns like
> (datcollprovider, datcolllocale) would be more future-proof,
> or a (datcollprovider,
On Fri, Jan 07, 2022 at 03:49:47PM +0900, Michael Paquier wrote:
> Yes, I was waiting for the latest results, but that did not help at
> all. Something is wrong with the patch, I am not sure what yet, but
> that seems like a mistake in the backend part of it rather than the
> tests. I have
Hi hackers,
Due to DST and also changes in local laws, there could be gaps in
local time [1]. For instance, 1 second after "2011-03-27 01:59:59 MSK"
goes "2011-03-27 03:00:00 MSK":
```
select (timestamptz '2011-03-27 01:59:59 MSK') at time zone 'MSK';
timezone
-
On Mon, Jan 10, 2022 at 12:51 PM Juan José Santamaría Flecha <
juanjo.santama...@gmail.com> wrote:
> Please find attached a patch for so.
>
The patch.
>
>
Regards,
>
> Juan José Santamaría Flecha
>
v2-0001-Fix-vcregress-plpython3-warnings.patch
Description: Binary data
On Fri, Jan 7, 2022 at 3:24 PM Andrew Dunstan wrote:
>
> In that case, just this should work:
>
> s/EXTENSION (\S*?)plpython2?u/EXTENSION $1plpython3u/g ;
>
> Please find attached a patch for so. I have also open an item in the
commitfest:
https://commitfest.postgresql.org/37/3507/
Regards,
On Thu, Dec 16, 2021 at 11:12 AM Masahiko Sawada wrote:
>
> On Thu, Dec 16, 2021 at 2:21 PM Amit Kapila wrote:
> >
> > >
> > > So if skip_xid is already changed, the apply worker would do
> > > replorigin_advance() with WAL logging, instead of committing the
> > > catalog change?
> > >
> >
> >
Peter Eisentraut wrote:
> Unlike in the previous patch, where the ICU
> collation name was written in datcollate, there is now a third column
> (daticucoll), so we can store all three values.
I think some users would want their db-wide ICU collation to be
case/accent-insensitive.
On Sat, Jan 8, 2022 at 9:20 AM Bossart, Nathan wrote:
> FWIW I just found this patch very useful for testing some EXEC_BACKEND
> stuff on Linux.
Thanks for testing. Tidied and pushed, to master only for now.
On Mon, Jan 10, 2022 at 03:24:46PM +0500, Andrey Lepikhov wrote:
> On 10/1/2022 13:56, Julien Rouhaud wrote:
> >
> > I don't know the details of that extension, but I think that it should work
> > as
> > long as you have the constants information in the jumble state, whatever the
> > resulting
On 10/1/2022 13:56, Julien Rouhaud wrote:
On Mon, Jan 10, 2022 at 12:37:34PM +0500, Andrey V. Lepikhov wrote:
I think, pg_stat_statements can live with an queryId generator of the
sr_plan extension. But It replaces all constants with $XXX parameter at the
query string. In our extension user
On Mon, Jan 10, 2022 at 10:20 PM Thomas Munro wrote:
> On Mon, Jan 10, 2022 at 8:00 PM Alexander Lakhin wrote:
> > The libpqrcv_PQgetResult function, in turn, invokes WaitLatchOrSocket()
> > where WaitEvents are defined locally, and the closed flag set on the
> > first invocation but expected to
On Fri, Jan 7, 2022 at 11:23 AM Masahiko Sawada wrote:
>
> On Fri, Jan 7, 2022 at 10:04 AM Masahiko Sawada wrote:
> >
> > On Wed, Jan 5, 2022 at 12:31 PM Amit Kapila wrote:
> > >
> > > On Mon, Dec 27, 2021 at 9:54 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Thu, Dec 16, 2021 at 2:42 PM
On Mon, Jan 10, 2022 at 8:00 PM Alexander Lakhin wrote:
> The libpqrcv_PQgetResult function, in turn, invokes WaitLatchOrSocket()
> where WaitEvents are defined locally, and the closed flag set on the
> first invocation but expected to be checked on second.
D'oh, right. There's also a
Hi!
I could not detect crashes with your last patch, so I think the patch is
ready for a review.
Please, also consider fixing error messages, as existing ones don't follow
message writing guidelines.
https://www.postgresql.org/docs/14/error-style-guide.html
Regards, Andrew
On Thu, Dec 23, 2021
> 19 авг. 2021 г., в 21:37, Alvaro Herrera написал(а):
>
> A customer recently hit this error message:
>
> ERROR: t_xmin is uncommitted in tuple to be updated
Hi!
Currently I'm observing this on one of our production clusters. The problem
occurs at random points in time, seems to be
On Mon, Jan 10, 2022 at 12:37:34PM +0500, Andrey V. Lepikhov wrote:
> I think, pg_stat_statements can live with an queryId generator of the
> sr_plan extension. But It replaces all constants with $XXX parameter at the
> query string. In our extension user defines which plan is optimal and which
>
On 06.01.22 06:44, Paul A Jungwirth wrote:
I didn't follow why indexes would have periods, for example, the new
period field in IndexStmt. Is that explained anywhere?
When you create a primary key or a unique constraint (which are backed
by a unique index), you can give a period name to
82 matches
Mail list logo
