On Wed, Sep 28, 2016 at 3:40 PM, Thomas Munro
wrote:
> On Wed, Sep 28, 2016 at 6:25 PM, Michael Paquier
> wrote:
>> wait-event-set-v8.patch
>
> Ok, I'm just about ready to mark this as 'Ready for Committer'.
Thanks.
> Just a couple of things:
> + pgstat_report_wait_start((uint8) classId, (uint1
On Tue, Sep 27, 2016 at 11:27 PM, David Steele wrote:
> On 9/26/16 2:36 AM, Michael Paquier wrote:
>
>> Just a nit:
>>
>> - postmaster.pid
>> + postmaster.pid and postmaster.opts
>>
>> Having one block for each file would be better.
>
> OK, changed.
You did no
On 2016-09-28 00:02, Andres Freund wrote:
> On 2015-09-07 17:05:10 +0100, Greg Stark wrote:
>> I feel like I remember hearing about this before but I can't find any
>> mention of it in my mail archives. It seems pretty simple to add
>> support for LLVM's Address Sanitizer (asan) by using the hooks
On Wed, Sep 28, 2016 at 6:25 PM, Michael Paquier
wrote:
> wait-event-set-v8.patch
Ok, I'm just about ready to mark this as 'Ready for Committer'. Just
a couple of things:
+ pgstat_report_wait_start((uint8) classId, (uint16) eventId);
Unnecessary casts.
+
+ Client
+ Sec
From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
> > huge_pages=off: 70412 tps
> > huge_pages=on : 72100 tps
>
> Hmm. I guess it could be noise or random code rearrangement effects.
I'm not the difference was a random noise, because running multiple set of
three runs of pgbench (huge
On Wed, Sep 28, 2016 at 10:43 AM, Masahiko Sawada wrote:
> On Tue, Sep 27, 2016 at 9:06 PM, Ashutosh Bapat
> wrote:
>> On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada
>> wrote:
>>> On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
>>> wrote:
On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada
On 09/28/2016 02:35 AM, Mark Dilger wrote:
The function
static void xlog_outdesc(StringInfo buf, XLogReaderState *record);
in src/backend/access/transam/xlog.c is called by XLogInsertRecord,
and after returning a string describing an XLogRecord, it clears the
state data in its XLogReaderState
On 2016/09/28 13:30, Ashutosh Bapat wrote:
> This mail looks exactly same as that from Shrinivas. Please check answers
> there.
Here is a link to the discussion thread that Ashutosh is referring to:
https://www.postgresql.org/message-id/flat/CAFjFpRfxJJJGNhtQaS2CQ7Boyfo88nu-45JcNKeREUbQUPxOEw%40
On Wed, Sep 28, 2016 at 9:39 AM, Thomas Munro
wrote:
> Ok, if they really are independent then shouldn't we take advantage of
> that at call sites where we might be idle but we might also be waiting
> for the network? For example we could do this:
>
> /* Sleep until something happens
On Tue, Sep 27, 2016 at 9:06 PM, Ashutosh Bapat
wrote:
> On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada
> wrote:
>> On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
>> wrote:
>>> On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada
>>> wrote:
On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat
On Tue, Sep 27, 2016 at 9:55 AM, Michael Paquier
wrote:
> Seems overcomplicated to me. How about returning the control file all
> the time and let the caller pfree the result? You could then use
> crc_ok in pg_ctl.c's get_control_dbstate() to do the decision-making.
In short I would just go with
On 24 September 2016 at 06:39, Robert Haas wrote:
> Since Kyotaro Horiguchi found that my previous design had a
> system-wide performance impact due to the ExecProcNode changes, I
> decided to take a different approach here: I created an async
> infrastructure where both the requestor and the requ
This mail looks exactly same as that from Shrinivas. Please check answers there.
On Tue, Sep 27, 2016 at 11:32 AM, davinder singh
wrote:
> Hi,
>I am working in optimizer module of postgreSQL 9.4.1. My project is
> concerned with the plan returned by the optimizer.
>
> I am trying to return a
On Tue, Sep 27, 2016 at 11:43 AM, Srinivas Karthik V
wrote:
> Dear PostgresSQL Hackers,
>I am working in optimizer module of postgreSQL 9.4.1. I am trying to
> return a subplan for a query instead of full plan.For this I need to return
> an intermediate plan (or path) from the DP lattice (i.e.
On Wed, Sep 28, 2016 at 1:26 PM, Tsunakawa, Takayuki
wrote:
>> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
>> On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki
>> wrote:
>> > Credit: This patch is based on Thomas Munro's one
2016-09-27 23:12 GMT+02:00 Tom Lane :
> Vitaly Burovoy writes:
> > On 9/27/16, Tom Lane wrote:
> >> I'm not exactly convinced that you did. There's only one copy of
> >> Archive->remoteVersion, and you're overwriting it long before the
> >> dump process is over.
>
> > It does not seem that I'm
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane,
> though. Try to make sure it doesn't leave partly-written stats files
> behind.
The attached patch based on
rangetypes_spgist.c contains a call to detoast a pointer which was
just returned from a detoast operation. This seems to do no harm,
but is to my mind a sloppy thinko. Fix attached.
tsgistidx.c contains a detoast of a pointer where detoast of a datum
was likely intended. Fix attached.
tsrank.c
On Thu, Sep 15, 2016 at 2:41 PM, Thomas Munro
wrote:
> On Thu, Sep 1, 2016 at 2:16 AM, Ivan Kartyshov
> wrote:
>> Hi hackers,
>>
>> Few days earlier I've finished my work on WAITLSN statement utility, so I’d
>> like to share it.
>> [...]
>> Your feedback is welcome!
>>
>> [waitlsn_10dev.patch]
>
> I think the better fix here is to simply remove the typedef. It doesn't
> seem to have much of a benefit, and makes using correct types harder as
> demonstrated here. We don't even use it internally in fd.c..
>
Fine by me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
On Tue, Sep 27, 2016 at 6:24 PM, Masahiko Sawada wrote:
> * Providing the prepare id of 2PC.
> Current patch adds new API prepare_id_provider() but we can use the
> prepare id of 2PC that is used on parent server.
And we assume that when this is used across many servers there will be
no GID con
On Mon, Sep 26, 2016 at 7:07 PM, Michael Paquier
wrote:
> On Mon, Sep 26, 2016 at 1:46 PM, Thomas Munro
> wrote:
>> If the class really is strictly implied by the WaitEventIdentifier,
>> then do we really need to supply it everywhere when calling the
>> various wait functions? That's going to be
Friends,
here is another patch, this time fixing the casting away of const
in the regex code.
Mark Dilger
regex.patch.1
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki
> wrote:
> > Credit: This patch is based on Thomas Munro's one.
>
> How are they different?
As Thomas mentioned, his patch (on
Hi,
Can we please keep this topic in one thread? Anybody motivated to apply
these isn't going to have an easy time applying things, and everyone
else is just having a harder time sorting through the mails.
On 2016-09-27 17:08:24 -0700, Mark Dilger wrote:
> along the lines of other similar emails
Friends,
along the lines of other similar emails from me of late,
I tried to avoid casting away const when using the FileName
typedef. There are several calls where a (const char *) has to
be cast to (char *) due to FileName being typedef'd as
non-const. But changing the typedef to const doesn't
Friends,
comparators usually take arguments like
(const void *a, const void *b)
and do something read-only to a and b. In our
sources, we typically cast these to something else,
like (char *), and do something read-only. This
generates a lot of warnings if using -Wcast-qual.
To fix that, I
The function
static void xlog_outdesc(StringInfo buf, XLogReaderState *record);
in src/backend/access/transam/xlog.c is called by XLogInsertRecord,
and after returning a string describing an XLogRecord, it clears the
state data in its XLogReaderState argument. That mixes the read-only
semantic
On 2016-09-27 19:31:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
> >> I would love to remove all the #ifdef's and have the
> >> macros just be no-ops if they're compiled out for example...
>
> > Don't we pretty much have that?
>
> I think
Andres Freund writes:
> debugging a citus valgrind bleat I noticed that hash_create() accesses
> the result of palloc(0) as an hash element:
> Do we consider this an API usage error that we want to fix?
I think Assert(nelem > 0) would be an appropriate response.
There are probably issues in sizin
Andres Freund writes:
> On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
>> I would love to remove all the #ifdef's and have the
>> macros just be no-ops if they're compiled out for example...
> Don't we pretty much have that?
I think "((void) 0)" is a more common spelling of a dummy statement.
T
On 2016-09-28 00:23:11 +0100, Greg Stark wrote:
> On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote:
> > Any plans to pick this up again?
>
> Yeah, I was just thinking I should pick this up again.
>
> > I vote for renaming the VALGRIND names etc. to something more tool-neutral.
> > I think
On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote:
> Any plans to pick this up again?
Yeah, I was just thinking I should pick this up again.
> I vote for renaming the VALGRIND names etc. to something more tool-neutral. I
> think it's going to be too confusing otherwise.
Hm, the danger ther
Hi,
debugging a citus valgrind bleat I noticed that hash_create() accesses
the result of palloc(0) as an hash element:
HTAB *
hash_create(const char *tabname, long nelem, HASHCTL *info, int flags)
{
...
if ((flags & HASH_SHARED_MEM) ||
nelem < hctl->nelem_alloc)
{
On 9/27/16, Vitaly Burovoy wrote:
> On 9/27/16, Tom Lane wrote:
>> (The other thing I'd want here is a --target-version option so that
>> you could get the same output alterations in pg_dump or pg_restore to
>> text. Otherwise it's nigh undebuggable, and certainly much harder
>> to test than it
Tom van Tilburg writes:
> Good to know and I agree that it is not an urgent case.
> I think this practice might be more common in the POSTGIS community where
> there are plenty of set-returning-functions used in this way. My use was
> taking a random sample of a pointcloud distrubution.
Fix pushe
Hi,
On 2015-09-07 17:05:10 +0100, Greg Stark wrote:
> I feel like I remember hearing about this before but I can't find any
> mention of it in my mail archives. It seems pretty simple to add
> support for LLVM's Address Sanitizer (asan) by using the hooks we
> already have for valgrind.
Any plan
On 9/27/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/27/16, Tom Lane wrote:
>>> I'm not exactly convinced that you did. There's only one copy of
>>> Archive->remoteVersion, and you're overwriting it long before the
>>> dump process is over.
>
>> It does not seem that I'm "overwriting it
Jeevan,
* Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote:
> Here are the review comments:
[... many good comments ...]
Many thanks for the review, I believe I agree with pretty much all your
comments and will update the patch accordingly.
Responses for a couple of them are below.
> 6. I
On 09/26/2016 08:48 PM, Tomas Vondra wrote:
On 09/26/2016 07:16 PM, Tomas Vondra wrote:
The averages (over the 10 runs, 5 minute each) look like this:
3.2.80 1 8 16 32 64128192
granu
On 9/27/16 6:16 AM, Kyotaro HORIGUCHI wrote:
I apologize in advance that the comments in this message might
one of the ideas discarded in the past thread.. I might not grasp
the discussion completely X(
The attached patches are rebased to the master and additional one
mentioned below.
I tried
Vitaly Burovoy writes:
> On 9/27/16, Tom Lane wrote:
>> I'm not exactly convinced that you did. There's only one copy of
>> Archive->remoteVersion, and you're overwriting it long before the
>> dump process is over.
> It does not seem that I'm "overwriting it long before the dump process
> is ov
Peter Eisentraut writes:
> I think using ValidateDate() was the right idea. That is what we use
> for checking date validity everywhere else.
Note that we've got two different CF entries, and threads, covering
fundamentally the same territory here, ie making to_timestamp et al
behave more sanely
On 9/27/16, Tom Lane wrote:
> Vitaly Burovoy writes:
>> On 9/27/16, Tom Lane wrote:
>>> The general policy has always been that pg_dump output is only expected
>>> to
>>> restore without errors into a server that's the same or newer version as
>>> pg_dump (regardless of the server version being
> On 27 Sep 2016, at 15:49, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> When running ./configure on a system without Flex/Bison it’s easy to miss the
>> warning that flies past and then run into compilation error instead. When it
>> happened to a colleague yesterday a brief discussion came
On Thu, Sep 22, 2016 at 6:41 AM, Ashutosh Bapat
wrote:
> [ new patch ]
This should probably get updated since Rajkumar reported a crash.
Meanwhile, here are some comments from an initial read-through:
+ * Multiple relations may be partitioned in the same way. The relations
+ * resulting from joi
On 09/25/2016 01:00 AM, Amit Kapila wrote:
Attached patch fixes the problem, now we do perform full page writes
for bitmap pages. Apart from that, I have rebased the patch based on
latest concurrent index patch [1]. I have updated the README as well
to reflect the WAL logging related informatio
On 09/20/2016 09:02 AM, Amit Kapila wrote:
On Fri, Sep 16, 2016 at 11:22 AM, Amit Kapila wrote:
I do want to work on it, but it is always possible that due to some
other work this might get delayed. Also, I think there is always a
chance that while doing that work, we face some problem due to
On 09/27/2016 02:04 PM, Dave Cramer wrote:
On 26 September 2016 at 14:52, Dave Cramer wrote:
This crashes with arrays with non-default lower bounds:
postgres=# SELECT * FROM test_type_conversion_array_int
4('[2:4]={1,2,3}');
INFO: ([1, 2, ], )
server closed the connection unexpectedly
Vitaly Burovoy writes:
> On 9/27/16, Tom Lane wrote:
>> The general policy has always been that pg_dump output is only expected to
>> restore without errors into a server that's the same or newer version as
>> pg_dump (regardless of the server version being dumped from).
> Why can't I use it if
On Fri, Sep 9, 2016 at 4:25 PM, Kevin Grittner wrote:
> On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote:
> These patches apply and build on top of 5c609a74 with no problems,
> but `make check` finds differences per the attached. Please
> investigate why the regression tests are failing and
On 9/27/16, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
>> wrote:
>>> We do dump/restore schemas/data via custom/dir formats and we have to
>>> keep several client versions for 9.2, 9.4 and 9.5 versions on local
>>> workstations because after pg_resto
This patch also applied with minor offsets, compiled without
warning, and passes regression tests, including `make check-world`
with TAP tests enabled. It looks good to me, presenting a cleaner
API.
I really want to get this to the point where we can dump and
restore nested materialized views bet
On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki
wrote:
> Credit: This patch is based on Thomas Munro's one.
How are they different?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Kevin Grittner writes:
> This patch applies with a few minor offsets, compiles without
> warning, and passes all regression tests including `make
> check-world` with TAP tests enabled. This and the related patch
> dealing with the parallel API definitely make things cleaner and
> easier to follow
Robert Haas writes:
> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
> wrote:
>> We do dump/restore schemas/data via custom/dir formats and we have to
>> keep several client versions for 9.2, 9.4 and 9.5 versions on local
>> workstations because after pg_restore95 connects to 9.2, it fails when
Amul Sul writes:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:not tested
> Note for committer : There are unn
On 9/26/16 2:02 AM, Michael Paquier wrote:
> On Mon, Sep 26, 2016 at 2:15 AM, David Steele wrote:
>
> Thanks for the review and the comments!
>
>> I notice that the copyright from pgcrypto/sha1.c was carried over but
>> not the copyright from pgcrypto/sha2.c. I'm no expert on how this
>> works,
This patch applies with a few minor offsets, compiles without
warning, and passes all regression tests including `make
check-world` with TAP tests enabled. This and the related patch
dealing with the parallel API definitely make things cleaner and
easier to follow.
I find it disappointing that AC
Hello.
During processing of logical messages in ReorderBufferSerializeChange()
pointer to ondisk structure isn’t updated after possible reorder buffer realloc
by
ReorderBufferSerializeReserve().
Actual reason spotted by Konstantin Knizhnik.
reorderbuffer.patch
Description: Binary data
--
S
On Tue, Sep 27, 2016 at 3:31 PM, Robert Haas wrote:
> You seem to have erased the subject line from this email somehow.
I think that that was Gmail. Maybe that's new? Generally, I have to go
out of my way to change the subject line, so it seems unlikely that I
fat-fingered it. I wish that they'd
On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy
wrote:
> At work we use several major versions of PostgreSQL, and developers
> use non-local clusters for developing and debugging.
> We do dump/restore schemas/data via custom/dir formats and we have to
> keep several client versions for 9.2, 9.4 an
You seem to have erased the subject line from this email somehow.
On Tue, Sep 27, 2016 at 10:18 AM, Peter Geoghegan wrote:
> On Tue, Sep 27, 2016 at 3:08 PM, Robert Haas wrote:
>> I don't know what any of that means. You said we need something like
>> an LWLock, but I think we don't. The worke
On 9/26/16 2:36 AM, Michael Paquier wrote:
> Just a nit:
>
> - postmaster.pid
> + postmaster.pid and postmaster.opts
>
> Having one block for each file would be better.
OK, changed.
> +const char *excludeFile[] =
> excludeFiles[]?
>
> +# Move pg_replslot out
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think the debate is more about whether moving the source display
> functionality over to \sf is a better solution than rearranging \df+
> output. (If we had consensus to do that, I'd be happy to go code it,
> but I'm not going to invest the effort when it
On Mon, Sep 26, 2016 at 11:17 AM, Anastasia Lubennikova
wrote:
>> Is there any fundamental problem in storing them in ordered way? I
>> mean to say, you need to anyway store all the column values on leaf
>> page, so why can't we find the exact location for the complete key.
>> Basically use trunc
On Tue, Sep 27, 2016 at 3:08 PM, Robert Haas wrote:
> I don't know what any of that means. You said we need something like
> an LWLock, but I think we don't. The workers just write the results
> of their own final merges into shm_mqs. The leader can read from any
> given shm_mq until no more tu
On Mon, Sep 26, 2016 at 3:40 PM, Peter Geoghegan wrote:
> On Mon, Sep 26, 2016 at 6:58 PM, Robert Haas wrote:
>>> That requires some kind of mutual exclusion mechanism, like an LWLock.
>>
>> No, it doesn't. Shared memory queues are single-reader, single-writer.
>
> The point is that there is a n
Robert Haas writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
>> That doesn't mean, at least to me, that we should forgo considering
>> better alternatives.
> I don't think so, either, but if we could agree that "Tom's patch >
> doing nothing" then he could commit it and we could d
On 09/26/2016 10:45 PM, Peter Eisentraut wrote:
On 9/26/16 1:39 PM, Jesper Pedersen wrote:
Left as is, since BuildTupleFromCStrings() vs. xyzGetDatum() are equally
readable in this case. But, I can change the patch if needed.
The point is that to use BuildTupleFromCStrings() you need to conver
On Tue, Sep 27, 2016 at 2:13 PM, Tom Lane wrote:
> I can see the value of processing unique indexes before non-unique ones.
> I'm pretty suspicious of trying to prioritize primary keys first, though,
> because (a) it's not clear why bother, and (b) PG is a tad squishy about
> whether an index is a
On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
> I feel like we're getting wrapped around the axle as it regards who is
> perceived to be voting for what.
True. It's not very clear; thanks for trying to shed some light on it.
> I don't particularly care for it either, primairly because \
On 9/26/16 2:36 AM, Michael Paquier wrote:
>
> Just a nit:
>
> - postmaster.pid
> + postmaster.pid and postmaster.opts
>
> Having one block for each file would be better.
I grouped these because they are related and because there are now other
bullets where mu
Daniel Gustafsson writes:
> When running ./configure on a system without Flex/Bison itâs easy to miss
> the
> warning that flies past and then run into compilation error instead. When it
> happened to a colleague yesterday a brief discussion came to the conclusion
> that it would be neat it th
On Tue, Sep 27, 2016 at 10:42 PM, Heikki Linnakangas wrote:
> The libpq-side is not. Just calling random() won't do. We haven't needed for
> random numbers in libpq before, but now we do. Is the pgcrypto solution
> portable enough that we can use it in libpq?
Do you think that urandom would be en
On 09/27/2016 04:19 PM, Michael Paquier wrote:
On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas wrote:
* A source of random values. This currently uses PostmasterRandom()
similarly to how the MD5 salt is generated, in the server, but plain old
random() in the client. If built with OpenSSL, w
Hello Jeevan.
1. About documentation, I think it will be good idea to arrange the
operators table with the precedence and add a line at top: "In
decreasing order of precedence".
Done, see attached.
2. You may want to remove the comment:
+ /* should it do a lazy evaluation of the
When running ./configure on a system without Flex/Bison it’s easy to miss the
warning that flies past and then run into compilation error instead. When it
happened to a colleague yesterday a brief discussion came to the conclusion
that it would be neat it the flex and bison checks took the existen
On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas wrote:
> * Added error-handling for OOM and other errors in liybpq
> * In libpq, added check that the server sent back the same client-nonce
> * Turned ERRORs into COMMERRORs and removed DEBUG4 lines (they could reveal
> useful information to an
Heikki Linnakangas writes:
> On 09/24/2016 02:34 PM, Peter Geoghegan wrote:
>> I go on to explain how this patch represents a partial solution to
>> that [1]. That's what I mean by "useful practical consequences". As I
>> say in [1], I think we could even get a full solution, if we applied
>> this
Hi,
I am working in optimizer module of postgreSQL 9.4.1. My project is
concerned with the plan returned by the optimizer.
I am trying to return a subplan for a query instead of full plan. For this
I need to return a path form *RelOptInfo *standard_join_search() *at*
allpaths.c *other than from
On Fri, 9 Sep 2016 18:29:23 +0700
Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Hi,
>
> Regarding to the previous conversations [1], [2], here is a patch
> (with some improvements from Nikita Glukhov) for the generic type
> subscription. It allows
> to define type-specific subscription logic for
On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada wrote:
> On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
> wrote:
>> On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada
>> wrote:
>>> On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat
>>> wrote:
My original patch added code to manage the files
On Tue, Sep 27, 2016 at 12:45 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hello Stephen,
>
> I am reviewing the latest patch in detail now and will post my review
> comments later.
>
Here are the review comments:
1. In documentation, we should put both permissive as well as r
On 2016/09/27 18:09, Ashutosh Bapat wrote:
>>> I tried to debug the problem somewhat. In set_append_rel_pathlist(),
>>> it finds that at least one child has a parameterized path as the
>>> cheapest path, so it doesn't create an unparameterized path for append
>>> rel. At the same time there is a pa
Hi,
The patch has correct precedence now.
Further minor comments:
1. About documentation, I think it will be good idea to arrange the
operators
table with the precedence and add a line at top: "In decreasing order of
precedence".
2. You may want to remove the comment:
+ /* should it d
On 26 September 2016 at 14:52, Dave Cramer wrote:
>
>
>
>>
>> This crashes with arrays with non-default lower bounds:
>>
>> postgres=# SELECT * FROM test_type_conversion_array_int
>> 4('[2:4]={1,2,3}');
>> INFO: ([1, 2, ], )
>> server closed the connection unexpectedly
>> This probably m
On Wed, Sep 21, 2016 at 8:47 AM, Dilip Kumar wrote:
> Summary:
> --
> At 32 clients no gain, I think at this workload Clog Lock is not a problem.
> At 64 Clients we can see ~10% gain with simple update and ~5% with TPCB.
> At 128 Clients we can see > 50% gain.
>
> Currently I have test
Hi,
I apologize in advance that the comments in this message might
one of the ideas discarded in the past thread.. I might not grasp
the discussion completely X(
The attached patches are rebased to the master and additional one
mentioned below.
At Wed, 18 May 2016 17:57:49 -0400, Michael Paquier
On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat
wrote:
> On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada
> wrote:
>> On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat
>> wrote:
>>> My original patch added code to manage the files for 2 phase
>>> transactions opened by the local server on the rem
On Sun, 25 Sep 2016 17:31:53 +0530
Mithun Cy wrote:
> I have some more comments on libpq-failover-8.patch
>
> + /* FIXME need to check that port is numeric */
>
> Is this still applicable?.
>
Unfortunately, it was. I've fixed this problem in 9-th version of patch
(attached)
>
> I think we ne
Good to know and I agree that it is not an urgent case.
I think this practice might be more common in the POSTGIS community where
there are plenty of set-returning-functions used in this way. My use was
taking a random sample of a pointcloud distrubution.
I took the liberty to post your answer at
On Tue, Sep 27, 2016 at 2:46 PM, Amit Langote
wrote:
> On 2016/09/27 15:44, Ashutosh Bapat wrote:
>>> By the way, I fixed one thinko in your patch as follows:
>>>
>>> -result->oids[i] = oids[mapping[i]];
>>> +result->oids[mapping[i]] = oids[i];
>>
>> While I can not spot any proble
On 2016/09/27 15:44, Ashutosh Bapat wrote:
>> By the way, I fixed one thinko in your patch as follows:
>>
>> -result->oids[i] = oids[mapping[i]];
>> +result->oids[mapping[i]] = oids[i];
>
> While I can not spot any problem with this logic, when I make that
> change and run partitio
>>
>> Please check if you are able to reproduce these errors in your
>> repository. I made sure that I cleaned up all partition-wise join code
>> before testing this, but ... .
>
> Thanks for the test case. I can reproduce the same.
>
>> I tried to debug the problem somewhat. In set_append_rel_pat
On 09/27/2016 11:38 AM, Peter Geoghegan wrote:
On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote:
I didn't think very hard about it, but yeah, think so..
Do you think it's worth a backpatch? Or, too early to tell?
Too early to tell..
- Heikki
--
Sent via pgsql-hackers mailing li
Sorry about the delay in replying.
On 2016/09/15 21:58, Ashutosh Bapat wrote:
> Hi Amit,
>
> It looks like there is some problem while creating paramterized paths
> for multi-level partitioned tables. Here's a longish testcase
>
> [ ... ]
>
> Please check if you are able to reproduce these err
On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote:
> I didn't think very hard about it, but yeah, think so..
Do you think it's worth a backpatch? Or, too early to tell?
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
On 09/27/2016 11:22 AM, Peter Geoghegan wrote:
On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote:
Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to
fix that. I'm not convinced that we need all the complications of this
patch, to get that fixed. (In particular, in
On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote:
> Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to
> fix that. I'm not convinced that we need all the complications of this
> patch, to get that fixed. (In particular, indexam's still wouldn't need to
> care about
1 - 100 of 103 matches
Mail list logo