documents. Even if PostgreSQL just had one big index in to the 5
separate documents, that would help.
Peter
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On 2/22/16 6:24 PM, Jim Nasby wrote:
> On 2/5/16 10:08 AM, David Fetter wrote:
>> On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
>>> I just discovered that ./configure will happily accept
>>> '--with-pgport=' (I
>>> was actually doing =$PGPORT, and didn't realize $PGPORT was empty).
>>>
somewhere that is not just a text file).
So I propose the two attached patches that introduce new configuration
Boolean parameters syslog_sequence_numbers and syslog_split_lines that
can toggle these behaviors.
From e6a17750956e3e6950683bad397a74adb30f30a2 Mon Sep 17 00:00:00 2001
From: Peter
ep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sun, 28 Feb 2016 20:21:54 -0500
Subject: [PATCH 1/3] pg_ctl: Add tests for promote action
---
src/bin/pg_ctl/t/003_promote.pl | 62 +
src/test/perl/TestLib.pm| 11
2 files changed, 73 insertion
The pg_resetxlog reference page has grown over the years into an
unnavigable jungle, so here is a patch that reorganizes it to be more in
the style of the other ref pages, with a normal options list.
From a9024195e9f7a0b47e592f39938bdc9743152a70 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
ss time than having to REINDEX the index,
and doesn't need too much memory. I think that in practice most
problems that can be detected by the B-Tree checker functions will be
detected with the lighter variant.
--
Peter Geoghegan
From 573810d8d3c994ce1a16ecffb2f5d208c0ff93e3 Mon Sep 17 00:00:00
On 2/8/16 9:36 AM, David Steele wrote:
> -#define XLogIsNeeded() (wal_level >= WAL_LEVEL_ARCHIVE)
> +#define XLogIsNeeded() (wal_level >= WAL_LEVEL_REPLICA)
> <...>
> -#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_HOT_STANDBY)
> +#define XLogStandbyInfoActive() (wal_level >= WAL_LEVEL_REP
replication slots can only be
> used if wal_level >= archive")));
> We should still forbid the creation of replication slots if wal_level =
> minimal.
I think I took this out because you actually can't get to that check,
but I put it back in because it seems better for clarit
been on
both sides of this, as a patch author and patch reviewer. If the patch
was left as "Waiting on Author", as my review of Alexander's patch
was, then it ought to not change to "Needs Review" silently. That
makes absolutely no sense.
--
Peter Geoghegan
--
Sent vi
On Wed, Mar 2, 2016 at 5:41 AM, Magnus Hagander wrote:
> Ok, I've pushed a code that does that.
Thank you.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
do is restrict the functions to throw an error when
called by non-superusers, out of caution.
It's a problem that modules like pg_stat_statements and
pg_freespacemap are currently lumped together in the documentation,
but we all know that.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailin
On 2/11/16 9:30 PM, Michael Paquier wrote:
>> Well, Yury was saying upthread that some MSVC versions have a problem
>> with the existing coding, which would be a reason to back-patch ...
>> but I'd like to see a failing buildfarm member first. Don't particularly
>> want to promise to support compi
On 2/5/16 5:04 AM, Peter Geoghegan wrote:
> As Heikki goes into on that thread, the appropriate action seems to be
> to constantly reset the error queue, and to make sure that we
> ourselves clear the queue consistently. (Note that we might not have
> consistently called ERR_get_er
On 2/17/16 10:52 PM, Michael Paquier wrote:
> On Thu, Feb 18, 2016 at 1:58 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> Hi all,
>>>
>>> After looking at Alvaro's message mentioning the handling of
>>> PQsocket() for invalid sockets, I just had a look by curiosity at
>>> other calls of
o get agreement about something abstract, like the
general idea of a distributed transaction manager. I fear that any
particular detailed interpretation of what that phrase means will be
very hard to get accepted into PostgreSQL.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
vrkkasy1xbshgzxkd6-hnxx3gq7x-p-dz0zt...@mail.gmail.com
In summary, I think it's surprising that a max_parallel_degree of 1
doesn't disable parallel workers entirely.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
w useful is it in the general case? I'm not
suggesting that it isn't, but I'm not sure.
How common is it for the leader process to do anything other than
coordinate and consume from worker processes?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
.
--
Peter Geoghegan
From bc481af77994057cb1ffe4a0e471b38bb00dc228 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Mon, 7 Mar 2016 13:16:24 -0800
Subject: [PATCH] Avoid incorrectly indicating exclusion constraint wait
INSERT ... ON CONFLICT's precheck may have to wait on the outcome of
an
ls apart for some reason, I'll update this. I
> plan to push this RSN if nobody objects.
Thanks for making the effort to make the tool generally available.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
hin ~5% of an *internal* sort with the patch series
applied, even though ~80% of time is spent copying and sorting
SortTuples overall in the internal sort case (the internal case cannot
overlap sorting and aggregate processing, since it has no final merge
step). This is a nice demonstration of ho
On 3/8/16 4:44 PM, Robert Haas wrote:
> On Mon, Feb 29, 2016 at 4:50 PM, Thomas Munro
> wrote:
>> On Sat, Feb 20, 2016 at 5:14 PM, Peter Eisentraut wrote:
>>> Here are three patches to fix new warnings in GCC 6.
>>>
>>> 0001 is apparently a typo.
>>
On 3/4/16 11:01 AM, Alexander Korotkov wrote:
> On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut <mailto:pete...@gmx.net>> wrote:
>
> Writing log messages to syslog caters to ancient syslog implementations
> in two ways:
>
> - sequence numbers
> -
On 3/8/16 9:12 PM, Andreas Karlsson wrote:
> As someone who uses syslog for my servers I find both of these GUCs
> useful, especially when used in combination, and I do not think a
> compile time option like suggest by Alexander would be suitable
> substitute because then I would need a custom buil
On 2/12/16 11:24 AM, Christian Ullrich wrote:
> Otherwise, it may be time to update the manual (15.6 Supported
> Platforms) where it says PostgreSQL "can be expected to work on these
> operating systems: [...] Windows (Win2000 SP4 and later), [...]".
> Perhaps we could add "except Windows before 7
update coming.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
sn't really a concern anymore. I think we may be
able to comprehensively address Robert's concerns about regressions
with very little work_mem and lots of data by fixing a problem with
polyphase merge. More to come soon.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-
y-paste coding.
>
> +1. Frustrating Citus's attempt to open-source their stuff is not in
> the project's interest.
I agree.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Mar 10, 2016 at 2:50 PM, Robert Haas wrote:
> So what's the next step here? Peter G, are you planning to update the
> patch based on this review from Peter E? If not, Peter E, do you want
> to update the patch and commit? If neither, I'm going to mark this
> Ret
On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote:
> Getting to it very soon. Just really busy right this moment.
That said, I agree with Peter's remarks about doing this frontend and
backend. So, while I'm not sure, I think we're in agreement on all
issues. I would ha
On 3/10/16 6:10 PM, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote:
>> Getting to it very soon. Just really busy right this moment.
>
> That said, I agree with Peter's remarks about doing this frontend and
> backend. So, while I'
On 3/4/16 3:55 PM, Alvaro Herrera wrote:
> * it failed to check for S_IXUSR, so permissions 0700 were okay, in
> contradiction with what the error message indicates. This is a
> preexisting bug actually. Do we want to fix it by preventing a
> user-executable file (possibly breaking compability wi
Looked at your proposed patch. Will respond to your original mail on the matter.
On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote:
> I think clearing the error after a call is not necessary. The API
> clearly requires that you should clear the error queue before a call, so
> cl
On Sun, Feb 14, 2016 at 8:01 PM, Peter Geoghegan wrote:
> The query I'm testing is: "reindex index pgbench_accounts_pkey;"
>
> Now, with a maintenance_work_mem of 5MB, the most recent revision of
> my patch takes about 54.2 seconds to complete this, as compared to
On 3/10/16 9:38 PM, Peter Geoghegan wrote:
> Looked at your proposed patch. Will respond to your original mail on the
> matter.
>
> On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote:
>> I think clearing the error after a call is not necessary. The API
>> clearly
On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote:
> Arguably, if everyone followed "my" approach, this should be very easy
> to fix everywhere.
I don't think that there is any clear indication that the OpenSSL
people would share that view. Or my view. Or anythi
e documentation. I
don't know what can be done about that.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
return compare;
There are many options when you want to produce a corrupt B-Tree index!
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Mar 11, 2016 at 1:09 PM, Peter Geoghegan wrote:
> Or, you could add code like this to comparetup_index_btree(), to
> simulate a broken opclass:
>
> diff --git a/src/backend/utils/sort/tuplesort.c
> b/src/backend/utils/sort/tuplesort.c
> index 67d86ed..23712ff 100644
&
th the left-right keyspace checks, which don't have relation
ExclusiveLock protection (IOW, I think that that might be buggy). I
need to think about that some more, but current thinking is that it
would hardly matter if we used the highkey from right page rather than
the first data item,
On Fri, Mar 11, 2016 at 1:31 PM, Peter Geoghegan wrote:
> You could have a race, where
> there was a concurrent page deletion of the left sibling of the child
> page, then a concurrent insertion into the newly expanded keyspace of
> the parent. Therefore, the downlink in the parent (
utes/columns past the first distinguishing/distinct attribute on
each item on internal pages). That's a case that amcheck then needs to
care about, just like it currently cares about the existing concept of
minus infinity items. That's how it goes for amcheck.
--
Peter Geoghegan
ndex relation.
Not sure about the cost delay thing. Delays are disabled by default
for manually issued VACUUM, so have doubts that that's useful.
If you want the tool to limp on when it finds an error, that can be
done by changing the constant for the CORRUPTION macro in amcheck.c.
But hav
On Fri, Mar 11, 2016 at 4:17 PM, Peter Geoghegan wrote:
> If you want the tool to limp on when it finds an error, that can be
> done by changing the constant for the CORRUPTION macro in amcheck.c.
> But having that be dynamically configurable is not really compatible
> with the go
I'll add that if people like the interface you propose. (Overloading
the VACUUM cost delay functions to cause a delay for amcheck
functions, too). Note that the functions already use an appropriate
buffer access strategy (it avoids blowing shared_buffers, much like
VACUUM itself).
--
Peter
On 1/7/16 9:40 PM, Marisa Emerson wrote:
> There's a port for PAM, but we would prefer to use BSD Auth as its quite
> a lot cleaner and is standard on OpenBSD.
>
> I've attached an updated patch that includes documentation. It has been
> tested against OpenBSD 5.8. I'll add this thread to the comm
On 3/11/16 4:38 PM, Thomas Munro wrote:
> It looks like this needs review from an OpenBSD user specifically.
> FreeBSD and NetBSD use PAM instead of BSD auth.
FreeBSD has man pages for this stuff, so maybe they also have it now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
diagnosing a
problematic opclass, you have to be an expert, and tweaking amcheck
for your requirements (i.e. rebuilding from source) becomes
reasonable. Part of the reason that the code is so heavily commented
is to make it hackable, because I do not feel optimistic that I can
get an expert-orientat
tch is basically uncontroversial, and is built to
make the AM interface clearer, and the design of speculative insertion
easier to understand. It's clear we should have it. I'll get around to
revising it before too long.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hacker
gorically
stated was that he disliked one narrow aspect of the style of one
thing in one function. I've already said I'm happy to do that.
As things stand, the documentation for amcanunique methods, and the
way they are described internally, is fairly misleading.
--
Peter Geoghega
On Sat, Mar 12, 2016 at 2:53 PM, Peter Geoghegan wrote:
> I said "basically uncontroversial", not "uncontroversial". That is a
> perfectly accurate characterization of the patch, and if you disagree
> than I suggest you re-read the thread.
In particular, note that Al
open source a
> version of it later this week that way you can use it for testing.
That could be interesting. The earlier prototypes of this tool are
known to have detected glibc collation incompatibilities in real
production systems.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing li
or performance tips will probably only work
well if there are still high standards that are actively enforced.
There still needs to be tight editorial control.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Thu, Mar 10, 2016 at 8:16 PM, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote:
>> Arguably, if everyone followed "my" approach, this should be very easy
>> to fix everywhere.
>
> I don't think that there is any clear indica
pecially compelling feature.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Mar 14, 2016 at 3:06 PM, Tom Lane wrote:
> Agreed, we need to deal with this one way or the other. My proposal
> is:
>
> 1. In HEAD, do it as Peter E. suggests, ie clear error queue before calls.
>
> 2. In back branches, clear error queue before *and* after calls. T
e right
> about the risk of latent bugs.
Yes, with one small difference: I wouldn't be calling ERR_get_error()
in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
the theory that skipping that case represents no risk. I'm making a
concession to Peter E's view that t
x 9.6 patches
to review, most of which are in need of support. I'm very busy.
I said that I'd get to this patch soon. I might be kicking the can
down the road a little with this patch; if so, I'm sorry. I suggest we
leave it at that, until the CF is almost over or until I produce
On Mon, Mar 14, 2016 at 5:21 PM, Andres Freund wrote:
> So? You're not the only one. I don't see why we shouldn't move this to
> 'returned with feedback' until there's a new version.
I don't see any point in that; I intend to get a revision in to the
o
On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote:
> Yes, with one small difference: I wouldn't be calling ERR_get_error()
> in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
> the theory that skipping that case represents no risk. I'm making a
> c
On Mon, Mar 7, 2016 at 1:46 PM, Peter Geoghegan wrote:
> Attached patch fixes a bug reported privately by Stephen this morning.
Bump.
I would like to see this in the next point release. It shouldn't be
hard to review.
Thanks
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing lis
"/truncated attributes are involved. This
seems necessary. No?
It's necessary because you aren't storing any attributes, so it's not
acceptable to even attempt a comparison -- I think that will segfault
(doesn't matter that the index scan wouldn't have returne
On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan wrote:
>
> Does this work with amcheck? Maybe it works with bt_index_check(), but
> not bt_index_parent_check()? I think that you need to make sure that
> _bt_compare() knows about this, too. That's because it isn't good
>
On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan wrote:
> * I think the comparison logic may have a bug.
>
> Does this work with amcheck? Maybe it works with bt_index_check(), but
> not bt_index_parent_check()? I think that you need to make sure that
> _bt_compare() knows about th
ually). I
haven't actually tested this theory of mine myself just yet, but let
me know what you think of it on the thread for your patch.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
such a
mapping itself extensible seems even more tricky, which is what it
would take, I suspect. Indexing is always of great importance for
jsonb. It's already too complicated.
--
Peter Geoghega
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nternal pages are checked against actual child pages (every item in
the child page, in fact). It's the parent/child relationship that is
verified in addition to the standard checks of every page on and
across (not between) every level.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailin
s a non-native speaker of English language, who
> ends up looking up quite a few words regularly) -
>
> Could we use "conform" or "correspond" instead of "comport" in the
> following error message:
>
> "left link/right link pair in index \"%s\&q
. This test suite would indirectly test
external sorting, B-Tree page deletion, edge-cases with very large
IndexTuples, etc.
Ideas for good areas of the B-Tree code to add tests for are welcome.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 3/15/16 2:28 PM, Jernigan, Kevin wrote:
> I recently joined the product management team for AWS RDS Postgres
> (after years at Oracle in their database team), and we are very
> interested in confirming (or not) that the fix for the problem below
> will be included in 9.5.2, and in the community’
On Tue, Mar 15, 2016 at 6:18 AM, Stephen Frost wrote:
> Agreed. I'm going to play with it a bit more but barring objections,
> I'll commit and back-patch Peter's patch.
Thanks for taking care of this, Stephen.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailin
On Mon, Mar 14, 2016 at 8:43 PM, Peter Geoghegan wrote:
> Does this work with amcheck? Maybe it works with bt_index_check(), but
> not bt_index_parent_check()? I think that you need to make sure that
> _bt_compare() knows about this, too. That's because it isn't good
> eno
On 3/10/16 8:11 AM, Grzegorz Sampolski wrote:
> In attchment new patch with updated documentation and with small change
> to coding style as you suggested.
This patch seems fine. I'm not sure about the name "pamusedns" for the
option, since we use the OS resolver, which might not actually use DNS
On 2/26/16 1:30 AM, Tom Lane wrote:
> As the patch is presented, I agree with Peter that it does not really
> need a format number bump. The question that has to be answered is
> whether this solution is good enough? You could not trust it for
> automated processing of tags ---
On 2/5/16 3:09 AM, Kyotaro HORIGUCHI wrote:
> I considered how to make tab-completion robust for syntactical
> noises, in other words, optional words in syntax. Typically "IF
> (NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
> further completion.
To repeat the question I raised in
On 3/10/16 9:20 PM, Peter Eisentraut wrote:
> On 3/4/16 3:55 PM, Alvaro Herrera wrote:
>> * it failed to check for S_IXUSR, so permissions 0700 were okay, in
>> contradiction with what the error message indicates. This is a
>> preexisting bug actually. Do we want to f
_split_lines to syslog_split_messages, which I think is more accurate.
From 70bacecba46eb38c02c43957c2f1812faf5684df Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Fri, 26 Feb 2016 22:34:30 -0500
Subject: [PATCH 1/2] Add syslog_sequence_numbers parameter
---
doc/src/sgml/config.sgml | 28 ++
came from the fact that historically,
when check_exclusion_or_unique_constraint() was called
check_exclusion_constraint(), it (almost) was our own tuple that was
waited on.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
his is why I wanted an easy way of atomically guaranteeing some
number of workers (typically 2), or not using parallelism at all. I
think the parallel worker API should offer a simple way to do that in
cases like this, where having only 1 worker is never going to win.
--
Peter Geoghegan
--
Sent via p
what
wasn't so obvious to you when you review my patches. It's probably
impossible to stare at something like tuplesort.c for as long as I
have and get that balance just right.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
33/
Marked "Waiting on Author".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
losing anything important seems like a relatively straightforward
task.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 16, 2016 at 6:42 PM, Peter Geoghegan wrote:
>> - I think that batchmemtuples() is somewhat weird. Normally,
>> grow_memtuples() doubles the size of the array each time it's called.
>> So if you somehow called this function when you still had lots of
>> me
quot;Can SortTuple.tuple ever be set?", rather than allowing it
to remain a specific property of a datum tuplesort.
state->datumTypByVal often isn't initialized in master, and so cannot
be checked as things stand (unless the code is in a
datum-case-specific routine).
This new flag controls batch memory in slightly higher-level way than
would otherwise be possible. It also controls the memory prefetching
added by patch/commit 0003-*, FWIW.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
mat specifiers. However, I had a bad feeling about integer overflow
of state->currentRun, and think I'll need to address that. After all,
if runs are now no longer 2x work_mem on average, it's not completely
ridiculous to imagine that being an issue on a misconfigured system.
--
Pet
On Fri, Mar 18, 2016 at 11:43 AM, Andres Freund wrote:
> Yes, that removes the warning, and looks correct.
Thanks. We should be careful to not repeat this mistake when the
quicksort patch goes in.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
a bad idea
FWIW, I've seen this get out of hand several times myself.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Committed with the discussed adjustment and documentation update.
On 3/18/16 2:26 PM, Christoph Berg wrote:
> Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net>
>>>> * it failed to check for S_IXUSR, so permissions 0700 were okay, in
>>>> contradi
ndered pronouns has negative value, though, and it really isn't that
hard to fix. So we should just fix it.
(In case it matters, I'm in favor of this proposal on its merits).
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Committed with the discussed adjustment and documentation update.
On 3/18/16 2:26 PM, Christoph Berg wrote:
> Re: Peter Eisentraut 2016-03-16 <56e8c221.1050...@gmx.net>
>>>> * it failed to check for S_IXUSR, so permissions 0700 were okay, in
>>>> contradi
asy
to miss some of the subtleties.
I do not pursue something like this without good reason. I'm
optimistic that the patch will be accepted if it is carefully
considered.
--
Peter Geoghegan
From 2b2a4c40a5e60ac1f28a75f11204ce88eb48cc73 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
Date: Tue, 2
you consider making amcheck [1] a part of your testing
strategy. I think that this patch is a good idea, and I'd be happy to
take feedback from you on how to make amcheck more effective for
testing this patch in particular.
[1] https://commitfest.postgresql.org/9/561/
--
Peter Geoghegan
On Sun, Mar 20, 2016 at 4:25 PM, Peter Geoghegan wrote:
> I worry that something weird could happen there. For example, perhaps
> the page LSN on what is actually a newly recycled page could be set
> such that the backend following a stale right spuriously raises a
> "snapshot t
or problems are.
6. Based on your feedback on the batch memory patch (your commit
c27033ff), I made a stylistic change. I made similar comments about
the newly added quicksort/dumpbatch() MemoryContextReset() call, since
it has its own special considerations (a big change in the pattern of
all
inions, if any are to be had. Sorry that
I changed my mind, but it's a subtle issue, I'm sure you'll agree. I'm
not going to push on this, but I want to be sure that we're happy with
this.
To reiterate, I think it boils down to: Is it okay that this new
XLTW_InsertIndex case reports someone else's TID, while the only other
XLTW_InsertIndex case has always reported our own TID?
Discussing these sorts of "ontological" questions reminds me just how
painful UPSERT was as a project. :-)
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
could be a very low
probability race condition when checking the key space across sibling
pages, and will work to address that. If I'm right about that then
it's not a lot of work to fix; I'm probably just going to use the
right page's high key rather than its first data item.
--
On Tue, Mar 22, 2016 at 10:57 AM, Peter Geoghegan wrote:
> That's right - I have a small number of feedback items to work
> through. I also determined myself that there could be a very low
> probability race condition when checking the key space across sibling
> pages, and wil
Seems that parser not using precedence ideal order, and that casting
obligation losts performance.
The first problem is self-evident in this example:
SELECT '{"x":1}'::jsonb || (('{"A":{"y":2}}'::jsonb)->'A')
-- it is ok, expected result with (x,y)
SELECT '{"x":1}'::jsonb || '{"A":{"y":2}}'::js
t
think I see any here, nor any high memory tests where RS flops. Now, I
think you focused on regressions because that was what was
interesting, which is good. I just want to put that in context.
Thanks
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gresql.org/docs/9.5/static/functions-json.html>
(!), it was not easy to arrive here, and need only a little bit more
to reach perfection ;-)
2016-03-22 18:42 GMT-03:00 David G. Johnston :
> On Tue, Mar 22, 2016 at 1:52 PM, Peter Krauss wrote:
>
>> Seems that parser not using
ions (I had no
feedback on "partial-sort-basic-6.patch", which didn't use the new
upper planner pathification stuff, unlike this latest version).
> On Wed, Nov 4, 2015 at 4:44 AM, Peter Geoghegan wrote:
>>
>> Explain output
>> ---
>> I th
1 - 100 of 12751 matches
Mail list logo
