itation
of PostgreSQL vs. encrypted filesystems vs. SSH; it's just a
quality-of-implementation issue.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be done before heap_open on the table being attached. If we are not
> going to attach the partition, there's no point in instantiating its relcache.
No, because we should take the lock before examining any properties of
the table.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The E
ile to
have the feature because it works better and is easier to use when
it's built in. I don't think that a patch for this feature is likely
to be bigger than (or even as large as) the patches for logical
replication or parallel query, and it will probably be less work to
maintain g
quot;) which I think is a ridiculous
statement. We have to have some kind of simple key management in
order to have the feature at all. It does not have to be crazy
complicated, but it has to exist.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
at happens, parallel_terminate_count is getting bumped
twice for some reason.
3. So then the leader process fails that assertion when it tries to
launch the parallel workers for the next query.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Jun 15, 2017 at 10:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Jun 15, 2017 at 10:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> It's fairly hard to read this other than as telling us that the wor
On Thu, Jun 15, 2017 at 10:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Jun 15, 2017 at 10:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> But we know, from the subsequent failed assertion, that the l
On Wed, Jun 14, 2017 at 6:28 PM, Justin Pryzby <pry...@telsasoft.com> wrote:
> On Tue, Jun 13, 2017 at 12:16:00PM -0400, Robert Haas wrote:
>> It might be worth adding platform-specific code for common platforms.
>
> All I care (which linux happily/happens to support) is m
dea. Please add to the next CommitFest and review
somebody else's patch in exchange for having your own patch reviewed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
robably
does not happen on any other platform. Of course it also makes my
theory that the child doesn't reach dsm_attach() before the parent
finishes the query pretty unlikely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
ut the select_parallel test quite deliberately
disarms all of the guards that would tend to discourage such plans.
Of course, as Amit also points out, it could also be the result of
some bug, but I'm not sure we have any reason to think so.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
s might be loosened in a future release.
>
> This is plain wrong.
It used to be true. Tom changed it in commit
05d8a561ff85db1545f5768fe8d8dc9d99ad2ef7, back in 2010.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailin
On Tue, Jun 13, 2017 at 4:56 PM, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> On Wed, Jun 14, 2017 at 4:22 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> I'm just trying to understand your comments so that I can have an
>> intelligent opinion about what we
groundWorker is lacking a memory barrier
> between incrementing parallel_terminate_count and marking the slot free.
> Maybe it doesn't need one, but since there is one in
> BackgroundWorkerStateChange, it looks weird to not have it here.
I noticed that the other day and thought about mentioning it, but
didn't quite
fault_part_validation_constraint(List *new_part_constaints);
#endif /* PARTITION_H */
There should be a blank line after the last prototype and before the #endif.
+-- default partition table when it is being used in cahced plan.
Typo.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
On Wed, Jun 14, 2017 at 6:15 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> PFA patch set addressing comments by Tom and Amit.
LGTM. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mai
d by printing chars like strings
>> with the full escaping mechanism. See attached patch.
>
> +1. I've been meaning to report about
> zero-byte-truncating-the-whole-output-string thing for some time now.
I've been bitten by this, too.
--
Robert Haas
EnterpriseDB: http://www.ent
On Tue, Jun 13, 2017 at 5:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> OK, I think I see the problem here. predicate_implied_by() and
>> predicate_refuted_by() differ in what they assume about the predicate
>> eva
his code will be gone entirely, so this will
be moot. If we decide to repair the existing broken logic rather than
ripping it out entirely then this is probably a good idea, but I hope
that's not what happens.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Co
find the problems. It
checks things like extconfig and pg_depend links, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Tue, Jun 13, 2017 at 10:24 AM, Robert Haas <robertmh...@gmail.com> wrote:
> I think that's going to come as an unpleasant surprise to more than
> one user. I'm not sure exactly how we need to restructure things here
> so that this works properly, and maybe modifying
> pr
ight want to make
me correct in the future - i.e. removing aborted tuples ASAP seems
like a good idea.
Another point to consider is whether a relfilenode assignment visible
to that snapshot might be a file that's since been truncated or
removed altogether.
--
Robert Haas
EnterpriseDB: http://ww
On Mon, Jun 12, 2017 at 9:03 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Mon, Jun 12, 2017 at 3:50 PM, amul sul <sula...@gmail.com> wrote:
>> On Wed, May 17, 2017 at 10:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> [...]
>>> I
console or
request the key from an HSM or get it in any other way, they just have
to write the appropriate shell script. We just provide mechanism, not
policy, and the user can adopt any policy they like, from an extremely
insecure policy to one suitable for Fort Knox.
--
Robert Haas
On Tue, Jun 13, 2017 at 12:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Jun 13, 2017 at 11:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> But it needs to be changeable, unless you like the proposition
like
it would be a good idea to install code specific to Linux that
displays all and only those values that are meaningful on Linux, and
(less importantly) similarly for macOS. Linux is such a common
platform that reporting bogus zero values and omitting other fields
that are actually m
me of them will
> surely not be okay with an immutable estimate for the store's size.
Hmm, true. But even if we extracted enrtuples from the
RangeTbleEntry, there wouldn't be any mechanism to actually trigger
such a replan, would there?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enter
sure, it keeps those things in sync, but it also makes the code harder
to read. On balance I think it's a negative.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Tue, Jun 13, 2017 at 10:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Perhaps this is a silly question, but I don't particularly see what's
>> wrong with:
>
>> 3. Do nothing.
>
> Well, the fundamenta
otent and doesn't depend on the existing page
contents, we might not need it currently, but with encryption, every
bit in the page depends on every other bit in the page, so we
certainly would. I don't know how many places we've got assumptions
like this baked into the system, but I'm guessing there are a
k that if we did it that way, it would be significantly
harder to debug. Right now, if something goes boom, you can look at
the old and new clusters and figure out what doesn't match, but if
pg_upgrade renumbered everything, you would no longer be able to do
that, or at least not easily.
--
Ro
g constraint into a CHECK constraint and that
doesn't work. That's not cool.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ed tuplestores,
the existing code produces correct estimates. If we chose option #1,
that would still be true, but we'd have to change a bunch of code to
get there. If we chose option #2, it would cease to be true. Why not
just leave it alone?
--
Robert Haas
EnterpriseDB: http://www.enterpris
TOAST tables once we have a
complete list of the relfilenodes that are actually used.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
I have a new MacBook Pro running Sierra. I managed to get PostgreSQL
to build after install Xcode, installing MacPorts, installing the
documentation toolchain via some incantation that was apparently
wrong, and then uninstalling and reinstalling the documentation
toolchain per
ne of the
>> better reasons is the desire for HSM based encryption in a storage
>> area network based setup.
>
> Could you explain this in more detail?
I don't think Ants ever responded to this point.
I'm curious whether this is something that is likely to be pursued for
Postg
re.
Commit 4b4b680c3d6d8485155d4d4bf0a92d3a874b7a65 (Make backend local
tracking of buffer pins memory efficient., vintage 2014) seems like a
likely culprit here, but I haven't tested.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
rk. This might be more future-proof, too,
if somebody someday adds support for REFERENCING { OLD | NEW } ROW to
constraint triggers and fails to realize that there's not a check
anywhere outside the parser for the table case.
I don't see anything else wrong with this, and it seems like it solves
the re
On Fri, Jun 9, 2017 at 1:45 PM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 6/9/17 12:17, Robert Haas wrote:
>> IOW, suppose there
>> were a collation API call distill() which had the property that
>> strcmp(distill(X), distill(Y)) == 0 iff X and Y ar
On Fri, Jun 9, 2017 at 12:19 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 11:56 PM, Thomas Munro
> <thomas.mu...@enterprisedb.com> wrote:
>> [Adding Andrew Gierth]
>>
>> Here is a rebased version of the patch to fix transition table
On Fri, Jun 9, 2017 at 12:18 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Fri, Jun 9, 2017 at 9:17 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> I'm not exactly sure what is possible or
>> desirable, but I would not be too surprised to hear complaints about
>>
oblems with transition tables.
So, Andrew, are you running with this, or should I keep looking into it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
the observed behavior different from the "pure" ICU behavior because
of the tiebreak, and at least some users might even find it worth
giving up hashing in order to get the exact sort order they need.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
that, so that users can select an ICU collator and get exactly the
behavior ICU delivers, without the extra tiebreak?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
issue. And hostaddr is
> much more closely tied to specifying the target to connect to, like host and
> port are.
Yeah, I'm not objecting to your changes, just telling you what my
chain of reasoning was.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
rigger could block or alter the modifications.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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, Jun 8, 2017 at 5:01 PM, Andrew Gierth
<and...@tao11.riddles.org.uk> wrote:
>>>>>> "Robert" == Robert Haas <robertmh...@gmail.com> writes:
> Robert> unless some other committer volunteers. (Of course, anyone
> Robert> could step in
in the tree will require work, and I'm
busy. But there don't seem to be any other options.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Thu, Jun 8, 2017 at 1:17 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> 2017-06-08 17:19 GMT+02:00 Robert Haas <robertmh...@gmail.com>:
>> On Wed, Jun 7, 2017 at 12:30 PM, Pavel Stehule <pavel.steh...@gmail.com>
>> wrote:
>> > I got strange erro
On Thu, Jun 8, 2017 at 2:05 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Thu, Jun 8, 2017 at 10:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> More generally, I don't think there's ever a
>> time when it's OK to commit a patch that you're not willing to
On Thu, Jun 8, 2017 at 1:48 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 06/08/2017 08:36 PM, Robert Haas wrote:
>>
>> I freely admit I encouraged you to commit this. I did not imagine
>> that would be followed immediately by abdicating all responsibility
>
a patch,
it'll either not get committed, or it'll be the responsibility of
whoever does.
I freely admit I encouraged you to commit this. I did not imagine
that would be followed immediately by abdicating all responsibility
for it. My mistake, I guess.
--
Robert Haas
EnterpriseDB: http://www.e
On Thu, Jun 8, 2017 at 7:01 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Jun 8, 2017 at 1:33 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Wed, Jun 7, 2017 at 5:46 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> As far as I understa
On Wed, Jun 7, 2017 at 5:47 AM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Sat, Jun 3, 2017 at 2:11 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>
>> + errmsg("default partition contains row(s)
>> that woul
r as one
operation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
cannot to check master
> and used some defaults.
I don't understand this problem report.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Jun 8, 2017 at 10:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> It doesn't seem like a problem to me if somebody else wants to extend
>> it to hostaddr, though. Whether that change belongs in v10 or v11 is
&g
I
don't mind someone else doing the work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
them to use
some other method to conclude that the row is deleted. What method
would we use?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Wed, Jun 7, 2017 at 11:20 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Sat, Jun 3, 2017 at 1:03 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 3:48 AM, Rafia Sabih
>> <rafia.sa...@enterprisedb.com> wrote:
>> I don't
threads, so my theory is that this patch was never really related to
the problem, but rather than by the time Erik got around to testing
this patch, other fixes had made the problems relatively rare, and the
apparently-improved results with this patch were just chance. If that
theory is wrong, it wou
On Fri, Jun 2, 2017 at 9:15 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Fri, Jun 2, 2017 at 6:38 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 9:01 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> Your reasoning sounds se
ory is right, you ought to see
that SerializableXactHashLock occurs as a wait event very frequently.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
tring_agg(), they will.
It's not clear how much work we'll really save by parallelizing that
sort of thing. Maybe it will be great?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
nch rw
> performance. Does not do so well with hammerdb (about the same as base) on
> single socket and two socket.
Any idea why? I think we will have to understand *why* certain things
help in some situations and not others, not just *that* they do, in
order to come up with a good solution to t
the problem that we are trying to solve with this change? Is
there a practical use case for setting autovacuum_freeze_max_age >
20, or is this just so that when autovacuum fails to vacuum
things in time, we can bloat clog instead of performing an emergency
shutdown?
--
Robert Haas
EnterpriseDB:
nsert(), nor
> is there need to make ExecPartitionCheck() public. That's how the patch
> attached with the previous email does it anyway.
Cool. I think this is a sensible approach, and have committed the patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postg
code could be removed entirely in light of commit
3ec76ff1f2cf52e9b900349957b42d28128b7bc7.
Amit?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I
don't personally think it's worth spending a lot of time trying to
tweak the costing model. Of course, if somebody wants to take a run
at it and can show that the benefit is there, cool beans.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
find it pretty hilarious to see the
EVANESCENT in kwlist.h, I think it's probably a good idea to avoid
choosing keywords that will cause even proficient speakers of English
to need a dictionary.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
ot;background worker", but like others,
I didn't like splitting up the name field into two parts. I think you
could do the former without doing the latter.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-h
On Tue, Jun 6, 2017 at 6:29 AM, Rafia Sabih
<rafia.sa...@enterprisedb.com> wrote:
> On Mon, Jun 5, 2017 at 8:06 PM, Robert Haas <robertmh...@gmail.com> wrote:
>> Many of these seem worse, like these ones:
>>
>> - * Quit if we've reached rec
b1c-4561-0158176f65f1%40dunslane.net
> [2] - https://www.postgresql.org/message-id/25861.1472215822%40sss.pgh.pa.us
Oh, good point. So this is a longstanding bug that has possibly just
gotten easier to hit.
I still think figuring out what's going on with the
ParallelWorkerNumbers is a good plan.
--
reasons), then I think you should say so
straight out. People shouldn't have to guess whether you're going to
maintain your patch or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
based on how often you
think you'll need to establish a new connection (but it's probably not
worth bothering with).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
ugh
messages to drown out the stuff they actually want to see at that
level. I wouldn't object to DEBUG3 though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
t;" which, while
maybe not as elegant as providing some way to override the
backend_type field, would be almost no work and substantially better
for v10 than what we've got now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
lism as well (bgworker.c, pqmq.c,
parallel.c, condition_variable.c). Maybe we (you?) should just go and
change them all. I don't think using MyLatch instead of
MyProc->procLatch has become automatic for everyone yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgr
gorithm. And
> Proc is queued to wait list then.
> 3. Otherwise spin_delay is performed, and loop returns to step 1.
Interesting work. Thanks for posting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
ts. I think it's in everyone's interest to get this feature
stabilized before we ship a final release - people will rely on it,
and if it drops even one row even occasionally, it's going to be a big
problem for our users.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpris
y(), but previously it always returned after
calling do_start_bgworker, and now it doesn't. So if
do_start_bgworker() did something that could modify the list
structure, then perhaps maybe_start_bgworkers() would get confused. I
don't really think that this theory has any legs, though.
-
is safely dead, but s390 and
pa-risc are ostensibly not dead.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ack-root-line-pointer-v23_v26
> in the below e-mail:
> https://www.postgresql.org/message-id/CABOikdOTstHK2y0rDk%2BY3Wx9HRe%2BbZtj3zuYGU%3DVngneiHo5KQ%40mail.gmail.com
OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
trigger on
> the new partition, which might in turn cause it to fail the new
> partition constraint. But in that case, it will not cause another row
> movement, because in the new partition, it's an INSERT, not an UPDATE,
> so the operation would end there, aborted.
Yeah, that's what I wa
= errno;
/* stuff */
errno = save_errno;
If that's not a signal handler changing an int, color me confused.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscript
On Tue, Jun 6, 2017 at 1:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Jun 6, 2017 at 12:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> By definition, the address range we're trying to reuse worked succes
On Tue, Jun 6, 2017 at 11:37 AM, Kevin Hale Boyes <kcbo...@gmail.com> wrote:
> On 6 June 2017 at 09:19, Robert Haas <robertmh...@gmail.com> wrote:
>> Thanks. Committed.
>
> The changes to catalogs.sgml has introduced a double "the" in this part of
gh a CPU instruction, so if we can rely
on a 4 byte store being indivisible from the perspective of some other
CPU, it seems fine to also rely on that being true in the signal
handler case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via p
tmaster startup
> failure.
If the postmaster picked an address where other things are unlikely to
get loaded, then that would increase the chances of child processes
finding it available, wouldn't it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t be going in the wrong direction entirely, but
it's the first thing that comes to mind for me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pens to get claimed by something. I don't
think we can say that there is any address where that definitely won't
happen. So I would say let's do this retry thing first, and then if
that proves inadequate, we can also try moving the mappings to a range
where conflicts are less likely.
On Tue, Jun 6, 2017 at 11:37 AM, Kevin Hale Boyes <kcbo...@gmail.com> wrote:
> On 6 June 2017 at 09:19, Robert Haas <robertmh...@gmail.com> wrote:
>> Thanks. Committed.
>
> The changes to catalogs.sgml has introduced a double "the" in this part of
On Mon, Jun 5, 2017 at 1:02 AM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/06/03 1:56, Robert Haas wrote:
>> On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote
>> <langote_amit...@lab.ntt.co.jp> wrote:
>>> Attached patch makes Ini
1.2
or TLS 1.1 or TLS 1.0.
It could well be that there's something I don't understand here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
That seems better, but looking at rewriteTargetListUD, it seems that
the actual rule is that this happens when there is a row-level on
either UPDATE or DELETE. If there is only a row-level trigger on
INSERT, then it is not done. Perhaps we should try to include that
detail in the comment as well.
-
On Tue, Jun 6, 2017 at 12:24 AM, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> It should return NIL when no entry is found in the cache, not NULL.
>
> Attached patch fixes that.
I'm not sure how much value neatnik-ism has in cases like this, but committed.
--
Robert Ha
uples
> StorePartitionKey
> index_create
> GenerateTypeDependencies
> add_column_collation_dependency
We could go change them all, but I guess I don't particularly see the point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hat your thinking is being
excessively shaped by the example presently in front of us.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rdware from reordering
> accesses, but I don't think it stops the compiler from doing so.
If it doesn't prevent both the hardware and the compiler from
reordering, it's broken. See the comments for pg_read_barrier() in
atomics.h.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
nguish between a value that occurs 1
time and a value that occurs 999,999 times -- they are both non-MCVs.
As you shrink the table that sort of thing becomes a smaller and
smaller problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pg
901 - 1000 of 21603 matches
Mail list logo
