On Thu, Oct 27, 2016 at 11:15 PM, Robert Haas wrote:
> Thanks. Here's a new version with a fix for that issue and also a fix
> for PQconnectionNeedsPassword(), which was busted in v1.
I did some more testing of the patch for both URI and (host, port)
parameter pairs. I did test for ipv4, ipv6, UD
Here is a patch series that implements several changes in the internal
grammar and node representation of function signatures. They are not
necessarily meant to be applied separately, but they explain the
progression of the changes nicely, so I left them like that for review.
The end goal is to m
Alvaro Herrera wrote:
> I propose we introduce the concept of "indirect indexes".
This is a WIP non-functional patch for indirect indexes. I've been
distracted from working on it for some time already and will be off-line
for half this month yet, but since this was discussed and seems to be
consi
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi
> I didn't find any relevant thread about the discussion of Bulk insert support
> in ECPG using arrays. Oracle supports the same and details are available
> in [1].
>
>
> I see some
On Thu, Aug 18, 2016 at 1:55 PM, Thomas Munro
wrote:
> On Tue, Aug 16, 2016 at 1:55 AM, Robert Haas wrote:
>> If we're going to remove barrier.h, I think that should be a separate
>> commit from creating a new barrier.h.
>
> OK. Here's a patch to remove the old header, and the v2 barrier patch
>
New patch.
On 9/9/16 11:45 PM, Vitaly Burovoy wrote:
> 1. The standard requires "... ALTER COLUMN ... SET GENERATED { ALWAYS
> | BY DEFAULT }" (9075-2:2011 subcl 11.20), but the patch implements it
> as "... ALTER COLUMN ... ADD GENERATED { ALWAYS | BY DEFAULT } AS
> IDENTITY"
Has both now. They
Hi All,
I didn't find any relevant thread about the discussion of Bulk insert
support in ECPG using arrays. Oracle supports the same and details
are available in [1].
I see some performance benefits in supporting the same in ECPG also.
Does any one worked on this area before? Are there any prob
Here is a patch for the background sessions C API and PL/Python support.
This was previously submitted as "autonomous transactions", which
proved controversial, and there have been several suggestions for a new
name.
I have renamed everything, removed all the incomplete PL/pgSQL stuff,
did some r
On Tue, Nov 1, 2016 at 4:15 PM, Peter Eisentraut
wrote:
> On 10/31/16 9:39 PM, Michael Paquier wrote:
>> We are on the 1st, at least in my timezone. So the CF should start
>> really soon, meaning that no new patches would get in. In a couple of
>> hours that would be fine? I recall that the last t
On 10/31/16 9:39 PM, Michael Paquier wrote:
> We are on the 1st, at least in my timezone. So the CF should start
> really soon, meaning that no new patches would get in. In a couple of
> hours that would be fine? I recall that the last times we tried to
> sync with the US East coast time.
https://
Hi,
At Sun, 2 Oct 2016 21:43:46 +0900, Michael Paquier
wrote in
> On Thu, Sep 29, 2016 at 10:02 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello,
> >
> > At Thu, 29 Sep 2016 16:59:55 +0900, Michael Paquier
> > wrote in
> >
> >> On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI
> >> wrote:
> >> >
On Tue, Nov 1, 2016 at 10:27 AM, Haribabu Kommi
wrote:
> On Mon, Oct 31, 2016 at 4:31 PM, Michael Paquier
> wrote:
>>
>> On Mon, Oct 31, 2016 at 1:49 PM, Peter Eisentraut
>> wrote:
>> > Commit fest CF 2016-11 is supposed to start in about a day. I don't
>> > think a commit fest manager was chos
On Mon, Oct 31, 2016 at 4:31 PM, Michael Paquier
wrote:
> On Mon, Oct 31, 2016 at 1:49 PM, Peter Eisentraut
> wrote:
> > Commit fest CF 2016-11 is supposed to start in about a day. I don't
> > think a commit fest manager was chosen yet. Volunteers?
>
> I'd like to pass my turn on this one as C
>>> When sending a big message, WalSndWriteData() notices that it's
>>> approaching timeout and tries to send a keepalive request, but the
>>> request just gets buffered behind the remaining output plugin data and
>>> isn't seen by the client until the client has received the rest of the
>>> pendin
>
>
> ^
>
> The reason for the error is that transformOnConflictArbiter applies
> RelationIsUsedAsCatalogTable() to something that it doesn't know to
> be a plain relation --- it's a view in this case. And that macro
> blindly assumes th
Hi hackers,
In PostgreSQL 9.6, hash joins can be parallelised under certain
conditions, but a copy of the hash table is built in every
participating backend. That means that memory and CPU time are
wasted. In many cases, that's OK: if the hash table contents are
small and cheap to compute, then
On Mon, Oct 31, 2016 at 9:31 PM, Robert Haas wrote:
> On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier
>> - Instead of palloc'ing the old and new pages to compare, it would be
>> more performant to keep around two static buffers worth of BLCKSZ and
>> just use that. This way there is no need as we
At 2016-09-28 13:13:56 -0400, robertmh...@gmail.com wrote:
>
> I hope that the fact that there's been no discussion for the last
> three weeks doesn't mean this effort is dead; I would like very
> much to see it move forward.
Here's an updated patch. Sorry, I got busy elswhere.
I struggled with t
Hi,
While debugging something on 9.6, I've noticed that auto_explain handles
parallel queries in a slightly strange way - both the leader and all the
workers log their chunk of the query (i.e. the leader logs explain for
the whole query, while workers only log the parts they've been executing)
Hello,
I have applied this patch on latest HEAD and have done basic testing which
works fine.
Some comments,
>if (current->assign_hook)
>- (*current->assign_hook) (current->value);
>- return true;
>+ {
>+ confirmed = (*current->assign_h
On Mon, Oct 31, 2016 at 9:31 PM, Robert Haas wrote:
> On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier
> wrote:
>> And here we go. Here is a review as well as a large brush-up for this
>> patch. A couple of things:
>> - wal_consistency is using a list of RMGRs, at the cost of being
>> PGC_POSTMAS
On 10/31/2016 02:24 PM, Tomas Vondra wrote:
On 10/31/2016 05:01 AM, Jim Nasby wrote:
On 10/30/16 1:32 PM, Tomas Vondra wrote:
Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's
some sort of CPU / OS scheduling artifact. For example, the system has
36 physical cores, 72 vi
On 10/31/2016 08:43 PM, Amit Kapila wrote:
On Mon, Oct 31, 2016 at 7:58 PM, Tomas Vondra
wrote:
On 10/31/2016 02:51 PM, Amit Kapila wrote:
And moreover, this setup (single device for the whole cluster) is very
common, we can't just neglect it.
But my main point here really is that the trade-of
On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby
wrote:
> BTW, I've sometimes wished for a mode where queries would silently have
> result ordering intentionally futzed, to eliminate any possibility of
> dependence on tuple ordering (as well as having sequences start at some
> random value). I guess w
Attached is a patch that implements copy_srf().
The function signature reflects cstate more than it reflects the COPY
options (filename+is_program instead of FILENAME or PROGRAM, etc)
CREATE OR REPLACE FUNCTION copy_srf(
filenametext DEFAULT null,
is_program boolean DEFAULT false,
This patch increases test coverage for pltcl, from 70% to 83%. Aside
from that, the work on this uncovered 2 new bugs (the trigger return one
I just submitted, as well as a bug in the SRF/composite patch).
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data
On Mon, Oct 31, 2016 at 7:58 PM, Tomas Vondra
wrote:
> On 10/31/2016 02:51 PM, Amit Kapila wrote:
> And moreover, this setup (single device for the whole cluster) is very
> common, we can't just neglect it.
>
> But my main point here really is that the trade-off in those cases may not
> be really
While reviewing code coverage in pltcl, I uncovered a bug in trigger
function return handling. If you returned the munged name of a dropped
column, that would silently be ignored. It would be unusual to hit this,
since dropped columns end up with names like
"...pg.dropped.2...", but sin
On Mon, Oct 31, 2016 at 11:57 AM, Tom Lane wrote:
> Now that I've seen this I wonder which other uses of rd_options are
> potentially broken. RelationIsUsedAsCatalogTable() is hardly the
> only macro that is assuming with little justification that it's
> applied to the right kind of reloptions.
I looked into bug#14397. The submitter was discourteous enough not to
provide an in-line example, but here it is:
CREATE TABLE IF NOT EXISTS TEST_1 (
ID SERIAL PRIMARY KEY,
C1 BYTEA,
C2 TEXT NOT NULL,
C3 BOOLEAN NOT NULL DEFAULT FALSE,
CONSTRAINT TEST_1_unique_idx UNIQUE(C
amul sul writes:
> Thanks for your explanation, I agree that this is not a single scenario
> where we need special care, but still my question stands there, why do we
> really need to dump built-in extension?
It's not built-in. It's installed by default, yes, but it's also
droppable.
On 31 Oct 2016 6:48 pm, "Tom Lane" wrote:
>
> amul sul writes:
> > On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas
wrote:
> >> There's a comment in dumpExtension() that explains it.
>
> > Let me explain the case I'm trying to tackle. I have two old dump
> > data, each of them have couple objects de
On 9/10/16 7:17 AM, Peter Eisentraut wrote:
> Let's start with that. Here is a patch that adds a pg_sequences view in
> the style of pg_tables, pg_indexes, etc. This seems useful independent
> of anything else, but would give us more freedom to change things around
> behind the scenes.
I have re
Andres Freund writes:
> On 2016-09-14 19:28:25 -0400, Tom Lane wrote:
>> So I think we should continue investigating this way of doing things.
>> I'll try to take a look at the executor end of it tomorrow. However
>> I'm leaving Friday for a week's vacation, and may not have anything to
>> show b
On 2016-10-31 09:28:00 -0400, Robert Haas wrote:
> On Fri, Oct 28, 2016 at 2:46 AM, Andres Freund wrote:
> > Well, that'll also make the feature not particularly useful :(. My
> > suspicion is that the way to suceed here isn't to rely more on testing
> > as part of the scan, but create a more gen
> On 27 Oct 2016, at 09:23, Kyotaro HORIGUCHI
> wrote:
>
> Hello, thank you very much for the work. My work became quite
> easier with it.
>
> At Tue, 25 Oct 2016 12:23:48 +0300, Heikki Linnakangas
> wrote in <08e7892a-d55c-eefe-76e6-7910bc8dd...@iki.fi>
>>
>> [..]
>> The perl scripts are st
Hi Tom,
On 2016-09-14 19:28:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 19:35:22 -0400, Tom Lane wrote:
> >> Anyway I'll draft a prototype and then we can compare.
>
> > Ok, cool.
>
> Here's a draft patch that is just meant to investigate what the planner
> changes might
27.10.2016, 21:53, Merlin Moncure kirjoitti:
As noted earlier, I was not able to reproduce the issue with
crashme.sh, which was:
NUM_FORKS=16
do_parallel psql -p 5432 -c"select PushMarketSample('1740')" castaging_test
do_parallel psql -p 5432 -c"select PushMarketSample('4400')" castaging_test
On Fri, Oct 28, 2016 at 11:35 AM, Michael Paquier
wrote:
> And here we go. Here is a review as well as a large brush-up for this
> patch. A couple of things:
Thanks for reviewing the patch in detail.
> - Speaking of which using BKPIMAGE_IS_REQUIRED_FOR_REDO stored in the
> block definition is sor
Hello,
The attached patch implements the suggestion by Amit before.
What I'm motivated is to collect extra run-time statistics specific
to a particular ForeignScan/CustomScan, not only the standard
Instrumentation; like DMA transfer rate or execution time of GPU
kernels in my case.
Per-node DSM
On 10/31/2016 02:51 PM, Amit Kapila wrote:
On Mon, Oct 31, 2016 at 12:02 AM, Tomas Vondra
wrote:
Hi,
On 10/27/2016 01:44 PM, Amit Kapila wrote:
I've read that analysis, but I'm not sure I see how it explains the "zig
zag" behavior. I do understand that shifting the contention to some other
(a
Hello,
The attached patch is revised version of the pass-down-bounds feature.
Its functionality is not changed from the previous version, however,
implementation was revised according to the discussion at the last CF.
This patch add a new fields (ps_numTuples) to the PlanState. This is
a hint for
On 2016-10-31 09:35:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > this doesn't look right. The ctid shouldn't be in the aggregate output -
> > after all it's pretty much meaningless here.
>
> I suspect it's being added to support EvalPlanQual row re-fetches.
Hm, that doesn't seem particu
On Mon, Oct 31, 2016 at 7:02 PM, Tomas Vondra
wrote:
>
> The remaining benchmark with 512 clog buffers completed, and the impact
> roughly matches Dilip's benchmark - that is, increasing the number of clog
> buffers eliminates all positive impact of the patches observed on 128
> buffers. Compare t
On 2016-10-31 09:44:16 -0400, Robert Haas wrote:
> On Mon, Oct 31, 2016 at 4:59 AM, Andres Freund wrote:
> > I^Wsomebody appears to have made a number of dumb mistakes in
> > WalSndWriteData(), namely:
> > 1) The timestamp is set way too late, after
> >pq_putmessage_noblock(). That'll sometime
On Mon, Oct 31, 2016 at 12:02 AM, Tomas Vondra
wrote:
> Hi,
>
> On 10/27/2016 01:44 PM, Amit Kapila wrote:
>
> I've read that analysis, but I'm not sure I see how it explains the "zig
> zag" behavior. I do understand that shifting the contention to some other
> (already busy) lock may negatively i
On Mon, Oct 31, 2016 at 4:59 AM, Andres Freund wrote:
> I^Wsomebody appears to have made a number of dumb mistakes in
> WalSndWriteData(), namely:
> 1) The timestamp is set way too late, after
>pq_putmessage_noblock(). That'll sometimes work, sometimes not. I
>have no idea how that ended
On 10/30/2016 07:32 PM, Tomas Vondra wrote:
Hi,
On 10/27/2016 01:44 PM, Amit Kapila wrote:
On Thu, Oct 27, 2016 at 4:15 AM, Tomas Vondra
wrote:
FWIW I plan to run the same test with logged tables - if it shows
similar
regression, I'll be much more worried, because that's a fairly typical
sce
Andres Freund writes:
> this doesn't look right. The ctid shouldn't be in the aggregate output -
> after all it's pretty much meaningless here.
I suspect it's being added to support EvalPlanQual row re-fetches.
> Casting a wider net: find_hash_columns() and it's subroutines seem like
> pretty mu
On 31 October 2016 at 16:52, Andres Freund wrote:
> Hi,
>
> On 2016-10-31 16:34:38 +0800, Craig Ringer wrote:
>> TL;DR: Logical decoding clients need to generate their own keepalives
>> and not rely on the server requesting them to prevent timeouts. Or
>> admins should raise the wal_sender_timeout
On Fri, Oct 28, 2016 at 2:46 AM, Andres Freund wrote:
> Well, that'll also make the feature not particularly useful :(. My
> suspicion is that the way to suceed here isn't to rely more on testing
> as part of the scan, but create a more general fastpath for qual
> evaluation, which atm is a *LOT*
On 10/31/2016 05:01 AM, Jim Nasby wrote:
On 10/30/16 1:32 PM, Tomas Vondra wrote:
Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's
some sort of CPU / OS scheduling artifact. For example, the system has
36 physical cores, 72 virtual ones (thanks to HT). I find it strange
On Fri, Oct 28, 2016 at 8:46 AM, Julien Rouhaud
wrote:
> It looks like pq_putmessage_hook and pq_flush_hook were meant for
> development purpose and not supposed to be committed.
>
> Attached patch remove them.
Thanks. Those were actually remnants of an earlier design which
didn't survive contac
amul sul writes:
> On Fri, Oct 28, 2016 at 6:22 PM, Robert Haas wrote:
>> There's a comment in dumpExtension() that explains it.
> Let me explain the case I'm trying to tackle. I have two old dump
> data, each of them have couple objects depend on plpgsql. I have
> restored first dump and trying
On Fri, Oct 28, 2016 at 3:40 AM, Andres Freund wrote:
>>
>> There is not much common functionality between the two.
>
> I don't really agree. For me manual and automated prewarming are pretty
> closely related. Sure they have their independent usages, and not too
> much code might be shared. But g
On Fri, Oct 28, 2016 at 3:09 AM, Ashutosh Bapat
wrote:
> I think there are going to be two kinds of partitioning use-cases.
> First, carefully hand-crafted by DBAs so that every partition is
> different from other and so is every join between two partitions.
> There will be lesser number of partit
On 9/30/16 12:50 PM, Anastasia Lubennikova wrote:
> The patches are good, no complaints.
> But again, I have the same question.
> I was confused, why do we always dump sequence data,
> because I'd overlooked the --sequence-data key. I'd rather leave this
> option,
> because it's quite non intuitiv
On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier
wrote:
> And here we go. Here is a review as well as a large brush-up for this
> patch. A couple of things:
> - wal_consistency is using a list of RMGRs, at the cost of being
> PGC_POSTMASTER. I'd suggest making it PGC_SUSER, and use a boolean (I
>
Hi,
while hacking up nodeAgg.c to use a dedicated slot/desc for the
hashtable, an assert I placed brought up a weird case:
regression[29535][1]=# EXPLAIN VERBOSE update bar set f2 = f2 + 100 where f1 in
(select f1 from foo);
┌──
The BRIN Bitmap Index Scan has the same problem. I have seen people
confused by this. I think N/A would clearly improve the situation.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jim Nasby writes:
> BTW, I've sometimes wished for a mode where queries would silently have
> result ordering intentionally futzed, to eliminate any possibility of
> dependence on tuple ordering (as well as having sequences start at some
> random value).
FWIW, SQLite has this, in the form of 'PR
I have attached a version of the patch rebased on top of the OpenSSL 1.1
changes.
Andreas
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index 668f217..a1b582f 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openss
Le 31/10/2016 à 04:35, Karl O. Pinc a écrit :
> Hi Gilles,
>
> On Sat, 29 Oct 2016 22:00:08 +0200
> Gilles Darold wrote:
>
>> The attached v10 of the current_logfiles patch
> Attached is a patch to apply on top of the v10 patch.
>
> It updates current_logfiles only once per log rotation.
> I see
Hi,
I^Wsomebody appears to have made a number of dumb mistakes in
WalSndWriteData(), namely:
1) The timestamp is set way too late, after
pq_putmessage_noblock(). That'll sometimes work, sometimes not. I
have no idea how that ended up happening. It's eye-wateringly dumb.
2) We only do WalSn
Hi,
On 2016-10-31 16:34:38 +0800, Craig Ringer wrote:
> TL;DR: Logical decoding clients need to generate their own keepalives
> and not rely on the server requesting them to prevent timeouts. Or
> admins should raise the wal_sender_timeout by a LOT when using logical
> decoding on DBs with any big
Hi all
I've been investigating some intermittent timeout issues I've seen
with BDR users in the wild and I think I've identified an issue with
how logical decoding sends data and handles feedback.
TL;DR: Logical decoding clients need to generate their own keepalives
and not rely on the server req
Le 30/10/2016 à 08:04, Karl O. Pinc a écrit :
> On Sat, 29 Oct 2016 22:00:08 +0200
> Gilles Darold wrote:
>
>> The attached v10 of the current_logfiles patch include your last
>> changes on documentation but not the patch on v9 about the
>> user-supplied GUC value. I think the v10 path is ready fo
Jim Nasby wrote:
> On 10/30/16 9:12 AM, Tom Lane wrote:
>> I think there will be a lot of howls. People expect that creating
>> a table by inserting a bunch of rows, and then reading back those
>> rows, will not change the order. We already futzed with that guarantee
>> a bit with syncscans, but
68 matches
Mail list logo
