nvent 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 PostgreSQL Company
--
Sent via pgsql-hackers mailing l
ordered_rel->reltarget is 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.e
strong argument 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 make changes to yo
On Fri, Nov 10, 2017 at 2:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> 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
>&g
pdated case similar 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
broke a lot of long 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.
Thank
On Fri, Nov 10, 2017 at 4:34 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> 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 (pgsq
, if use
> of 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
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.patch
Description: Binary data
0002-forces
't get it to break the other 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 Comp
On Wed, Nov 1, 2017 at 6:16 AM, amul sul <sula...@gmail.com> 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
Descriptio
r 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 really having access, especially on
a system with a secu
be correct.
Let's see what Tom thinks.
--
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
ire/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
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-
min_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@postgr
On Sat, Oct 28, 2017 at 5:50 AM, Robert Haas <robertmh...@gmail.com> 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 sever
tents and would be
> 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 Ha
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 just dev-testing th
On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson <memissemer...@gmail.com> 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.
ally 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 remove speculative insertion locks from the dead
han the 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 Enter
the gather
> paths at this 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
about it.
Hmm. It seems 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)
y don't we want to generate it later 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
timate thing for somebody 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 subscr
o
one per table, say) 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 Pos
On Mon, Nov 6, 2017 at 11:22 PM, Masahiko Sawada <sawada.m...@gmail.com> 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@postg
ng 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 memory would be for storing data, but
really it's about whe
so if my answer
> 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
Enterpris
I 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
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 takes B
- 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.enterprisedb
ool 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
On Mon, Nov 6, 2017 at 11:20 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Nov 6, 2017 at 3:51 AM, Robert Haas <robertmh...@gmail.com> 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
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
EnterpriseDB: http:/
of failing. When it does,
> 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
Th
abase in an
intact state, 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
total_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 list
On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov
<a.korot...@postgrespro.ru> wrote:
> On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> > I can propose following alternative approach: teach read-only queries on
>> > hot
>> &g
about ~9% currently, largely due to the faster aggregate
> invocation. But the big benefit here would be all the deforming and the
> comparisons...
I'm not sure I follow you 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
t get reused and only
palloc for large tuples (cf. SLAB_SLOT_SIZE).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
skip-gather-project-v1.patch
Description: Binary data
shm-mq-less-spinlocks-v2.patch
Description: Binary data
shm-mq-reduce-receiver-latch-set-
at's about 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)
where we can avoid those errors and the cases where
we can't, and I don't see where #2 can go in the future other than #4.
--
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
=> target_value and then wrapping 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 Po
nt_setting().
No, it isn'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 possibil
On Thu, Nov 2, 2017 at 10:26 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Thu, Nov 2, 2017 at 9:44 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> The second commit (22576734b805fb0952f9be841ca8f643694ee868) is where
>> I think things get a lot more dangero
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 (pgsql-hackers@p
the same concurrency-safe
> 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, wh
kes 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
create problems, possibly including 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
e potential to 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 mailin
you'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 make changes to your
are immutable.
I am pretty sure this 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
if it were allowed, would 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.
+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 to me, but I'm not
an expe
ion time. 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
--
n truncation. Therefore, 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 E
hat makes this change utterly unacceptable 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 l
allel 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://
thought of better having both, but 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
--
they should
just do:
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
ited-size fetch forces serial 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 mail
t like we can't
> control what 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@po
ssion thread from
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 subscr
attached patch:
>
>Buffers: 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 mailin
n that I really
> wanted to 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-ha
t; I’ve seen the row with t_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.enter
crash. The patch also contains a 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
Enterpris
-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
dling 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
essfully.
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@postgre
know that, you 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 Enterprise Postgre
On Mon, Oct 30, 2017 at 7:04 PM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote:
> Robert Haas wrote:
>> On Tue, Oct 24, 2017 at 7:25 PM, Andres Freund <and...@anarazel.de> wrote:
>> > I think it does the contrary. The current mechanism is, in my opinion,
>&g
ould be to keep the secondary checkpoint 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
atter. I feel like 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
Ent
ame thing 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@postg
It should find a way to display the
results *as if* the initPlans were attached to the subnode, but
without actually moving them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
sent in
> Older Bugs section. 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
On Sat, Oct 28, 2017 at 8:02 PM, Amit Kapila <amit.kapil...@gmail.com> 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.
you should submit to the CommitFest regardless, 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://
2/)
Thanks. I picked the 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
On Sun, Oct 29, 2017 at 3:42 AM, Michael Paquier
<michael.paqu...@gmail.com> 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 P
e 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, relcache.c:954
It shouldn't be possible to reach an elog()
On Tue, Oct 17, 2017 at 3:48 AM, Seki, Eiji <seki.e...@jp.fujitsu.com> 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 pgsq
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql
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?
--
enclosed my patch. I tried 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
t; way to make the meaning clear.
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 <rjuju...@gmail.com> 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.
y it's guaranteed that 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.
ode. Do you want
to 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
g memory in a long-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.enterpr
his issue; unfortunately, I don'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
Other 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-
CT 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 make changes to your sub
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
ure. 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.com
The Enterprise PostgreSQL Company
pgwire-be-rmh.patch
Description: Binary data
pgwire-libpq-test.patch
Description: Binary data
--
Se
be argued that your
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: h
many letters in the alphabet, so 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 subscr
1 - 100 of 21603 matches
Mail list logo
