as been updated accordingly. All assertions identified in the
original post are now adjacent the global variables they are asserting.
Kind Regards
--
Peter Smith
Fujitsu Australia
ct_asserts_StaticAssertDecl_2.patch
Description: ct_asserts_StaticAssertDecl_2.patch
d a
>> "secret" or a "stored secret" would be better.
> But I agree that "secret", as used in RFC5803 is better.
Here is my proposed patch to adjust this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postgre
ay of
getting a page dump is described here:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#contrib.2Fpageinspect_page_dump
If I had to guess, I'd guess that this was due to a generic storage problem.
--
Peter Geoghegan
On Thu, Oct 10, 2019 at 1:18 PM Peter Geoghegan wrote:
> You didn't say which PostgreSQL versions were involved, and if the
> database was ever upgraded using pg_upgrade. Those details could
> matter.
In case you weren't aware, contrib/amcheck should make detected and
diagno
ypes of atomic operations: the fact that the downlink still
exists at all, and the fact that the sidelinks still exist at all.
This smells like a problem with slightly inconsistent page images, as
opposed to a problem with how one particular atomic operation did
something. It's not actually surprising that this would be the first
place that you'd notice a generic issue, since many other things are
"more forgiving" in various ways.
--
Peter Geoghegan
On 2019-10-10 10:03, Michael Paquier wrote:
> On Thu, Oct 10, 2019 at 09:08:37AM +0200, Peter Eisentraut wrote:
>> Here is my proposed patch to adjust this.
>
> Looks fine to me reading through. I think that you are right to not
> change the descriptions in build_server_f
e running the regression tests,
> specifically the interval test, and they all look like this:
I've also seen this randomly, but only under 64-bit mingw, never 32-bit
mingw.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
potentially useful to avoid misuse by
third-party extensions.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 86e5e00e17762c174624f203b9c54fdf5fe815fb Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 23
the "package" mechanism
anymore.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 304270da9168134df77d59c537268bd6bcaf1a06 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 14 Oct 2019
ad-hoc Windows build provisions (those
win32.mak files we used to have around). Also, the ddll.def (debug
build) isn't used by anything anymore AFAICT.
I think we can clean this up and just have the regular ddl.def built
normally at build time if required.
Does anyone know more about this?
n ever.
> There's pretty substantial and
> nontrivial areas without any tests - do we have actually have any
> confidence that they work?
Everything that you're talking about has existed since v11 came out a
year ago, and most of it is a year or two older than that. So yeah,
I'm pretty confident that it works.
--
Peter Geoghegan
view again, and consider if this is OK for "Ready for Committer"
status.
Kind Regards
--
Peter Smith
Fujitsu Australia
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
On Behalf Of Andres Freund
Sent: Thursday, 6 April 2017 5:18 AM
To: Haribabu Kommi
Cc: Mic
On 2019-10-13 21:25, Peter Eisentraut wrote:
> During the cleanup of the _MSC_VER versions (commit
> 38d8dce61fff09daae0edb6bcdd42b0c7f10ebcd), I found it useful to use
> -Wundef, but that resulted in a bunch of gratuitous warnings. Here is a
> patch to fix those. Most of th
don't have a strong reason to advocate dropping
> support other than that this #define appears to be undocumented.
Per subsequent messages in this thread, this issue is outside the scope
of my patch, so I proceeded with my patch as I had proposed it.
--
Peter Eisentraut http:/
On 2019-09-18 11:33, Quan Zongliang wrote:
> On 2019/9/18 17:11, Peter Eisentraut wrote:
>> Why do you need to turn off replication when there is "maintenance" on a
>> table? What does that even mean?
>>
> In a table, the user only keep data for a period of
e a way to get the old
behavior. Perhaps this whole thing should be a new
recovery_target_action, say, 'pause_unless_reached'.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ils/selfuncs.h"
-#include "bloom.h"
/*
* Estimate cost of bloom index scan.
This class of change I don't like.
The existing arrangement keeps "other" header files separate from the
header file of the module itself. It seems useful to keep that separate.
--
Peter Eisentrau
it
> make sense to cleanup those ones?
OK, I'll look into those, but it seems like a separate undertaking. We
don't always remove things just because they were dropped by the SQL
standard.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24
On 2019-10-18 15:00, Tom Lane wrote:
> Yeah, the comment that Peter complained about is mine. I believe the
> desire to avoid depending on "sed" at build time was focused on our
> old support for building libpq with Borland C (and not much else).
> Since this makefile infr
On 2019-10-20 10:26, Peter Eisentraut wrote:
> On 2019-10-18 15:00, Tom Lane wrote:
>> Yeah, the comment that Peter complained about is mine. I believe the
>> desire to avoid depending on "sed" at build time was focused on our
>> old support for building libpq wi
On 2019-10-21 00:07, Peter Eisentraut wrote:
> On 2019-10-20 10:26, Peter Eisentraut wrote:
>> On 2019-10-18 15:00, Tom Lane wrote:
>>> Yeah, the comment that Peter complained about is mine. I believe the
>>> desire to avoid depending on "sed" at build time w
this will have on a machine
with horribly slow I/O. Though I just bought a new Raspberry Pi, and
could test on that when I get back home from my trip to Europe -- it
uses an SD card, which is pretty slow.
> I'm not saying that tuplesort has gotten worse or anything. Just that
> there's been too much development without adding tests.
I agree.
--
Peter Geoghegan
; also work a bit more on that angle.
That's hard for me to test right now, but offhand this general
approach looks good to me. I am pretty sure it's portable.
--
Peter Geoghegan
also a valid thing to do, but it's obviously quite
different from a mingw build.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-10-21 07:34, Michael Paquier wrote:
> On Sun, Oct 20, 2019 at 10:01:09AM +0200, Peter Eisentraut wrote:
>> On 2019-10-17 09:44, Michael Paquier wrote:
>>> I have a question here. Per the notes in information_schema.sql,
>>> SQL_SIZING_PROFILES has been remove
for format [-Wformat-extra-args]
These files don't use our printf replacement or the c.h porting layer,
so unless we want to start doing that, I propose the attached patch to
determine the appropriate format conversion the hard way.
--
Peter Eisentraut http://www.2ndQuadrant.co
ise
> PostgerSQL sisteminin semaphore tütekitimini max_connections parametresini şu
> an %d) düşürerek azaltabilirsiniz.\n"
This has been fixed in the translation repository and will be applied in
the next minor releases.
--
Peter Eisentraut http://www.2ndQuadrant.com/
It seems to me that using IDENT_USERNAME_MAX for peer authentication is
some kind of historical leftover and not really appropriate or useful,
so I propose the attached cleanup.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
On 2019-09-30 20:16, Peter Eisentraut wrote:
> On 2019-09-27 17:50, Alvaro Herrera wrote:
>> On 2019-Sep-13, Alvaro Herrera wrote:
>>
>>> On 2019-Aug-20, Peter Eisentraut wrote:
>>>
>>>> The memory management of that seems too complicated. The "ex
On 2019-10-10 00:52, Smith, Peter wrote:
> I liked your idea of using an extern function declaration for implementing
> the file-scope compile-time asserts. AFAIK it is valid standard C.
>
> Thank you for the useful link to that compiler explorer. I tried many
> scena
"So we *shouldn't* need a separate
configure check"
Kind Regards
---
Peter Smith
Fujitsu Australia
On 2019-02-25 17:17, Corey Huinker wrote:
> Right, this makes a lot of sense, similar to how ri_restrict() combines
> RESTRICT and NO ACTION.
>
>
> I'm pretty sure that's where I got the idea, yes.
Committed, including your patch.
--
Peter Eisentrau
Dear all,
we rebased our temporal normalization patch on top of
554ebf687852d045f0418d3242b978b49f160f44 from 2019-02-28.
On 9/7/18 1:02 PM, Peter Moser wrote:
> The syntax is
> SELECT * FROM (r NORMALIZE s USING() WITH(period_r, period_s)) c;
Please find all information about our dec
a
> script called reformat_dat_file.pl in the tree which contains
> comments indicating that it could be modified for bulk editing, said
> script having been committed BY YOU, I don't understand why you think
> that bulk editing is infeasible.
I'm also curious to hear what Tom t
umented or under-documented process that requires a
fixed amount of extra mental effort when committing *anything* is
another matter.
--
Peter Geoghegan
ly determined
small range of contiguous OIDs that fall within the current range for
that devel cycle. That would prevent collisions caused by the natural
human tendency to prefer a round number. Having contiguous OIDs for
the same patch seems worth preserving.
--
Peter Geoghegan
this or that reason, it's deprecated.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
; then we are moving in the right direction IMO regardless of anything
> else.
I'm glad that we now have a plan that is a clear step forward.
> I think Peter and I are more agreeing than we are at the opposite ends
> of a spectrum, but more importantly, I think it is worth having a
>
eck within _bt_pagedel() will throw an
ERRCODE_INDEX_CORRUPTED error, and tell the DBA to REINDEX. Shouldn't
this internal level _bt_is_page_halfdead() check contain a "can't
happen" error, or even a simple assertion?
--
Peter Geoghegan
seems very
difficult, and I don't think that it's performance critical. This is a
problem only because it's distracting and confusing.
I favor keeping the test, but having it throw a
ERRCODE_INDEX_CORRUPTED error, just like _bt_pagedel() does already. A
comment could point out that the test is historical/defensive, and
probably isn't actually necessary. What do you think of that idea?
--
Peter Geoghegan
On Fri, Mar 1, 2019 at 5:00 PM Peter Geoghegan wrote:
> I favor keeping the test, but having it throw a
> ERRCODE_INDEX_CORRUPTED error, just like _bt_pagedel() does already. A
> comment could point out that the test is historical/defensive, and
> probably isn't actually neces
On 2019-02-25 09:29, Peter Eisentraut wrote:
> On 2019-02-22 21:31, Andres Freund wrote:
>> On 2019-02-22 12:38:35 +0100, Peter Eisentraut wrote:
>>> On 2019-02-19 18:02, Andres Freund wrote:
>>>> But even if we were to decide we'd want to keep a volatile in Set
ew index.
I used your wording for this in v14, almost verbatim.
> Now that the index tuple format becomes more complicated, I feel that
> there should be some kind of an overview explaining the format. All the
> information is there, in the comments in nbtree.h, but you have to piece
> together all the details to get the overall picture. I wrote this to
> keep my head straight:
v14 uses your diagrams in nbtree.h, and expands some existing
discussion of INCLUDE indexes/non-key attributes/tuple format. Let me
know what you think.
--
Peter Geoghegan
w.
>
> Stupid question, but do we use any kind of reference counter to know if
> two subsystems look at a structure, and a copy is required?
No, but I wonder if we could use Valgrind to enforce rules about who
has the right to scribble on what, when. That could make it a lot
easier to impose a new rule.
--
Peter Geoghegan
t is too low.
Does anyone want to make an argument against the idea of raising the
default? They should speak up now.
--
Peter Geoghegan
ter.
Can you put your proposal in the form of some logical pseudocode? I
don't understand the free-form description.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
This was once just another
dynamic allocation, that called _bt_mkscankey(), but that regressed
nested loop joins, so I had to make it work the same way as before. I
noticed this about six months ago, because there was a clear impact on
the TPC-C "Stock level" transaction, which is now sometimes twice as
fast with the patch series. Note also that commit d961a568, from 2005,
changed the _bt_first() code to use a stack allocation. Besides,
sticking to a stack allocation makes the changes to _bt_first()
simpler, even though it has to duplicate a few things from
_bt_mkscankey().
I could get you a v15 that integrates your changes pretty quickly, but
I'll hold off on that for at least a few days. I have a feeling that
you'll have more feedback for me to work through before too long.
[1]
https://postgr.es/m/cah2-wzn_nayk4pr0hrwo0stwhmxjp5qyu+x8vppt030xpqr...@mail.gmail.com
--
Peter Geoghegan
v3 indexes (v3 indexes
simply aren't allowed to use a heap TID in their scankey). Unique keys
also allow amcheck to relocate every tuple in the index from the root
page, using the same code path as regular index scans. We'll be
relying on the uniqueness of keys within amcheck from the beginning,
before anybody teaches nbtree to perform retail index tuple deletion.
--
Peter Geoghegan
t, provided all the
assertions that verify that the work "_bt_findinsertpage()" would have
done if called was in fact unnecessary. (e.g., check the high
key/rightmost-ness)
> The attached new version simplifies this, IMHO. The bounds and the
> current buffer go together in the same struct, so it's easier to keep
> track whether the bounds are valid or not.
I'll look into integrating this with my current draft v15 tomorrow.
Need to sleep on it.
--
Peter Geoghegan
On Wed, Mar 6, 2019 at 10:54 PM Peter Geoghegan wrote:
> It will also have to store heapkeyspace, of course. And minusinfkey.
> BTW, I would like to hear what you think of the idea of minusinfkey
> (and the !minusinfkey optimization) specifically.
> I'm not sure that that
bit more, I think making a new test file is
reasonable. The file is already fairly long anyway, compared to the
typical test file size.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
within
nbtsort.c needs to be changed back.
--
Peter Geoghegan
From cdfe29c5479da6198aa918f4c373cb8a1a1acfe1 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Mon, 21 Jan 2019 15:35:37 -0800
Subject: [PATCH 08/12] DEBUG: Force version 3 artificially.
---
contrib/amcheck/expected/check_bt
d, and found them equal.
Similarly, v3 indexes specify "minusinfkey = true" in all cases,
because they always want to go left -- just like in old Postgres
versions. They don't have negative infinity values (matches can be on
either side of the all-equal pivot, so they must go left).
--
Peter Geoghegan
On Thu, Mar 7, 2019 at 12:37 AM Peter Geoghegan wrote:
> When I drew you that picture while we were in Lisbon, I mentioned to
> you that the patch sometimes used a sentinel scantid value that was
> greater than minus infinity, but less than any real scantid. This
> could be used
same leaf page will indicate that
the scan is over, without actually visiting the sibling. (Again, I'm
assuming that your search is for a single value.)
--
Peter Geoghegan
ions. I'll send a
separate patch for that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
could remove all that.
But it should be done consistently in either case.
I also think we shouldn't worry about the "failed (ignored)" case. That
never happens, and I don't want to mess up the spacing we have now for
that. I'd consider removing support for it altogethe
have to use .
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
h is always a single integer,
and PG_VERSION, which could be 10.9.8 or 11beta5 or 12devel. The patch does
if (PG_VERSION ends with 'devel')
return /docs/devel/
else
return /docs/$PG_MAJORVERSION/
There is no third case. Your third case of not-numeric-and-not-devel is
correctly covered
ctory owned by peter:staff without group
access, then it would be inappropriate for pg_basebackup to change the
permissions on that directory.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
he
> rightmost page has a pivot tuple with all columns truncated away, which
> means positive infinity.
But we do already pretend that. How is that not the case already?
> But it doesn't explain why it's done like that.
It's done this way because that's equivalent to what Lehman and Yao
do, while also avoiding adding the special cases that I mentioned (in
nbtsplitloc.c, and so on).
--
Peter Geoghegan
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
> > Question: Wouldn't it be more straightforward to use "1 +inf" as page
> > 1's high key? I.e treat any missing columns as positive infinity.
>
> That might also work, but it wouldn't be more st
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
> All of that said, maybe it would be clearer if page deletion was not
> the special case that has to opt in to minusinfkey semantics. Perhaps
> it would make more sense for everyone else to opt out of minusinfkey
> semantics, an
e index scan to do
something that won't work for it. It is not up to low level code like
_bt_compare() to worry about these differences (beyond asserting that
caller got it right). If page deletion didn't need minusinfkey
semantics (if nobody but v3 indexes needed that), then I would just
make the "move right of separator" !minusinfkey code within
_bt_compare() test heapkeyspace. But we do have a general need for
minusinfkey semantics, so it seems simpler and more future-proof to
keep heapkeyspace out of low-level nbtsearch.c code.
--
Peter Geoghegan
searching_for_pivot_tuple semantics (relying on its value
> > being minus infinity is still relying on its value being something).
>
> Yeah. I find that's a complicated way to think about it. My mental model
> is that v4 indexes store heap TIDs, and every tuple is unique thanks to
> that. But on v3, we don't store heap TIDs, and duplicates are possible.
I'll try it that way, then.
--
Peter Geoghegan
xes a couple of cases of that. Most instances were
already correct.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 1bb6acf63cf796d0659283c7ea5220385f7de181 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
;> if (PG_VERSION ends with 'devel')
>> return /docs/devel/
>> else
>> return /docs/$PG_MAJORVERSION/
>>
>> There is no third case. Your third case of not-numeric-and-not-devel is
>> correctly covered by the else branch.
>
> Thanks for
On 2019-02-06 23:15, Peter Eisentraut wrote:
> On 05/02/2019 17:20, Tom Lane wrote:
>> What I *don't* like about the proposed patch is that it installs a
>> new, different comparison rule for the ON UPDATE CASCADE case only.
>> If we were to go in this direction, I&#x
On 2019-03-08 11:09, Peter Eisentraut wrote:
> On 2019-03-07 20:04, Daniel Verite wrote:
>> With previous versions, we'd need to call ucol_setAttribute(),
>> with the attributes and values defined here:
>> http://icu-project.org/apiref/icu4c/ucol_8h.html
>>
tance will hold up over days. I
think that it will, because there aren't that many updates, and
they're almost all HOT-safe. I'll put the idea of a 50/50 fillfactor
benchmark with the high-contention/regressed workload on my TODO list,
though.
--
Peter Geoghegan
On Tue, Mar 12, 2019 at 11:32 AM Robert Haas wrote:
> If I wanted to try to say this in fewer words, would it be fair to say
> that reducing the size of an index by 40% without changing anything
> else can increase contention on the remaining pages?
Yes.
--
Peter Geoghegan
n the reduction in the number of leaf
pages, because the benefits compound (items in the root are even a bit
smaller, because of this compounding effect, despite alignment
effects). Internal pages are the most important pages to have cached,
but also potentially the biggest points of contention.
--
Peter Geoghegan
at another TODO item -- this regression will be revisited
using BCC instrumentation. I am currently performing a multi-day
benchmark on a very large TPC-C/BenchmarkSQL database, and it will
have to wait for that. (I would like to use the same environment as
before.)
--
Peter Geoghegan
splits, or is it
contention in internal pages that can be traced back to leaf splits,
that insert a downlink in to their parent page? It would be really
cool to have some idea of the answers to questions like these.
--
Peter Geoghegan
t we'd like to avoid
it where possible. Checking the high key there is now much more likely
to result in the index scan not going to the next page, since we're
more careful when considering a leaf split point these days. The high
key often looks like the items on the page to the right, not the items
on the same page.
Thanks
--
Peter Geoghegan
On 2019-03-11 09:31, Michael Paquier wrote:
> On Mon, Mar 11, 2019 at 08:23:39AM +0100, Peter Eisentraut wrote:
>> Attached patch fixes a couple of cases of that. Most instances were
>> already correct.
>
> It seems to me that you should look at that:
> https://www.p
def. I
> *suppose* that this is correct as written. There are a few occurrences
> of this pattern in eg. contrib/xml2.
I think this is correct, but I don't want to wreck my sanity trying to
understand the syntax-level details of why.
--
Peter Eisentraut http://www.2ndQuadran
entity and publishes updates
Patch attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 95f78d4ef499410c5f5a0fbcd86b658a2cdabbd9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Wed, 13 Mar 2019
haracter
> limit.
>
> Attached is an updated patch.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
and pass tests.
Here is an updated patch. It includes the typo fix in the documentation
from you, some small bug fixes, a new reindexdb --concurrently option,
and based on that some whole-database tests, as discussed recently.
I think this addresses all open issues.
--
Peter Eisentraut
/db/schema.rb
I don't have time to confirm all this right now, but I am pretty
confident that they have both problems. And almost as confident that
they'd notice substantial benefits from this patch series.
--
Peter Geoghegan
On 2019-03-11 08:23, Peter Eisentraut wrote:
> Variables used after a longjmp() need to be declared volatile. In
> case of a pointer, it's the pointer itself that needs to be declared
> volatile, not the pointed-to value. So we need
>
> PyObject *volatile it
ust
unsets PGAPPNAME around pg_ctl invocations in the testing library, and
then adjusts the tests to remove no longer needed application_name
overrides.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 9b9e317882ee3
On 2019-02-15 15:02, Alexey Bashtanov wrote:
> Hello Anders and Peter,
>
> Thanks for your messages.
> Please see the new patch version attached.
In my testing, I couldn't get this patch to do anything. Could you
please share your testing steps?
I did
postgres -D data --
e() function that _bt_checkkeys() must sometimes
call. It also allows us to only call BTreeTupleGetNAtts() for the high
key, while passes down a generic, loop-invariant
IndexRelationGetNumberOfAttributes() value for non-pivot tuples.
I'll do it that way in the next revision.
Thanks
--
Peter Geoghegan
m, I don't
> see a problem in following the same for development environment also?
I think the potential problems of getting this wrong are bigger than the
issue we are trying to fix.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-02-28 23:41, Alvaro Herrera wrote:
> Maybe ADD GENERATED AS IDENTITY / DROP IDENTITY should recurse; not
> really sure about this one. Peter?
No, the intention is that only the partition root has the identity
property. If you wanted to make it recurse, then you'd need to ar
elete local $ENV{PGAPPNAME};
...
}
But that is documented as new in Perl 5.12.0, so we might not be able to
use it. It appears to work in the 5.8.9 I have lying around, so I'm
confused.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I have committed this separately.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
gt;> The solution to that is to do 'local %ENV = %ENV;', to assign a copy of
>> the original to the localised variable.
>
> That's the right thing, not what I wrote. We use that in
> src/bin/initdb/t/001_initdb.pl.
Great. Committed that way.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ecks won't catch this, because the keys are similar
enough one level down. The "minus infinity" item is a kind of a blind
spot, because we cannot do a parent check of its children, because we
don't have the key (it's truncated when the item becomes a right page
minus infinity item, during an internal page split).
--
Peter Geoghegan
ime they're not "absolute minus infinity" -- they're "minus
infinity in this subtree".
Maybe you could actually do something with the high key from leaf page
5 to detect the stray value "20" in leaf page 6, but again, we don't
do anything like that right now.
--
Peter Geoghegan
On Sat, Mar 16, 2019 at 9:55 AM Peter Geoghegan wrote:
> On Sat, Mar 16, 2019 at 9:17 AM Heikki Linnakangas wrote:
> > Hmm. "re-find", maybe? We use that term in a few error messages already,
> > to mean something similar.
>
> WFM.
Actually, how about "r
ion that
you could also detect, but can't. But you'd have to be extraordinarily
unlucky to have that happen for any amount of time. Unlucky even by my
own extremely paranoid standard.
--
Peter Geoghegan
On Sat, Mar 16, 2019 at 1:47 PM Peter Geoghegan wrote:
> I agree that it's always true that the high key is also in the parent,
> and we could cross-check that within the child. Actually, I should
> probably figure out a way of arranging for the Bloom filter used
> within bt_r
On Sat, Mar 16, 2019 at 2:01 PM Peter Geoghegan wrote:
>
> On Sat, Mar 16, 2019 at 1:47 PM Peter Geoghegan wrote:
> > I agree that it's always true that the high key is also in the parent,
> > and we could cross-check that within the child. Actually, I should
> >
llback doing something else, which result in somehow strange code, where
> you have to guess that the transaction is restarted in all cases, either
> within the commit function or explicitely.
I have updated the SPI interface with your suggestions. I agree it's
better that way.
ty. Neither of
these sound like obviously better alternatives.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
phisticated tools and the exclusive mode is more for manual or simple
scripted use.
If we do think that the exclusive mode will be removed in PG13, then I
don't think we need further documentation changes. It already says it's
deprecated, and we don't need to justify that at length.
right now. I would have
preferred that pg_basebackup require an explicit option to turn on group
access, similar to initdb.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
1701 - 1800 of 10756 matches
Mail list logo
