27;ve got
-- if you're going to invent new general-purpose primitives, they need
to go next to the existing functions that do similar things, not in
whatever part of the code you first decided you needed them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgre
s just a dummy
target list that produces nothing. Instead, I think we should pass
path->pathtarget, representing the idea that whatever Gather Merge
produces as output is the same as what you put into it.
See attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
ument that this is an improvement as it
stands, and we can adjust it later if it becomes clear what would be
better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Fri, Nov 10, 2017 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> I decided to try instead teaching the planner to keep track of the
>> types of PARAM_EXEC parameters as they were created, and that seems to
>> work fine. See 0001, attached.
>
> I did not look
imilar to what you've done elsewhere.
--
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
ong lines in your version of
the patch into multiple lines; please try to be attentive to this
issue when writing patches in general, as it is a bit tedious to go
through and insert line breaks in many places.
Please let me know your thoughts on the attached patches.
Thanks,
--
Ro
On Fri, Nov 10, 2017 at 4:34 AM, Etsuro Fujita
wrote:
> Here is a small patch for $Subject.
Good catch. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
server-side lo_import or lo_export is needed for some routine task,
> it's safer to use a role of this sort than full superuser privilege,
> as that helps to reduce the risk of damage from accidental errors.
+1. That seems like great language to me.
--
Robert Haas
Enterprise
ts in
ExecContextForcesOids imply that somebody it might, so perhaps it's
best to clean that up. Patch for this attached, too.
And here are the other patches again, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
0001-pass-eflags-to-worker-v1
way, I then tried this.
Instead of asking me what I did, can you tell me what I need to do?
Maybe a self-contained reproducible test case including exactly what
goes wrong on your end?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsq
On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote:
> Fixed in the 0003 patch.
I have committed this patch set with the attached adjustments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hash-adjustments.patch
Description: Binary data
--
Sent
s exactly the kind of thing that I'm talking about. Forcing an
administrator to hand out full superuser access instead of being able
to give just lo_import() makes life difficult for users for no good
reason. The existence of a theoretically-exploitable security
vulnerability is not tantamount to
a straight check on the number of base rels such that
> allow generating gather path in set_rel_pathlist, if there are
> multiple baserels involved. I have used all_baserels which I think
> will work better for this purpose.
Yes, that looks a lot more likely to be correct.
Let's s
contained therein, and decide who to fire/imprison/execute at
gunpoint). It shouldn't be our job to decide that granting a certain
right is NEVER 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
ll not prevent you from making a binary
setuid regardless of what the binary does. If you make a binary
setuid root that lets someone hack root, that's your fault, not the
operating system.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
in_parallel_table_scan_size = 0. That got it to use parallel query,
but I still don't see anything broken. Can you clarify further?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Sat, Oct 28, 2017 at 5:50 AM, Robert Haas wrote:
> No, because the Append node is *NOT* getting copied into shared
> memory. I have pushed a comment update to the existing functions; you
> can use the same comment for this patch.
I spent the last several days working on this patch,
gt; more likely to hit edge cases than if using pg_read_binary_file() or
> such (which obviously sees an out of date page)?
More the latter. It's not really an increase in terms of security
exposure, but it might lead to more trouble in practice.
--
Robert Haas
EnterpriseDB: http://www.e
_items() is, if I remember correctly, not necessarily going
to tolerate malformed input very well - I think that's why we restrict
all of these functions to superusers. So using it in this way would
seem to increase the risk of a server crash or other horrible
misbehavior. Of course if we're
On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson wrote:
> The code still chooses the custom plan instead of the generic plan for
> the prepared statements. I am working on it.
I don't think it's really the job of this patch to do anything about
that problem.
--
Robert Haas
En
catalogs. Any syscache lookup can theoretically take a lock,
even though most of the time it doesn't, and thus taking a lock that
has been removed from the deadlock detector (or, say, an lwlock) and
then performing a syscache lookup with it held is not OK. So I don't
think we can re
he generic routines.
I don't remember any more just how much faster qsort_tuple() and
qsort_ssup() are than plain qsort(), but it was significant enough to
convince me to commit 337b6f5ecf05b21b5e997986884d097d60e4e3d0...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpr
stage only if there are more than two rels involved and
> there isn't inheritance involved.
Why is that the correct rule?
Sorry if I'm being dense here. I would have thought we'd want to skip
it for the topmost scan/join rel regardless of the presence or absence
of inheritanc
s like slowing down single client performance by a couple
of percent is something that we really don't want to do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
ter when there isn't
inheritance involved?
--
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
to want. Maybe nobody does,
but I see no reason to worry if they do.
--
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.or
y) then why use the stats collector machinery for
this at all, vs. having a structure in shared memory that can be
updated directly? It seems like adding a lot of overhead for no
functional benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sen
On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada wrote:
> Attached the patch for $subject.
Committed.
--
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 y
kend-private memory, we clean up most everything else in
AbortTransaction() and then only destroy memory contexts in
CleanupTransaction(). This change doesn't go as far, but it's in the
same general direction, and I think rightly so. My error was in
thinking that the primary use of memo
swer
> appears inadequate, then can you provide more details on what you are
> concerned about?
I don't know why the question of why root->append_rel_list is empty is
the relevant thing here for deciding whether to generate gather paths
at this point.
--
Robert Haas
Enter
wonder why we currently postpone this until
such a late phase of planning.
--
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
ou can acquire a relation extension lock".
The latter rule, although more complex, is still deadlock-proof,
because the heavyweight locks still use the deadlock detector, and the
rest has a consistent order of lock acquisition that precludes one
backend taking A then B while another backend ta
1);
Maybe just cur_update_rri < update_rri + num_update_rri, or even
current_update_rri - update_rri < num_update_rri.
Also, +1 for Amit Langote's idea of trying to merge
mt_perleaf_childparent_maps with mt_persubplan_childparent_maps.
--
Robert Haas
EnterpriseDB: http://www.enterpr
and other
systems do today. I think the in-core use of this redirect
functionality is useful, but I think the real win would be optionally
using it in pgpool and pgbouncer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers m
On Mon, Nov 6, 2017 at 11:20 AM, Amit Kapila wrote:
> On Mon, Nov 6, 2017 at 3:51 AM, Robert Haas wrote:
>> This looks like it's on the right track to me. I hope Tom will look
>> into it, but if he doesn't I may try to get it committed myself.
>>
>> -
m later, but they've still got to lock the objects they
actually want to access. Group locking aims to prevent deadlocks
between cooperating processes; it is not a license to skip locking
altogether.
None of which is to say that the problems don't feel related somehow.
--
Robert Haas
En
t; happen in the first few seconds of the backup job. My backup scripts (not
> included here) are aware of that and retries the backup in case of failure.
I wonder why we don't do this already ... and by default.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Pos
but that seems hard to achieve in this case.
--
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
_path and related fields */
+set_cheapest(current_rel);
I wonder if it's really OK to call set_cheapest() a second time for
the same relation...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov
wrote:
> On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote:
>> > I can propose following alternative approach: teach read-only queries on
>> > hot
>> > standby to tolerate concurrent relation truncation. Therefor
or this precise plan wouldn't yet be that big because a
> good chunk of slot_getattr calls come from execTuplesMatch() which
> doesn't really provide enough context to do JITing (when used for
> hashaggs, there is more so it's JITed). Similarly gather merge's
>
cSetAlloc
time. I think that's largely caused by allocating space for heap
tuples and then freeing them and allocating space for new heap tuples.
Gather/Gather Merge are guilty of that, but I think there may be other
places in the executor with the same issue. Maybe we could have
fixed-size
out a 24% improvement.
Any reviews appreciated.
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
shm-mq-less-spinlocks-v1.2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
PG11
>
> 1. Do nothing, we reject MERGE
>
> 2. Implement MERGE for unique index situations only, attempting to
> avoid errors (Simon OP)
>
> 3. Implement MERGE, but without attempting to avoid concurrent ERRORs (Peter)
>
> 4. Implement MERGE, while attempting to avoid concurre
g the ORDER BY query
in a subselect to cut off fetching values at the correct point. But
no operator class for any access method can directly handle that query
efficiently as you've written it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sen
#x27;t. Right now, SET always refers to a GUC, never a
variable, so there's no possibility of getting confused about whether
it's intending to change a GUC or an eponymous variable. Once you
make SET able to change either one of two different kinds of objects,
then that possibility does exis
On Thu, Nov 2, 2017 at 10:26 PM, Peter Geoghegan wrote:
> On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas wrote:
>> The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where
>> I think things get a lot more dangerous. The problem (as Andres
>> pointed out to me th
if no single unique index can be identified." I don't
think anybody's putting words into your mouth here. We're just
reading what you wrote.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgs
t; semantics?
>
> I don't know if this would be helpful TBH, or if it would negate
> Simon's compatibility goals. Just another idea.
Yes, that fixes the problem. Of course, it also turns MERGE
CONCURRENTLY into syntactic sugar for INSERT ON CONFLICT UPDATE, which
br
easily, but haste makes bugs, and (I know you're all tired
of hearing me say this) patches that implicate the on-disk format are
scary.
--
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
ing security problems. For example,
maybe a security-definer function could leave behind variables to
trick the calling code into failing to set GUCs that it intended to
set. Or maybe creating a variable at the wrong time will just break
things randomly.
--
Robert Haas
Enterp
create new problems
that didn't exist before those commits. And if we release without
reverting those commits then we can't change our mind later.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pg
u're just going to
have to cast it to non-const. Then it wasn't really very const in the
first place...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
is is by no means the only piece of code which assumes that.
--
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
have to take
AccessExclusiveLock on the child.
--
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
WalSndShutdown();
+
+if (!pq_is_send_pending())
+return;
+}
I think it's only the if (!pq_is_send_pending()) return; that needs to
be conditional here, isn't it? The pq_flush_if_writable() can be done
unconditionally.
Other than that this looks like a reasonable change
ime. The partition bounds can be changed for
individual partitions but that would require a lock on the partition.
Can you give an example of the kind of scenario about which you are concerned?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
efore, when
> non-existent heap page is accessed on hot standby, we can know that it was
> deleted by concurrent truncation and should be assumed to be empty. Any
> thoughts?
Sounds like it might break MVCC?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgre
able or anything
-- but I wonder how much application code it will break, and whether
any steps need to be taken to reduce breakage.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
query, but then materializing it isn't that bad
because the result set is a lot smaller than the original table.
I am not disputing the idea that there are *some* cases where parallel
query is useful and materialization is still undesirable, of course.
--
Robert Haas
EnterpriseDB: http://w
no so
> sure. Should we remove that part altogether, or add both in a single
> statement with updated comments?
I was only suggesting that you update the comments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing l
CREATE TEMP TABLE x AS SELECT * FROM t2 WHERE ...;
DECLARE x CURSOR FOR SELECT * FROM x;
Since e9baa5e9fa147e00a2466ab2c40eb99c8a700824, that ought to work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-
rial execution
currently. If it's true that nothing else can happen in the middle
then we could relax that, but I don't see why that should be true?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsq
t rows get inserted on the foreign server when they violate
> local constraints.
I think that's a fair point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
the new one. Otherwise people may have trouble understanding the
history.
--
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/mai
uffers: shared hit=547 read=16121, temp read=5502 written=5502
Committed. Arguably we ought to back-patch this, but it's minor so I didn't.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacker
skip.
Well, I think there are outstanding concerns that the patch in
question is not safe, and I don't see that anything has been done to
resolve them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing li
max = 3268957 page_inspect, I might use it to
> extract row from the page, but this will not be quite easy.
Not sure if this would work, but maybe try BEGIN ... UPDATE the row,
perhaps via TID qual ... ROLLBACK?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
testcase to test dropped
> columns in partitioned table.
>
> Sorry for not noticing this problem earlier.
OK, committed. This is a good example of how having good code
coverage doesn't necessarily mean you've found all the bugs. :-)
--
Robert Haas
EnterpriseDB: http://www.ente
rict-overflow=some-higher-level, and
> with ubsan. I'm fairly certain there's more bogus overflow checks
> around...
Makes sense.
--
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
andling for each partitioning column. Do you want me
> to handle opclass using RelabelType node? I am afraid that, that would make
> the \d+ output more horrible than the current one if non-default opclass used.
Maybe we should just pass the OID of the partition (or both the
partition and
successfully.
I suggest that if we think we don't need -fwrapv any more, we ought to
remove it. Otherwise, we won't find out if we're wrong.
--
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
ou could just run
pg_waldump to find it. That probably wasn't true when this code was
originally written, but it is today.
I was mostly just thinking out loud, listing another option rather
than advocating for it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpris
On Mon, Oct 30, 2017 at 7:04 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Tue, Oct 24, 2017 at 7:25 PM, Andres Freund wrote:
>> > I think it does the contrary. The current mechanism is, in my opinion,
>> > downright dangerous:
>> > https://www.postgres
heckpoint around
but never try to replay from that point, or only if a specific flag is
provided.
--
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
e that's something that's likely to come back
to bite us.
Giving LockAcquireExtended() an argument that causes some
AccessExclusiveLocks not all to be logged also seems pretty ugly,
especially because there are no comments whatsoever explaining the
rationale.
--
Robert Haas
EnterpriseDB: htt
hing in core? I kinda think
Peter might have the right idea here. Under his proposal, we'd be
getting something that is, in a way, new.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Mon, Oct 30, 2017 at 9:00 AM, Amit Kapila wrote:
> Now that the PARAM_EXTERN issue is fixed, I have rebased this patch.
> This patch had been switched to Ready For Committer in last CF, then
> Robert had comments which I have addressed, so I think the status
> should be switched b
n. Shall we leave it as it is or do we want to do
> something else with it?
>
> [1] - https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items
How about just adding an additional bullet point for that item that
says "fixed by commit blah blah for 10.1"?
--
Robert Haas
Enterprise
On Sat, Oct 28, 2017 at 8:02 PM, Amit Kapila wrote:
> I think we need to make changes in exec_simple_recheck_plan to make
> the behavior similar to HEAD. With the attached patch, all tests
> passed with force_parallel_mode.
Committed to REL_10_STABLE.
--
Robert Haas
Enterpris
gardless, to increase
your chances of getting feedback.
--
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
he second variant, committed, and also back-patched to 9.6.
--
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 Sun, Oct 29, 2017 at 3:42 AM, Michael Paquier
wrote:
> Okay. Here is an updated patch incorporating those comments.
Committed with a little wordsmithing on the documentation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pg
new hash
value into a uint64 value. That seems likely to be slightly faster
and I don't see any real downside.
rhaas=# create table natch (a citext, b text) partition by hash (a);
ERROR: XX000: missing support function 2(16398,16398) in opfamily 16437
LOCATION: RelationBuildPartitionKey,
On Tue, Oct 17, 2017 at 3:48 AM, Seki, Eiji wrote:
> I found a typo in comment of blvacuum.c, so attach the patch for it.
Thanks. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hack
* getting copied into shared
memory. I have pushed a comment update to the existing functions; you
can use the same comment for this patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
ting, if any, can we think about doing with this plan to make
sure it doesn't regress things? For example, if we do a TPC-H run
with partitioned tables and partition-wise join enabled, will any
plans change with this patch? Do they get faster or not? Anyone have
other ideas for what to test?
my best to follow instructions on
> how to submit a patch.
I'd say you did a good job. Committed.
--
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 yo
ar.
I think you are right. I have committed the patch.
--
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 Sat, Oct 28, 2017 at 10:03 AM, Julien Rouhaud wrote:
> I just noticed that get_default_partition_oid() tries to release the
> tuple even if it isn't valid.
> Trivial patch attached.
Oops. I wonder how that managed to survive testing.
Committed.
--
Robert Haas
Ente
hat the subsequent reads can see the
> committed result of previous writes even if the previous transactions
> were distributed transactions.
Right, this is very important, and having the backend wait for the
resolver(s) is, I think, the right way to implement it.
--
Robert Haas
Enterp
o have a crack at it or should we just leave this as a master-only
fix?
--
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
-lived context. I think the same
technique is used elsewhere for similar reasons. I admit I haven't
checked whether there would actually be a leak here if we did it as
you propose, but I wouldn't find it at all surprising.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterp
n't recall the
details off-hand.
--
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
her problems with taking ShareRowExclusiveLock include (1) probable
lock upgrade hazards and (2) do you really want MERGE to kick
autovacuum off of your giant table? Probably not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
UPDATE;
if less useful cases are vulnerable to some weirdness, maybe it's OK
to just document the problems.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
y again later; in the meantime, they'd
be on the new version.
--
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
or a long time to come, and
although an automated reconnect is a little annoying, it's a lot less
annoying than an outright connection failure. So that part of your
patch should probably be resubmitted when and if we bump the version
to 3.1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
transaction is only read-only because you had no other choice, but
nonetheless that's how it is marked. I have a feeling that if we
extend the definition of "read only" to mean "sometimes allow writes",
we may regret it.
--
Robert Haas
EnterpriseDB: http://www.enterpri
o let's not
use them up for developer-convenience 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://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 22926 matches
Mail list logo
