On 2020-01-28 04:05, Mark Dilger wrote:
German uses both Sonnabend and Samstag for Saturday, so don’t you have to
compare to a list of values anyway?
Yeah, good point. If it doesn't accept both "Sonnabend" and "Samstag",
then it's not really usable.
--
Pete
feels like that should be outside to_date's
purview.
To clarify, nothing in my examples was meant to imply that de-accenting
might be necessary. AFAICT, the accented forms are the only
linguistically acceptable forms and all the locale libraries accept them
correctly in their accente
t works, but
it would be good to have a test for, in case of future restructuring.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
s more tests. We are designing this
delicate mechanism but have no real tests for it. We at least need to
come up with a framework for how to test this automatically, so that we
can add more test cases over time as people will invariably report
issues when this hits the real world.
xists now (and
it's quasi SQL standard now), we might as well fill in this gap.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
the same patches here a second time for completeness.
--
Peter Geoghegan
From 8f55bcedaa9c109543627e9c785dab0ffb0e5c75 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Wed, 22 Jan 2020 20:59:57 -0800
Subject: [PATCH v2 3/3] Remove "negative infinity" check from _bt_compare().
On Thu, Jan 16, 2020 at 12:05 PM Peter Geoghegan wrote:
> > It does seem odd to me to treat them differently, but it's possible
> > that this is a reflection of my own lack of understanding. What do
> > other database systems do?
>
> Other database systems treat un
ter than it needs
to be, or something along those lines.
--
Peter Geoghegan
in the mix, too. I'd still not wish to rely on this for debugging.
I agree that there are a lot of moving pieces here. I wouldn't like to
have to rely on this working myself.
--
Peter Geoghegan
On Fri, Mar 22, 2019 at 2:15 PM Peter Geoghegan wrote:
> On Thu, Mar 21, 2019 at 10:28 AM Peter Geoghegan wrote:
> > I'll likely push the remaining two patches on Sunday or Monday.
>
> I noticed that if I initidb and run "make installcheck" with and
> w
are with the
backend than alternatives, then nothing is standing in the way of
continuing to use that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
be welcome.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-04-01 10:52, Peter Eisentraut wrote:
> On 2019-03-31 05:49, Erik Rijkers wrote:
>> STORED in a
>> file_fdw foreign table still silently creates the column which then
>> turns out to be useless on SELECT, with an error like:
>>
>> "ERROR: column
uperflous line to make gist logically
> broken. This triggers regression test of amcheck.
Any thoughts on this, Heikki?
It would be nice to be able to squeeze this into Postgres 12,
especially given that GiST has been enhanced for 12 already.
--
Peter Geoghegan
0.0.0.0/0 md5
it is not obvious that this means, if GSS-encrypted, use md5. It could
just as well mean, if GSS-authenticated, use md5.
The analogy with SSL is such that we use "hostssl" for connections using
SSL encryption and "cert" for the authe
On 2019-04-02 20:54, Erik Rijkers wrote:
> attached is run_ft.sh which creates a text file: /tmp/pg_head.txt
> then sets it up as a foreign table, and adds a generated column.
>
> Then selects a succesful select, followed by a error-producing select.
I have committed a fix for this
27;2'
# expected: '0'
(and repeated for several other tests).
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
data does not satisfy the
generation expression. That is the case here. I don't know of a
principled way to prevent that. It's just one of the problems that can
happen when you store data in a foreign table: You have very little
control over what data actually ends up being stored.
--
llify the utility of pg_upgrade. I can restore the essential tables from
> backup in 15-30 minutes.
I think the real fix is to have pg_upgrade copy over the statistics.
They are right there after all, just take them.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL De
On 2019-04-04 17:16, Tom Lane wrote:
> BTW, the kerberos test suite takes nearly 4 minutes for me, is
> it supposed to be so slow?
I've seen this on some virtualized machines that didn't have a lot of
entropy.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postgr
pushed something very close to the patch you posted. (I added
an additional assertion, and tweaked the comments.)
Thanks for the report and patch!
--
Peter Geoghegan
aes256-cts-hmac-sha1-96
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-03-18 20:08, Peter Eisentraut wrote:
> I agree that it would be useful to document and discuss better which
> built-in operators are leak-proof and which are not. But I don't think
> the CREATE POLICY reference page is the place to do it. Note that the
> leak-proofn
ith the patch applied to
current master, using the test case from Yoshikazu Imai (2019-03-19).
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
eans that this encryption feature is not supported on
that (presumably older) installation? (krb5-config --version says
"Kerberos 5 release 1.7-prerelease") Is that plausible? Is a gentler
failure mode possible?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-03-19 10:21, Tsunakawa, Takayuki wrote:
> From: Tsunakawa, Takayuki [mailto:tsunakawa.ta...@jp.fujitsu.com]
>> Fixed.
>
> Rebased on HEAD.
Do you need the dlist_foreach_modify() calls? You are not actually
modifying the list structure.
--
Peter Eisentraut
is cumbersome,
and as we are seeing now, it is not quite clear which cases it is
supposed to cover. There are also additional cases for binary
parameters, and there are additions to the CSV output format. We need
tests for all that so the behavior explains itself and doesn't have to
t might be nice to have a column in the view not only for the table OID
but also the index OID. That is obviously not so useful for CREATE
INDEX but more useful for REINDEX. I haven't looked into how adding
that would work.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Postgre
yption without auth'
# at t/002_enc.pl line 170.
# got: '2'
# expected: '0'
not ok 4 - GSS unencrypted fallback
# Failed test 'GSS unencrypted fallback'
# at t/002_enc.pl line 170.
# got: '2'
# expected: '0'
ok 5
nts.
> Yeah, I think that's simple enough -- the CLUSTER one already does that,
> I think.
Added that.
> Another thing for REINDEX TABLE is that we should add a count
> of indexes to process, and how many are done.
Reasonable, but maybe a bit too much for the last moment.
--
Pet
Should we change the default of the password_encryption setting to
'scram-sha-256' in PG12?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
he net effects of this patch on workloads
> that aren't specifically about large and prunable partition sets.
In my testing, I've also noticed that it seems to be slightly on the
slower side for these simple tests.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL De
On 2019-04-06 06:40, Alvaro Herrera wrote:
> On 2019-Apr-05, Peter Eisentraut wrote:
>
>> I've reworded the phases a bit. There was a bit of a mixup of waiting
>> for snapshots and waiting for lockers. Perhaps not so important from a
>> user's perspective, but
On 2019-04-04 12:43, Michael Paquier wrote:
> I would like to apply this down to 9.5 for the checkpoint part and
> down to 11 for the role part, so if anybody has any comments, please
> feel free.
How about some tests to show that this is actually true?
--
Peter Eisentraut
gt; Would it make sense to clarify this on CREATE FOREIGN TABLE page?
done
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
nning just 002_enc.pl by itself passes the tests!
> I've also reached out to some colleagues about having one of them test
> with MacOS. What version are you on..?
macOS 10.14.14 it says.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2019-04-08 05:46, Tsunakawa, Takayuki wrote:
> I'm registering you as another author and me as a reviewer, and marking this
> ready for committer.
Moved to next commit fest.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On 2019-04-08 13:52, Andrew Dunstan wrote:
> Yeah, if we're not going to do it now we should announce that we will
> do it in the next release.
Targeting PG13 seems reasonable.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
committed, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
the item
pointer overhead?
I wonder if we should add an assertion based on the pd_special offset
of the page to PageGetFreeSpace(). That would make it harder to make
mistakes like this in the future. Maybe it would be better to revise
the whole API instead, though.
--
Peter Geoghegan
hat use conventional line pointers.
--
Peter Geoghegan
ncies (which also vary by OS) it's not a proper
> replacement for a type of facility a very sizable fraction of our users
> need.
Yeah, I think implementing a v4 generator in core would be trivial and
address almost everyone's requirements.
--
Peter Eisentraut http:
hat seems reasonable. It also avoids the large amount of duplicate
setup code.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
n/ or anywhere else that
> I can find. So I speculate that Peter is running some weird hodgepodge
> of Apple and Homebrew code, making the question not so much "why does
> it fail" as "how did it ever work".
Yes, you need a krb5 installation from either Homebrew or MacPort
ose appear to be mostly for internal use.
Also, there is GCC_COLORS, LS_COLORS, etc. But perhaps this wisdom will
be lost on users who just read the man page and get confused. ;-)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
;t be able to call whatever we rename PageGetFreeSpace()
to.
--
Peter Geoghegan
ial files.
Are there by any chance standard file formats and tools that describe a
binary difference between directories? That would be really useful here.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
C-Tree?
Peter Geoghegan
(Sent from my phone)
On 2019-04-09 13:58, Christoph Berg wrote:
> I'm not entirely sure what happened here, but I think this made
> pg_restore verbose by default (and there is no --quiet option).
That was by accident. Fixed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Develo
t is a great analysis. Seems like block-level is the preferred way
forward.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Yeah, that would be annoying. Let's not do that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
nflict problem
Well, whatever we do -- if anything -- we would certainly need to keep
the old names around for a while somehow. So this doesn't really make
that issue go away.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi all,
I understood that v11 includes predicate locking for gist indexes, as per
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3ad55863e9392bff73377911ebbf9760027ed405
.
I tried this in combination with an exclude constraint as following:
drop table if exists t;
create table t(
deal with this situation, by
consolidating the old and new tests in some way. I don't think that
your work needs to block on that, though.
> Thoughts? Anyone object to making these sorts of changes
> post-feature-freeze?
IMV there should be no problem with pushing ahead with this after
feature freeze.
--
Peter Geoghegan
e for every tuple on v4
indexes. The original fastpath tests won't tickle the implementation
in any interesting way in my opinion.
--
Peter Geoghegan
On Wed, Apr 10, 2019 at 4:56 PM Peter Geoghegan wrote:
> The original fastpath tests don't seem particularly effective to me,
> even without the oversight I mentioned. I suggest that you remove
> them, since the minimal btree_index.sql fast path test is sufficient.
To be clear:
omit all the actual data and just mention
> which blocks were changed by some record in that part of the WAL.
That seems better than the other variant.
> Yet another question is how to make sure WAL doesn't get removed
> before we finish scanning it. Peter mentioned on the other th
On Thu, Apr 11, 2019 at 1:14 AM Thomas Munro wrote:
> On Thu, Apr 11, 2019 at 10:54 AM Thomas Munro
> wrote:
> > On Thu, Apr 11, 2019 at 9:43 AM Peter Billen
> wrote:
> > > I kinda expected/hoped that transaction t2 would get aborted by a
> serialization error, an
a useful resource. I would at least like
to know the settings used by its builds.
--
Peter Geoghegan
On Thu, Apr 11, 2019 at 6:12 PM Peter Billen wrote:
>
> I believe we are after multiple issues/improvements:
>
> 1. Could we extend
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=fcff8a575198478023ada8a48e13b50f70054766
> by adding support for exclude const
efer to
have optimizations enabled if I was optimizing my code, but that's not
what the web resource is for, really.
Thanks
--
Peter Geoghegan
new index definition track
>> relispartition from the old index.
>> - Again at swap time, the inheritance link needs to be updated between
>> the old/new index and its parent when reindexing a partition index.
>
> Peter, this is an open item, and I think as the committer of th
se.
Proposed patch attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From acb1542a1f8ebee9c9d6d9322c64c849b2f23e15 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 12 Apr 2019 09:49:10 +0200
S
On 2019-04-09 09:32, Peter Eisentraut wrote:
> On 2019-04-09 04:51, Stephen Frost wrote:
>>> Running just 002_enc.pl by itself passes the tests!
>> Great! I think what I'll do is work to incorporate the two tests back
>> into one script, to avoid whatever the race
ul than the alternative.
--
Peter Geoghegan
able-debug would help, since llvm-gcov requires it,
but that doesn't seem particularly likely.
It's definitely generally recommended that "-O0" be used, so I think
that we can agree that that was an improvement, even if it doesn't fix
the remaining problem that I notice
On Fri, Apr 12, 2019 at 10:49 AM Peter Geoghegan wrote:
> It's definitely generally recommended that "-O0" be used, so I think
> that we can agree that that was an improvement, even if it doesn't fix
> the remaining problem that I noticed when I rechecked nbtutils
ible for that reason, but at
the same time the per-datum overhead seems very high to me. Maybe
prefix compression could help here, which a low key and high key can
do rather well.
--
Peter Geoghegan
inistic() in that case.
>
> Proposed patch attached.
>
> Looks fine to me.
Committed, thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
would be difficult to
impossible as a practical matter.
Unfortunately, you're both right. I don't know where that leaves us.
--
Peter Geoghegan
e until the project begins to mature. I have little faith in our
ability to predict which approach will be the least painful at this
early stage.
--
Peter Geoghegan
On Mon, Apr 15, 2019 at 9:16 AM Ashwin Agrawal wrote:
> Would like to know more specifics on this Peter. We may be having different
> context on hybrid row/column design.
I'm confused about how close your idea of a TID is to the traditional
definition from heapam (and even zheap)
That's one of the reasons why I've been trying to get you to get on
> board with allowing different leaf-level "item pointer equivalents"
> widths inside nbtree...
Getting me to agree that that would be nice and getting me to do the
work are two very different things. ;-)
--
Peter Geoghegan
or the
TCP/IP case that we don't currently provide. It's probably of marginal
use, as you also say.
I don't get what this has to do with walsenders specifically. Do they
have each walsender connect to a different socket?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
gt; After thinking some more on it, this behavior looks rather sensible to
> me. Are there any objections?
Looks good to me.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
of multiple patches.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
st right? (I have noticed that it
> is done this way since the beginning.)
We got rid of all the reloads in these kinds of tests because they have
the effect that if the configuration has an error, the reload just
ignores it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Po
us infinity items, and actually store a "low key"
at P_FIRSTDATAKEY() within internal pages instead. That would be
useful for other things anyway (e.g. prefix compression).
--
Peter Geoghegan
On Tue, Apr 16, 2019 at 12:00 PM Peter Geoghegan wrote:
> Can you be more specific? What was the cause of the corruption? I'm
> always very interested in hearing about cases that amcheck could have
> detected, but didn't.
FWIW, v4 indexes in Postgres 12 will support t
, rather than counting tuples per se.
I like that idea, but I'm pretty sure that there are very few users
that are aware of these distinctions at all. It would be a good idea
to clearly document them.
--
Peter Geoghegan
r us to detect.
I'll create an open item for this, and begin work on a patch tomorrow.
--
Peter Geoghegan
On 2019-03-25 09:04, Peter Eisentraut wrote:
> So perhaps push the check down to GetRelationPublicationActions()
> instead. That way we don't have to patch up two places and everything
> "just works" even for possible other callers. See attached patch.
This has been comm
On Wed, Apr 17, 2019 at 7:37 PM Peter Geoghegan wrote:
> Tentatively, I think that the fix here is to not "itup_key->scantid =
> NULL" when a NULL value is involved (i.e. don't "itup_key->scantid =
> NULL" when we see IndexTupleHasNulls(itup) within _bt_
bute was NULL. It should only do that when a key attribute is
NULL.
--
Peter Geoghegan
On Thu, Apr 18, 2019 at 8:13 PM Peter Geoghegan wrote:
> It just occurred to me that the final patch will need to be more
> careful about non-key attributes in INCLUDE indexes. It's not okay for
> it to avoid calling _bt_check_unique() just because a non-key
> attribute was NUL
casionally saving a MAXALIGN() quantum in space this
way. It is unlikely that anyone would actually care very much about
these kinds of space savings, but at the same time it feels more
elegant to me. The heap TID may not have a pg_attribute entry, but
ISTM that the on-disk representation should not have padding "in the
wrong place", on general principle.
Thoughts?
--
Peter Geoghegan
reeTupleGetHeapTID() works just as
well with either the existing scheme, or this new one. Having the
"real" tuple length available will make it easier to implement "true"
suffix truncation, where we truncate *within* a text attribute (i.e.
generate a new, shorter value using new opclass infrastructure).
--
Peter Geoghegan
to the identifier (or perhaps
its length), plus the usual t_info stuff. We'd almost invariably waste
4 or 5 bytes, which seems like a problem to me.
--
Peter Geoghegan
e
nbtree (nbtree won't when I'm done, though, because it will actively
try to preserve the "real" tuple size). It's convenient to me that no
caller seems to rely on the index_form_tuple() MAXALIGN() that I want
to remove.
--
Peter Geoghegan
of
bugs in quite a variety of contexts.
--
Peter Geoghegan
/fd.c layering is confusing in a number of ways IMV.
--
Peter Geoghegan
On 2019-04-01 11:23, Peter Eisentraut wrote:
> On 2019-03-31 04:57, Andres Freund wrote:
>> while rebasing the remaining tableam patches (luckily a pretty small set
>> now!), I had a few conflicts with ExecComputeStoredGenerated(). While
>> resolving I noticed:
>
>
On Fri, Apr 19, 2019 at 6:34 PM Peter Geoghegan wrote:
> Attached revision does it that way, specifically by adding a new field
> to the insertion scankey struct (BTScanInsertData).
Pushed.
--
Peter Geoghegan
lignment rules seem to make it
worthwhile to keep the heap TID in the tuple header; it seems
inherently necessary to have a MAXALIGN()'d tuple header, so finding a
way to consistently put the first MAXALIGN() quantum to good use seems
wise.
--
Peter Geoghegan
On Wed, Apr 24, 2019 at 10:43 AM Peter Geoghegan wrote:
> The hard part is how to do varwidth encoding for space-efficient
> partition numbers while continuing to use IndexTuple fields for heap
> TID on the leaf level, *and* also having a
> BTreeTupleGetHeapTID()-style macro to g
to disable the trace_sort instrumentation my commenting out
the TRACE_SORT entry in pg_config_manual.h. I recall being opposed on
this point by Robert Haas. Possibly because he just didn't want to
deal with it at the time.
--
Peter Geoghegan
wkward position of no
longer quite meeting the traditional definition of a "developer
option".
--
Peter Geoghegan
ntation is good, and you seem to be saying that it is, I
> think we should just remove the symbol and be done with it.
Sounds like a plan. Do you want to take care of it, Joe?
--
Peter Geoghegan
ailable by the new
pg_stat_progress_create_index view, but with getrusage() stats.
--
Peter Geoghegan
roaches over the
other, though I don't really know how to assess this layering
business. I'm glad that either approach will prevent oversights,
though.
--
Peter Geoghegan
2601 - 2700 of 10774 matches
Mail list logo
