On 2020-11-20 08:25, Peter Eisentraut wrote:
On 2020-11-10 16:21, Georgios Kokolatos wrote:
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is
adt/like.c.func-sort-c.html>.
From e6af4a7baa2703cc8239a3e9670d21ef36009e90 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 11 Feb 2021 14:21:06 +0100
Subject: [PATCH] Add tests for bytea LIKE operator
Add test coverage for the following operations, which were previously
not tested at all:
.)From fcfd4f1702f0cef7d0f6564aff94c4a6258f24e6 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 2 Dec 2021 08:08:44 +0100
Subject: [PATCH] Replace uses of deprecated Python module distutils.sysconfig
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig be
There is another snowball release out, and I have prepared a patch to
integrate it. Since it's quite big and mostly boring, I'm not attaching
it here, but you can see it at
https://github.com/petere/postgresql/commit/11eade9302d0a737a12f193c41160fb895c0bc67.patch
The upstream release notes ar
I was thinking a bit about formulating a policy for pg_dump backward
compatibility, based on the discussions in this thread.
Premises and preparatory thoughts:
- Users (and developers) want pg_dump to support server versions that
are much older than non-EOL versions.
- Less critically, much-l
On 02.12.21 10:42, Daniel Gustafsson wrote:
On 2 Dec 2021, at 06:07, Kyotaro Horiguchi wrote:
At Thu, 02 Dec 2021 13:54:41 +0900 (JST), Kyotaro Horiguchi
wrote in
As discussed in the thread [1], I find the wording "SSL server
certificate revocation list" as misleading or plain wrong.
FWIW,
On 02.12.21 07:48, Amit Kapila wrote:
a. ALTER SUBSCRIPTION ... [SET|RESET] SKIP TRANSACTION xxx;
b. Alter Subscription SET ( subscription_parameter [=value]
[, ... ] );
c. Alter Subscription On Error ( subscription_parameter
[=value] [, ... ] );
d. Alter Subscription SKIP ( subscription_par
On 24.11.21 05:20, Michael Paquier wrote:
On Mon, Nov 22, 2021 at 11:21:52AM +0100, Peter Eisentraut wrote:
On 19.11.21 08:31, Michael Paquier wrote:
Regarding 0001, I find the existing code a bit more self-documenting
if we keep those checks flagInhAttrs() and guessConstraintInheritance().
So
On Fri, Dec 3, 2021 at 12:59 AM Euler Taveira wrote:
>
> On Thu, Dec 2, 2021, at 4:18 AM, Peter Smith wrote:
>
> PSA a new v44* patch set.
>
> It includes a new patch 0006 which implements the idea above.
>
> ExprState cache logic is basically all the same as before
On Thu, Dec 2, 2021 at 2:32 PM tanghy.f...@fujitsu.com
wrote:
>
> On Thursday, December 2, 2021 5:21 AM Peter Smith
> wrote:
> >
> > PSA the v44* set of patches.
> >
>
> Thanks for the new patch. Few comments:
>
> 1. This is an example in publication doc,
On 23.11.21 16:09, Alvaro Herrera wrote:
In init_fork(), there's a typo:
+* For tables, the AM callback creates both the main and the init fork.
should read:
+* For tables, the AM callback creates both the main and the init forks.
I believe the original wording is correct.
Ov
If my patch to unite vacuum verbose and the autovacuum logging gets in,
then this issue also goes away.
Peter Geoghegan
(Sent from my phone)
On 02.12.21 19:30, Tom Lane wrote:
Generally +1, but I see you removed some instances of
--- ensure consistent test output regardless of the default bytea format
-SET bytea_output TO escape;
I think that the principle still applies that this should work regardless
of the installation's default
On 02.12.21 19:22, Tom Lane wrote:
That's surely no problem in HEAD, but as you say, it is an issue for
the older branches. How difficult would it be to teach configure to
try both ways, or adapt based on its python version check?
I think it wouldn't be unreasonable to do that. I'll look into
On 02.12.21 18:30, Tom Lane wrote:
This assumes a yearly major release cadence.
If the point is to not have to count dates carefully, why does the cadence
matter?
If we were to change the release cadence, then it would be appropriate
to review this policy.
I can get behind something rough
On 02.12.21 23:16, Andres Freund wrote:
I think we should at least include pg_upgrade in this as well, it's pretty
closely tied to at least pg_dump.
right
* pg_dump and psql will maintain compatibility with servers at least
ten major releases back.
Personally I think that's too long... I
n 100% of all the pages ANALYZE samples are
PageIsAllVisible() pages? I think that it shouldn't be too hard to
come up with solutions to those problems (the extrapolation idea
already hints at a solution), but for now I'd like to keep the
discussion high level.
[1]
https://postgr.es/m/CAH2-Wz=9r83wcwzcpuh4fvpedm4znzbzmvp3rt21+xhqwmu...@mail.gmail.com
--
Peter Geoghegan
On Fri, Dec 3, 2021 at 11:02 AM Bossart, Nathan wrote:
>
> On 8/8/21, 11:54 PM, "Peter Smith" wrote:
> > v11 -> v12
> >
> > * A rebase was needed due to some recent pgindent changes on HEAD.
>
> The patch looks correct to me. I have a couple of small
On Sat, Dec 4, 2021 at 10:13 AM Euler Taveira wrote:
>
> On Thu, Dec 2, 2021, at 4:18 AM, Peter Smith wrote:
>
> PSA a new v44* patch set.
>
...
> I used the last patch series (v44) posted by Peter Smith [1]. I did a lot of
> improvements in this new version (v45). I merged
On 06.12.21 07:51, Tom Lane wrote:
TBH, I am not convinced that the complained-of case is enough of a
problem to justify any change in our build rules, even if there
weren't any semantic issues. If you are worried about build times,
you should be using ccache, and IME builds using ccache are n
On 06.12.21 12:15, Michael Paquier wrote:
FWIW, I am not on board with changing build semantics or any
assumptions the header installation relies on either, but I could see
a point in switching back to INSTALL_DATA instead of cp to be
consistent with the rest of the build, iff the argument made b
On 01.12.21 22:59, Bossart, Nathan wrote:
On 12/1/21, 10:29 AM, "Peter Eisentraut"
wrote:
The attached patch fixes this by accepting the argument using
PG_GETARG_INT32(), doing some checks, and then casting it to unsigned
for the rest of the code.
The patch also fixes another ina
On Tue, Dec 7, 2021 at 6:07 AM Bossart, Nathan wrote:
>
> On 12/5/21, 9:21 PM, "Michael Paquier" wrote:
> > On Mon, Dec 06, 2021 at 11:28:12AM +1100, Peter Smith wrote:
> >> For the initialization of opts I put memset within the function to
> >> make it
ifically that there are very few or even 0 all-visible pages), it
wouldn't hurt us at all, and we wouldn't need to have special
pgstat_report_vacuum()-only heuristics.
--
Peter Geoghegan
On Mon, Dec 6, 2021 at 2:37 PM Peter Geoghegan wrote:
> On Mon, Dec 6, 2021 at 12:07 PM Robert Haas wrote:
> > So does this. If some of the table is now all-visible when it wasn't
> > before, it's certainly a good guess that the portions that still
> > aren't
pret dead tuples with the intention of capturing
some of that, as a medium term solution. Something that considers the
concentration of dead tuples in heap pages seems promising.
--
Peter Geoghegan
need further discussion.
With luck, soon everything can be more in sync again.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
hed patch for a
correction, but do check what your intent was.
As mentioned before, we probably don't need the skip-sequences option
in test_decoding.From 2dd9a0e76b9496016e7abebebd0006ddee72d3c1 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 7 Dec 2021 14:19:42 +0100
Subjec
On 03.12.21 03:53, Amit Kapila wrote:
I don't know how difficult it would be, but allowing multiple xids might
be desirable.
Are there many cases where there could be multiple xid failures that
the user can skip? Apply worker always keeps looping at the same error
failure so the user wouldn't k
On 06.12.21 19:28, Robert Haas wrote:
Speaking of parameter descriptions, the trickiest part of this whole
thing appears to be how to get transparently encrypted data into the
database (as opposed to reading it out). It is required to use
protocol-level prepared statements (i.e., extended query)
On 06.12.21 21:44, Jacob Champion wrote:
I think reusing a zero IV will potentially leak more information than
just equality, depending on the cipher in use. You may be interested in
synthetic IVs and nonce-misuse resistance (e.g. [1]), since they seem
like they would match this use case exactly.
On 03.12.21 15:28, Bharath Rupireddy wrote:
I'm thinking of adding the above steps into the "Additional Supplied
Modules" section documentation. Any thoughts please?
[1] - https://www.postgresql.org/docs/devel/contrib.html
The chapter about extensions is probably better:
https://www.postgresq
On 02.12.21 22:22, Tom Lane wrote:
My first thought about fixing point 1 was to put "char" into some
other typcategory, but that turns out to break some of psql's
catalog queries, with results like:
regression=# \dp
ERROR: operator is not unique: unknown || "char"
LINE 16:E' (' || p
On 03.12.21 19:42, Chapman Flack wrote:
Is there any way to find out, from the catalogs or in any automatable way,
which types are implemented with a dependence on the database encoding
(or on some encoding)?
What is this needed for? C code can internally do whatever it wants,
and the databas
tever we do gather, we should try our best to make accurate. If
> that doesn't work well, then gather different stuff instead.
It's important to be accurate, but it's also important to be tolerant
of model error, which is inevitable. We should make pragmatic
decisions about what kinds of errors our new model will have. And it
should have at least a rudimentary ability to learn from its mistakes.
--
Peter Geoghegan
k that this final number needs to be denominated in abstract
units -- we need to call those abstract units *something*. I don't
care what that name ends up being, as long as it reflects reality.
--
Peter Geoghegan
el signal (from the stats)?
That's the high level intuition behind making "bloat units" a
probability density function, and not just a simple expected value.
Teaching the autovacuum.c scheduler to distinguish signal from noise
could be very valuable, if it enables opportunistic batching of work,
or off-hours work. We don't have to respect noise. The devil is in the
details, of course.
--
Peter Geoghegan
On Wed, Dec 8, 2021 at 2:51 PM Michael Paquier wrote:
>
> On Tue, Dec 07, 2021 at 08:12:59AM +1100, Peter Smith wrote:
> > On Tue, Dec 7, 2021 at 6:07 AM Bossart, Nathan wrote:
> >> Attached a v14 with the initializations added back.
> >
> > LGTM.
>
> All
in_messages;
--- fail - "a" is not in REPLICA IDENTITY INDEX
CREATE PUBLICATION testpub6 FOR TABLE rf_tbl_abcd_nopk WHERE (a > 99);
+-- fail - "a" is not in REPLICA IDENTITY INDEX
+update rf_tbl_abcd_nopk set a = 1;
The "update" DML should be uppercase "UPDATE" for consistency with the
surrounding tests.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On 08.12.21 01:23, Tomas Vondra wrote:
The argument "create" for fill_seq_with_data() is always true (and
patch 0002 removes it). So I'm not sure if it's needed. If it is, it
should be documented somewhere.
Good point. I think it could be removed, but IIRC it'll be needed when
adding sequenc
On 02.12.21 01:17, Paul Martinez wrote:
Regarding that specific example, in a production scenario, yes, the
DELETE command should reference both columns. And if used for
documentation both columns should be referenced for clarity/correctness.
Ok, thanks. I have updated your example accordingly
On 08.12.21 07:27, Michael Paquier wrote:
I saw that Tom updated it within the last 12 months, which I took to mean that
it was still being maintained. But I'm okay with removing it.
Yes, I saw that as of bf8a662. With 42 incorrect reports, I still see
more evidence with removing it. Before do
written and I've had this
on my list for, uh, 7 years.From d1e2df592b7eaa7952d621266d5ad5d6b80e503a Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 8 Dec 2021 14:20:57 +0100
Subject: [PATCH] Readd use of TAP subtests
Since 405f32fc49609eb94fa39e7b5e7c1fe2bb2b73aa, Test::More must b
Hi.
Some regex exposed a bunch of typos scattered across PG comments and docs.
They are all of the "uses-an-instead-of-a" (or vice versa) variety.
PSA a small patch to fix them.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
v1-0001-Fix-typos-for-an-versus-a.patch
Descripti
x for this was integrated into v45 [1]
--
[1]
https://www.postgresql.org/message-id/CAFPTHDYB4nbxCMAFQGowJtDf7E6uBc%3D%3D_HupBKy7MaMhM%2B9QQA%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
On Thu, Dec 9, 2021 at 11:12 AM Michael Paquier wrote:
>
> On Thu, Dec 09, 2021 at 07:30:48AM +1100, Peter Smith wrote:
> > Some regex exposed a bunch of typos scattered across PG comments and docs.
> >
> > They are all of the "uses-an-instead-of-a" (or vice v
On Tue, Nov 30, 2021 at 5:09 PM Peter Geoghegan wrote:
> Attached draft patch attempts to explain things in this area within
> the nbtree README. There is a much shorter comment about it within
> vacuumlazy.c. I am concerned about GiST index-only scans themselves,
> of course, but
, I missed that as this comes from ./configure we don't need to
> change anything as this file is generated by autoconf. I have applied
> the rest.
Thanks for pushing.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On 02.12.21 08:20, Peter Eisentraut wrote:
Buildfarm impact:
gaur and prariedog use Python 2.6 and would need to be upgraded.
Tom, are you planning to update the Python version on these build farm
members? I realize these are very slow machines and this might take
some time; I'm
On 03.12.21 21:13, Tom Lane wrote:
Andrew Dunstan writes:
On 12/3/21 14:42, Tom Lane wrote:
Right, I envisioned that ASCII behaves the same but we'd use
a numeric representation for high-bit-set values. These
cases could be told apart fairly easily by charin(), since
the numeric representatio
On 09.12.21 03:44, Thomas Munro wrote:
On Thu, Dec 9, 2021 at 11:46 AM Andres Freund wrote:
Is it perhaps time to to use unix sockets on windows by default
(i.e. PG_TEST_USE_UNIX_SOCKETS), at least when on a new enough windows?
Makes sense to get this to work, at least as an option.
Makes s
oyances, such as compiler warnings
or unwanted test output, as long as you aren't changing user-facing
behavior". I now think that it'd be reasonable to include this
last group, although I'm pretty sure Peter didn't have that in mind
in his policy sketch.
I would be okay with that.
On 09.12.21 15:04, Himanshu Upadhyaya wrote:
1)
Why we don't support KEY(however is optional as per SQL standard) keyword?
SELECT JSON_OBJECT(KEY 'a' VALUE '123');
ERROR: type "key" does not exist
LINE 1: SELECT JSON_OBJECT(KEY 'a' VALUE '123');
ORACLE is supporting the above syntax.
I can see
On 07.12.21 19:49, Jacob Champion wrote:
= Implicit TLS =
Reactions to implicit TLS were mixed, from "we should not do this" to
"it might be nice to have the option, from a technical standpoint".
Both a separate-port model and a shared-port model were tentatively
proposed. The general consensus
On 07.12.21 21:24, Tom Lane wrote:
I wrote:
Peter Eisentraut writes:
Could we add explicit casts (like polcmd::text) here? Or would it break
too much?
I assumed it'd break too much to consider doing that. But I suppose
that since a typcategory change would be initdb-forcing anyway,
On 08.12.21 18:31, Tom Lane wrote:
A question that seems pretty relevant here is: what exactly is the
point of using the subtest feature, if we aren't especially interested
in its effect on the overall test count? I can see that it'd have
value when you wanted to use skip_all to control a subset
e of any specific need for it.
Perhaps there is an argument for it.
--
Peter Geoghegan
On Thu, Dec 9, 2021 at 1:04 PM Peter Geoghegan wrote:
> On Thu, Dec 9, 2021 at 11:28 AM John Naylor
> wrote:
> > Now that we have a concept of a fail-safe vacuum, maybe it would be
> > beneficial to skip a vacuum in single-user mode if the fail-safe
> > criteria were not
autovacuum_freeze_max_age (and autovacuum_multixact_freeze_max_age)
settings, with sanity checks.
We could then apply this criteria in new code that implements this
"big red button" (maybe this is a new option for the postgres
executable, a little like --single?). Something that's reasonably
targeted, and dead simple to use.
--
Peter Geoghegan
gress indicator.
We could still have a separate option for the postgres executable,
just to invoke single-user mode and call this function. It would
mostly just be window dressing, of course, but that still seems
useful.
--
Peter Geoghegan
whatever work is required for the system to be able
to allocate XIDs again -- but not too much more (not until things are
back to normal). Now the plan is starting to get ambitious relative to
how often it'll be seen by users, though.
--
Peter Geoghegan
em go away.)From f858f7045c8b526e89e3bdc1e67524180a5b6b5c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 10 Dec 2021 07:24:32 +0100
Subject: [PATCH] Remove pg_strtouint64(), use strtoull() directly
pg_strtouint64() is a wrapper around strtoull/strtoul/_strtoui64, but
it seems no longer ne
On 09.12.21 19:41, Andres Freund wrote:
Withhttps://github.com/anarazel/postgres/commit/046203741803da863f6129739fd215f8a32ec357
all tests pass. pg_regress requires PG_REGRESS_SOCK_DIR because it checks for
TMPDIR, but windows only has TMP and TEMP.
This looks reasonable so far. The commit mes
use of the analogy with the "row filter" feature
also being developed. But a filter is normally a dynamic data-driven
action, which this is not. Golden Gate calls it in their documentation
"Selecting Columns", or we could just call it "column list".From cc9082fe6f98e
On Tue, Nov 30, 2021 at 11:52 AM Peter Geoghegan wrote:
> I haven't had time to work through any of your feedback just yet --
> though it's certainly a priority for. I won't get to it until I return
> home from PGConf NYC next week.
Attached is v3, which works thro
like it could be misleading.
I went as far as removing the getrusage stuff for the ereport()
messages that get demoted to DEBUG2. What do you think of that aspect?
I could add some the getrusage output back where that makes sense. I
don't have very strong feelings about that.
--
Peter Geoghegan
want to repeat
ourselves in the VERBOSE case, which will have already indicated its
verboseness in the up-front ereport().
In other words, every distinct case reports on its aggressiveness
exactly once per call into lazyvacuum.c. In roughly the same way as it
works on HEAD.
--
Peter Geoghegan
On Sat, Dec 11, 2021 at 1:13 PM Peter Geoghegan wrote:
> Yes -- in order to report aggressiveness in VACUUM VERBOSE. But the
> autovacuum case still reports verbose-ness, in the same way as it
> always has -- in that same LOG entry. We don't want to repeat
> ourselves in the VE
s currently being processed. Various statistics about the
tables are printed as well."
Having 2 ereports (not just 1) isn't essential, but it seems useful
because it makes the new VACUUM VERBOSE continue to work like this.
But without any of the downsides that go with seeing way too much
detail, moment to moment.
--
Peter Geoghegan
now?). Just logging something still requires defining
"useless VACUUM operation" in a way that is both reliable and
proportionate. So just logging something necessitates solving that
hard problem.
[1] https://commitfest.postgresql.org/36/3433/
--
Peter Geoghegan
On 10.12.21 16:25, Tom Lane wrote:
Our experience with the variable size of "long" has left a sufficiently
bad taste in my mouth that I'm not enthused about adding hard-wired
assumptions that "long long" is identical to int64. So this seems like
it's going in the wrong direction, and giving up p
On Thu, Dec 9, 2021 at 1:37 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, December 8, 2021 7:52 PM Ajin Cherian
> > On Tue, Dec 7, 2021 at 5:36 PM Peter Smith wrote:
> > >
> > > We were mid-way putting together the next v45* when your latest
> > > att
%2BPtoxjo6hpDFTya6WYH-zdspKQ5j%2BwZHBRc6EZkAkq7Nfw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/CAA4eK1L3r%2BURSLFotOT5Y88ffscCskRoGC15H3CSAU1jj_0Rdg%40mail.gmail.com
Kind Regards,
Peter Smith.
Fujitsu Australia
any
definition of "useless" that is continuous (rather than discrete) --
which, on reflection, pretty much means any definition that is
concerned with bloat. I think that you're right about that: the
question there must be "why are we even launching these
bloat-orientated autovacuums that actually find no bloat?".
--
Peter Geoghegan
on-aggressive autovacuums. I think that that might be a
lot worse than it sounds, because the impact compounds over time --
I'm not sure that 20% is much worse than 60%, or much better than 5%
(very hard to model it). But if we make the high-level, abstract idea
of "aggressiveness" more of a continuous thing, and not something
that's defined by sharp (and largely meaningless) XID-based cutoffs,
we have every chance of nipping these problems in the bud (without
needing to model much of anything).
--
Peter Geoghegan
vailable to not just
server code. And it resolves the namespace collision with the
pg_strtointNN() functions in numutils.c.From e723f9480be4c466f9c3f59a75af951d94f2 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 14 Dec 2021 08:38:35 +0100
Subject: [PATCH v2] Simplify the general-pu
On 31.10.21 11:08, Peter Eisentraut wrote:
I want to reactivate $subject. I took Petr Jelinek's patch from [0],
rebased it, added a bit of testing. It basically works, but as
mentioned in [0], there are various issues to work out.
The idea is that the standby runs a background work
On 24.11.21 07:11, Masahiko Sawada wrote:
I haven’t looked at the patch deeply but regarding 007_sync_rep.pl,
the tests seem to fail since the tests rely on the order of the wal
sender array on the shared memory. Since a background worker for
synchronizing replication slots periodically connects
On 24.11.21 17:25, Dimitri Fontaine wrote:
Is there a case to be made about doing the same thing for physical
replication slots too?
It has been considered. At the moment, I'm not doing it, because it
would add more code and complexity and it's not that important. But it
could be added in t
On 28.11.21 07:52, Bharath Rupireddy wrote:
1) Instead of a new LIST_SLOT command, can't we use
READ_REPLICATION_SLOT (slight modifications needs to be done to make
it support logical replication slots and to get more information from
the subscriber).
I looked at that but didn't see an obvious
much more likely to work out
there). But putting the TIDs into a store used for dead TIDs could
make sense. Especially in extreme cases.
--
Peter Geoghegan
On Tue, Dec 14, 2021 at 10:12 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila wrote:
> >
> > On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > Few other comments:
> > ===
>
> Few more comm
peration to
heap vacuuming. With a distinct autovacuum schedule (well, the
schedule would be related, but still distinct).
--
Peter Geoghegan
functions among these newly added
ones. What do you think?From a2dbd0e24a30b945a5d641ed773dc44f5e6b50c1 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 15 Dec 2021 11:02:59 +0100
Subject: [PATCH] doc: More documentation on regular expressions and SQL
standard
---
doc/src
On 14.12.21 02:31, Tomas Vondra wrote:
There's still one remaining problem, that I already explained in [1].
The problem is that with this:
BEGIN;
SELECT nextval('s') FROM generate_series(1,100);
ROLLBACK;
The root cause is that pg_current_wal_lsn() uses the LogwrtResult.Write,
which
On 13.12.21 20:33, Andres Freund wrote:
pg_regress.c at remove_temp() is still there. These things should probably
be addressed before we can consider making this the default.
Hm, not immediately obvious what to do about this. Do you know if windows has
restrictions around the length of unix d
versions.From e4b049ec68995f1fda50b545e42ef2d2a7d8f8df Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Thu, 16 Dec 2021 06:21:04 +0100
Subject: [PATCH] pg_dump: Refactor getIndexes()
Rearrange the version-dependent pieces in the new more modular style.
---
src/bin/pg_dump/pg_dump.c | 119
On 16.12.21 02:39, Michael Paquier wrote:
On Wed, Dec 15, 2021 at 04:13:10PM -0600, Justin Pryzby wrote:
On Wed, Dec 15, 2021 at 05:04:54PM -0500, Andrew Dunstan wrote:
The directory name needs to be predictable somehow, or maybe optionally
set as a parameter. Having just a timestamped director
On 16.12.21 05:47, Greg Stark wrote:
In the server, the encrypted datums are stored in types called
encryptedr and encryptedd (for randomized and deterministic
encryption). These are essentially cousins of bytea.
Does that mean someone could go in with psql and select out the data
without any
On 16.12.21 16:25, Tom Lane wrote:
Thomas Munro writes:
Apple's ranlib doesn't like empty translation units[1], but
protocol_openssl.c doesn't define any symbols (unless you have an
ancient EOL'd openssl), so longfin and CI say:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
On Fri, Dec 17, 2021 at 7:11 AM Alvaro Herrera wrote:
>
> Kindly do not change the mode of src/backend/parser/gram.y.
>
Oops. Sorry that was not deliberate.
I will correct that in the next version.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
On Wed, Dec 15, 2021 at 3:50 PM Greg Nancarrow wrote:
>
> On Mon, Dec 13, 2021 at 8:49 PM Peter Smith wrote:
> >
> > PSA the v46* patch set.
> >
>
> 0001
>
...
> (2) In the 0001 patch comment, the term "publication filter" is used
> in one
On Tue, Dec 14, 2021 at 4:20 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > On Tue, Dec 7, 2021 at 5:48 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > I think for "FOR ALL TABLE" publication(p2 in my c
On Tue, Dec 14, 2021 at 10:12 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila wrote:
> >
> > On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > Few other comments:
> > ===
>
> Few more comm
On 17.12.21 03:25, Shinya Kato wrote:
For now, I'v attached the patch that fixed the compilation error.
I think it would be good if you could split the uncontroversial new
EmitErrorsOnPlaceholders() calls into a separate patch. And please add
an explanation what exactly the rest of the patch
On 17.12.21 05:47, Amit Kapila wrote:
I think in the above sentence, you mean to say "dropped from the
publication". So, IIUC, you are proposing that if one drops a column
that was part of the column list of a relation in a publication, an
error will be raised. Also, if the user specifies CASCADE
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of adding more, I
will remove them from my current patc
On 17.12.21 00:48, Jacob Champion wrote:
WDYT? (My responses here will be slower than usual. Hope you all have a
great end to the year!)
Looks interesting. I wonder whether putting this into pg_ident.conf is
sensible. I suspect people will want to eventually add more features
around this,
On 17.12.21 01:41, Jacob Champion wrote:
(And I think the client should be able to enforce encryption in
the first place, before I distract you too much with other stuff.)
Yes, this is a useful point that I have added to my notes.
On 16.12.21 07:50, Michael Paquier wrote:
As per $subject, avoiding the flush of the new cluster's data
directory shortens a bint the runtime of the test. In some of my slow
VMs, aka Windows, this shaves a couple of seconds even if the bulk of
the time is still spent on the main regression test
701 - 800 of 11048 matches
Mail list logo
