n of the user docs -- the section that
3785f7ee added.
[1]
https://postgr.es/m/cah2-wzm9y59h2m6izjm4fpdup5r4bsrvzgbn2gtrco1j4nz...@mail.gmail.com
[2]
https://github.com/postgrespro/postgrespro/blob/PGPRO9_5/src/backend/access/common/indextuple.c#L451
--
Peter Geoghegan
f173040 cannot recur here is one concrete thing you could
do. Documenting/explaining the ri_RangeTableIndex/ri_mergeTargetRTI
divide is another. The comment above ri_mergeTargetRTI is totally
inadequate.
--
Peter Geoghegan
On Fri, Mar 23, 2018 at 11:15 PM, Peter Geoghegan wrote:
> I agree that this is very similar, as far as the RTEs go. What is
> dissimilar is the fact that there is hard-coded knowledge of both
> through parsing, planning, and execution. It's everything, taken
> together.
>
&
> copy of the code, but ISTM the new code just removes handling of some
> error types when (plan==NULL), and doesn't call SPI_keepplan or
> exec_simple_check_plan. Why not to keep using exec_prepare_plan and add
> a new parameter to skip those calls?
Good idea. Done.
--
Peter Eise
s worth.
Clearly I jumped the gun on this one. I agree that this is fine.
--
Peter Geoghegan
that
necessitates the use of multiple RTEs. I don't think it would make
sense to use a second RTE only when needed.
--
Peter Geoghegan
th 3 being determined
> purely experimentally though.
A quick look at the DWARF4 standard [1] suggests that this refers to
lexical depth. So, I agree that that doesn't seem like a great idea.
[1] http://dwarfstd.org/doc/DWARF4.pdf
--
Peter Geoghegan
ions.
Sorry for going off in a tangent, but I think it's somewhat necessary
to have a strategy here. Of course, we don't have to get everything
right now, but we should be looking in this direction whenever we talk
about on-disk nbtree changes.
--
Peter Geoghegan
On 3/21/18 17:14, Bossart, Nathan wrote:
> Here is an updated set of patches that use the newly proposed approach
> for avoiding division-by-zero errors in pg_resetwal.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remo
rhaps output something. Can we also have the
> pg_upgrade status display indicate that too, e.g. change
>
> Copying user relation files
>
> to
>
> Copying (copy-on-write) user relation files
That would be nice, but we don't have a way to tell that, AFAICT.
copyfile is only able to do a complete
> file copy, so we would also lose this property as well on Linux.
I have shown earlier in the thread that copy_file_range in one go is
still better than doing it in pieces.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Developmen
On 3/19/18 20:40, Peter Eisentraut wrote:
> On 3/14/18 08:05, Ildus Kurbangaliev wrote:
>>> The ROLLBACK call in the first loop iteration undoes the UPDATE
>>> command that drives the loop. Is it then sensible to continue the
>>> loop?
>>>
>>
ey_normalization#How_big_can_normalized_keys_get.2C_and_is_it_worth_it.3F
--
Peter Geoghegan
oss-check workaround is ugly, but apparently there is a
precedent in copy.c. I didn't know that detail until Robert pointed it
out. That makes me feel a lot better about this general question of
how the target relation is represented, having two RTEs, etc.
--
Peter Geoghegan
e committed shortly.
--
Peter Geoghegan
From ede1ba731dc818172a94adbb6331323c1f2b1170 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Thu, 24 Aug 2017 20:58:21 -0700
Subject: [PATCH v7 1/2] Add Bloom filter data structure implementation.
A Bloom filter is a space-efficient, probabilistic dat
ch goal is when coming up with a back-patchable fix like
this. When the goals are somewhat in competition with each other, a
second or a third opinion is particularly appreciated.
--
Peter Geoghegan
On 3/13/18 19:40, Andres Freund wrote:
> I've pushed a revised and rebased version of my JIT patchset.
What is the status of this item as far as the commitfest is concerned?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
couple of small
> bugs.
>
> (This includes the patches I just posted in the row triggers patch)
Since the row triggers patch has been committed, do you plan to send an
update on this patch?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
shaped as
> suggested. Any input from other folks? I don't have more to say.
Committed after fixing up the documentation a bit as suggested by others.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
rmat should not need to
>> be interpreted in a context-sensitive way, if we can avoid it.
>
> Both pg_filedump and amcheck could correclty parse any tuple based on
> BTP_LEAF flags and length of tuple.
amcheck doesn't just care about the length of the tuple. It would have
to rely on catalog metadata about this being an INCLUDE index.
--
Peter Geoghegan
-coded
assumptions about the relationship between those two RTEs.
--
Peter Geoghegan
t must have a snapshot that is at least
as old as the first snapshot that the first call to bt_check_index()
acquires. It's not a special case; it's exactly as bad as any
statement that takes the same amount of time to execute.
> Is
> there anything we can do to lessen that burden l
ould use suffix truncation to save at least one byte in
almost all cases, even with the thinnest possible
single-integer-attribute IndexTuples. What you describe just isn't
going to happen.
--
Peter Geoghegan
ybe use CopyAndSetIdentifier? (We similarly have
MemoryContextResetAndDeleteChildren.)
I'm also not clear why this doesn't undo the previous optimization that
preferred making the identifier a compile time-constant. Aren't we now
just going back to doing a pstrdup() every time?
. That's what we see for the RETURNING +
ON CONFLICT projections within nodeModifyTable.c, which the new
projections are very similar to, and clearly modeled on.
--
Peter Geoghegan
he patch as ready
for committer, actually. I was just expressing that your input was
valuable. Sorry for being unclear.
--
Peter Geoghegan
On 3/21/18 18:50, Peter Eisentraut wrote:
> On 3/12/18 11:26, Nikita Glukhov wrote:
>> I have reviewed this patch. Attached new 6th version of the patch with
>> v5-v6 delta-patch.
>
> Thanks for the update. I'm working on committing this.
Committed.
Everything seemed
f
repeating it twice. I think that makes it clearer. I'm not sure
splitting it up like above makes it better, because the
IsTransactionBlock() is part of the "is atomic". Maybe adding a comment
would make it clearer.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
uld take a pretty steep penalty for me to want to take
> the risk of refactoring to avoid that.
>
> I've pushed it with some cosmetic adjustments.
Thank you, Tom.
--
Peter Geoghegan
On 3/28/18 09:00, Tomas Vondra wrote:
> I see. I thought "fixed" means you adopted the #define, but that's not
> the case. I don't think an extra comment is needed - the variable name
> is descriptive enough IMHO.
Committed as presented then. Thanks.
--
Peter Eisen
code, not external factors. If an
in-progress compiler does funny things, what are we supposed to do about
that?
Generally, fixing up PostgreSQL for a new compiler release isn't a major
effort and can be done briefly before the release of the compiler.
--
Peter Eisentraut
On 3/28/18 17:27, Andres Freund wrote:
> I've pushed these three.
Great, now the only thing remaining is to prepare an unconference
session explaining all this to the rest of us. ;-)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Re
t; we use explicit [ and ] characters, but I see that there are other
> examples, and it is rendered as [ and ] in the output.
I think this will probably not come out right in the generated psql
help. Check that please.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
and pgbench utilities.
What I'd like to see here is extensive protocol documentation that
describes the compression method negotiation, and the interaction with
SSL, and a test suite to support that.
Maybe start a new thread.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postg
, passed
>
> I have checked new version. Although I can miss something, the patch looks
> good to me.
>
> The new status of this patch is: Ready for Committer
Committed, thanks!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ar as the protocol is concerned.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
tuples? I don't
> know answer to that, but given that sometimes bt_check_index() may take
> hours if not days to finish, it seems worth thinking or at least documenting
> the side-effects somewhere.
That seems like a worthwhile goal for a heap checker that only checks
the structure of the heap, rather than something that checks the
consistency of an index against its table. Especially one that can run
without a connection to the database, for things like backup tools,
where performance is really important. There is certainly room for
that. For this particular enhancement, the similarity to CREATE INDEX
seems like an asset.
--
Peter Geoghegan
patch and it looks fine to me.
I'm grateful that you didn't feel any need to encourage me to use
whatever the novel/variant filter du jour is! :-)
--
Peter Geoghegan
On 3/29/18 07:37, Andrew Gierth wrote:
>>>>>> "Peter" == Peter Eisentraut writes:
>
> Peter> Committed, thanks!
>
> So... what is a pl/* that does _not_ use pinned cursors for cursor loops
> supposed to do in this case?
Other than maybe using
a bit
> unlogical
> that SPI behaves differently.
Here is the same patch rewritten using SPI, using the new no_snapshots
facility recently introduced.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, T
d it when investigating problems after the fact, and
as a general smoke-test, where it works well. I would perhaps
recommend running it once a week, although that's a fairly arbitrary
choice. The docs in v10 don't take a position on this, so while I tend
to agree we could do better, it is a preexisting issue.
[1] https://www.postgresql.org/docs/10/static/amcheck.html#id-1.11.7.11.7
--
Peter Geoghegan
. You make a good point about Java. Furthermore, when people talk
about just in time compilation in database systems, which is far from
a novel thing, they generally use the word JIT.
Why confuse things?
--
Peter Geoghegan
On 3/29/18 14:20, Andres Freund wrote:
> On 2018-03-28 20:34:13 -0400, Peter Eisentraut wrote:
>> On 3/28/18 12:09, Andres Freund wrote:
>>> Yea, not the most descriptive... Returning multiple different resultsets
>>> from a function / procedure. Inability to do so is
item */
if (newitemonleft)
leftfree -= (int) state->newitemsz;
else
rightfree -= (int) state->newitemsz;
With an extreme enough case, this could result in a failure to find a
split point. Or at least, if that isn't true then it's not clear why,
and I think it needs to be explained.
--
Peter Geoghegan
The margin of error is tiny - certainly much less than a
practical use-case could ever care about.
>> +/*
>> + * Calculate "val MOD m" inexpensively.
>> + *
>> + * Assumes that m (which is bitset size) is a power-of-two.
>> + *
>> + * Using a power-of-two
letely figured this out yet. Whatever is in
pglogical and bdr and similar external projects are the best current
compromises. But they have lots of problems, so I don't know if anyone
is ready to propose something for in core yet.
--
Peter Eisentraut http://www.2ndQuadrant.com/
ruptions to be
> less responsive.
The maximum file size that we copy is 1GB and that nowadays takes maybe
10 seconds. I think that would be an acceptable response time.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Mar 29, 2018 at 7:42 PM, Peter Geoghegan wrote:
>> We should be able to get this into v11...
>
> That's a relief. Thanks.
I have a new revision lined up. I won't send anything to the list
until you clear up what you meant in those few cases where it seemed
unclear.
the same functionality at a coarser granularity (e.g.
database, table), certainly, but I don't see that there is much more
that we can do while starting with a B-Tree index as our target.
Please propose an alternative user interface for the new check. If you
prefer, I can invent new bt_index_check_heap() +
bt_index_parent_check_heap() variants. That would be okay with me.
--
Peter Geoghegan
On Fri, Mar 30, 2018 at 6:55 PM, Peter Geoghegan wrote:
> On Fri, Mar 30, 2018 at 6:20 PM, Andres Freund wrote:
>>> What would the upcasting you have in mind look like?
>>
>> Just use UINT64CONST()? Let's try not to introduce further code that'll
>> need
idea to stick covering indexes and suffix truncation features together.
> That wouldn't accelerate appearance one feature after another, but rather
> likely would RIP both of them...
I think that the thing that's more likely to kill this patch is the
fact that after the first year, it only ever got discussed in the
final CF. That's not something that happened because of my choices. I
made several offers of my time. I did not create this urgency.
[1] https://www.postgresql.org/message-id/18788.963953...@sss.pgh.pa.us
[2]
https://wiki.postgresql.org/wiki/Key_normalization#Making_all_items_in_the_index_unique_by_treating_heap_TID_as_an_implicit_last_attribute
--
Peter Geoghegan
On Fri, Mar 30, 2018 at 10:39 PM, Peter Geoghegan wrote:
> It's safe, although I admit that that's a bit hard to see.
> Specifically, look at this code in _bt_insert_parent():
>
> /*
> * Find the parent buffer and get the parent page.
> *
&g
it in rebase. Reinstate it.
Hmm, doesn't cause any test changes?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
reg1_col1_fkey"
+DETAIL: Key (reg1_col1)=(42) is not present in table "at_regular1".
There are no documentation changes. The foreign key section in CREATE
TABLE does not contain anything about partitioned tables, which is
probably an existing omission, but it might be good to fix t
arent_check_heap()? Or, are you talking about function
overloading?
--
Peter Geoghegan
tion and
> causing issues due to dependencies.
WFM. I have all the information I need to produce the next revision now.
--
Peter Geoghegan
On Sat, Mar 31, 2018 at 2:59 PM, Peter Geoghegan wrote:
> WFM. I have all the information I need to produce the next revision now.
I might as well post this one first. I'll have 0002 for you in a short while.
--
Peter Geoghegan
v8-0001-Add-Bloom-filter-data-structure-implementati
On Sat, Mar 31, 2018 at 3:15 PM, Peter Geoghegan wrote:
>> WFM. I have all the information I need to produce the next revision now.
>
> I might as well post this one first. I'll have 0002 for you in a short while.
Attached is 0002 -- the amcheck enhancement itself. As requeste
onal overhead of having an
accurate high key size for every candidate split point would be
significant.
--
Peter Geoghegan
On Sat, Mar 31, 2018 at 3:15 PM, Peter Geoghegan wrote:
> On Sat, Mar 31, 2018 at 2:59 PM, Peter Geoghegan wrote:
>> WFM. I have all the information I need to produce the next revision now.
>
> I might as well post this one first. I'll have 0002 for you in a short while
On Sat, Mar 31, 2018 at 8:08 PM, Andres Freund wrote:
>> round() is from C99, apparently. I'll investigate a fix.
>
> Just replacing it with a floor(val + 0.5) ought to do the trick, right?
I was thinking of using rint(), which is what you get if you call
round(float8) fro
On Sat, Mar 31, 2018 at 8:09 PM, Peter Geoghegan wrote:
> I was thinking of using rint(), which is what you get if you call
> round(float8) from SQL.
Attached patch does it that way. Note that there are float/int cast
regression tests that ensure that rint() behaves consistently on
sup
On Sat, Mar 31, 2018 at 8:32 PM, Andres Freund wrote:
> LGTM, pushed. Closing CF entry. Yay! Only 110 to go.
Thanks Andres!
--
Peter Geoghegan
fset number...
Maybe I was confused.
> I'd like to note that I really appreciate your attention to this patch
> as well as other patches.
Thanks. I would like to thank Anastasia and you for your patience and
perseverance, despite what I see as mistakes in how this project was
manged. I really want for it to be possible for there to be more
patches in the nbtree code, because they're really needed. That was a
big part of my motivation for writing amcheck, in fact. It's tedious
to link this patch to a bigger picture about what we need to do with
nbtree in the next 5 years, but I think that that's what it will take
to get this patch in. That's my opinion.
--
Peter Geoghegan
claring a foreign key
> + that references a partitioned table is not allowed.
>
Maybe use "possible" or "supported" instead of "allowed" and "permitted"
in this and similar cases.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Y unconditionally. Or at least explain this more.
Other than that, it looks OK.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
programs are called, so this is going to lead
to omissions and inconsistencies -- which will then possibly only be
found much later by the extensions that Craig was talking about. I'd
like to see this more isolated, maybe via a path change, or something
inside system_or_bail or something less inv
ntil they notice that the compression result changes, in
which case they have matched the bank account number.
In the web space, that is easier because the client code is typically
viewable by the attacker, and this kind of query is more common (the
"bank account number" is typic
ave bothered about this refactoring
> if be-secure-openssl.c did not exist yet, but as it does I think that we
> should bite the bullet, and do that for v11 so as a good base is in
> place for the future.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postgre
in typical database
installations. I think we should move forward with considering protocol
compression proposals, but any final result should put a warning in the
documentation that using compression is potentially insecure.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postg
On 4/1/18 04:14, Pavel Stehule wrote:
> Hi
>
> small bugfix patch
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4/2/18 12:46, Tom Lane wrote:
> Peter Eisentraut writes:
>> I agree the attack is less likely to be applicable in typical database
>> installations. I think we should move forward with considering protocol
>> compression proposals, but any final result should
; *** 111,116 CREATE PUBLICATION > class="parameter">name
>> --- 111,121
>> and so the default value for this option is
>> 'insert, update, delete'.
>>
>> +
>> +T
And Craig is the main
> proponent of it?
I wonder how bad it will be in practice if we PANIC. Craig said "This
isn't as bad as it seems because AFAICS fsync only returns EIO in
cases where we should be stopping the world anyway, and many FSes will
do that for us". It would be nice to get more information on that.
--
Peter Geoghegan
ot;)));
>
> I guess we can add that later, but it's a bit sad that this won't work
> against views with INSTEAD OF triggers.
It also makes it hard to test deparsing support, which actually made
it in in the end. That must be untested.
--
Peter Geoghegan
On Mon, Apr 2, 2018 at 8:11 PM, Pavan Deolasee wrote:
> Honestly I don't think Peter ever raised concerns about the join, though I
> could be missing early discussions when I wasn't paying attention. It's
> there from day 1. Peter raised concerns about the two RTE stuff
ccurred somewhere in the file is all that is necessary;
applications that require better granularity already use O_DIRECT."
--
Peter Geoghegan
), then the first difficulty isn't high
> too.
I think it's possible.
I didn't have time to look at this properly today, but I will try to
do so tomorrow.
Thanks
--
Peter Geoghegan
On 3/15/18 03:46, Pavel Stehule wrote:
> It looks well
>
> the patch has tests and doc,
> there are not any warnings or compilation issues
> all tests passed
>
> I'll mark this patch as ready for commiter
committed
--
Peter Eisentraut http://www.2
't ideal, and
particularly hinders automated testing.
--
Peter Geoghegan
We could optimize this away when !RelationIsLogicallyLogged(rel)
>> + * but that doesn't save much space or time.
>
> What you're saying isn't that you're not logging anything, but that
> you're allocating the header regardless? Because this certainl
dd it to _bt_check_natts().
* README-SSI says:
* The effects of page splits, overflows, consolidations, and
removals must be carefully reviewed to ensure that predicate locks
aren't "lost" during those operations, or kept with pages which could
get re-used for different parts of the index.
Do we need to worry about that here? I guess not, because this is just
like having many duplicates. But a note just above the _bt_doinsert()
call to CheckForSerializableConflictIn() might be a good idea.
That's all I have for today.
--
Peter Geoghegan
On 4/3/18 15:11, Alvaro Herrera wrote:
> 0003 is the main patch, which is a bit changed from v4, notably to cover
> your review comments:
Looks good now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
it.
I agree that this was handled in a way that was just unsatisfactory.
It was also unnecessary, since we still have a few days left until
feature freeze.
--
Peter Geoghegan
otally untested. That was a consequence
of the representation in the executor.
--
Peter Geoghegan
problem, but it probably wouldn't have made a big difference in the
end. There is only so much time available.
--
Peter Geoghegan
okup and so on. Yes, we change size of some tuples,
> but B-tree already worked with tuples of variable sizes. So, the fact
> that tuples now have different size shouldn't affect SSI. Right now,
> I'm not sure if CheckForSerializableConflictIn() just above the
> _bt_doinsert() is good idea. But even if so, I think that should be
> a subject of separate patch.
My point was that that nothing changes, because we already use what
_bt_doinsert() calls the "first valid" page. Maybe just add: "(This
reasoning also applies to INCLUDE indexes, whose extra attributes are
not considered part of the key space.)".
That's it for today.
--
Peter Geoghegan
On 4/3/18 22:31, Peter Eisentraut wrote:
> The problem I see now is that when we WAL-log a truncate, we include all
> the relids in one record. That seems useful. But during decoding we
> split this into one change per relid. So at the receiving end, truncate
> can only process one
That would require a bit more deep surgery in SPI, it
seems. I'll take a look if it's doable.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
o support the grammar,
> and the one interesting piece exec_stmt_set seems fine to me.
>
> Barring any objections, I'll mark it as RFC tomorrow morning.
You apparently didn't, but I committed it anyway. ;-)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreS
ross
both> platforms, and not flushing early at all is only minimally worse.
Based on this, I suggest that we set the flush distance to 32MB on all
platforms. Not only is it faster, it avoids having different settings
on some platforms.
--
Peter Eisentraut http://www.2ndQ
marks need to be seen in the context of the past couple of
weeks, and in the context of this being a relatively high risk patch
that was submitted quite late in the cycle.
--
Peter Geoghegan
was just one patch. I can think of several.
--
Peter Geoghegan
The documentation change suggests the error will be
ERROR: canceling statement due to user request: "Cancellation message text"
Why the quotes?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ternal" arguments. Similarly for some columns in pg_aggregate.
There are also additional pseudo-types that should be excluded. See
pg_type.typtype = 'p', except some of those should not be excluded.
Needs more thought.
Considering these issues, I think it would be appropriate
ll
* truncate_useless_pathkeys() to possibly remove more pathkeys.
* I don't think that there is much point in having separate 0003 +
0004 patches. For the next revision, please squash those down into
0002. Actually, maybe there should be only one patch for the next
revision. Up to you.
* Please write commit messages for your patches. I like to make these
part of the review process.
That's all for now.
--
Peter Geoghegan
implementation that this patch is
proposing to get rid of.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
the options are
the same and some are different or missing.
Another thought: Isn't CSV just the same as unaligned output plus some
quoting? Could we add a quote character setting and then define --csv
to be quote-character = " and fieldsep = , ?
--
Peter Eisentraut http
this is a workaround for not properly cataloguing
NOT NULL constraints. If we fixed that, you could do SET NOT NULL NOT
VALID and go from there. Maybe we should look again into fixing that.
That would solve so many problems.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL De
sting for pg_dump, psql, pg_basebackup,
pg_upgrade, logical replication, and so on. Ideally, we would be able
to run the whole test set against an older version somehow. Lots of
details omitted here, of course. ;-)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Developm
1401 - 1500 of 10745 matches
Mail list logo
