On 3/28/16 4:42 AM, Emre Hasegeli wrote:
Now, we are using a
function to replace an enum type on all tables with another one, but
we are not at all happy with this solution. It requires all objects
which were using the enum to be dropped and recreated, and it rewrites
the tables, so it greatly i
On 3/28/16 11:03 AM, Magnus Hagander wrote:
That should work yeah. And given that we already use that check in other
places, it seems it should be perfectly safe. And as long as we only do
a WARNING and not abort if the fsync fails, we should be OK if people
intentionally store their backups on
Thank you Pavel, David.
Thank you for pointing syntaxes to be addressed. Most of the are
addressed in the attached patch.
At Tue, 22 Mar 2016 12:57:27 -0400, David Steele wrote in
<56f17977.8040...@pgmasters.net>
> Hi Kyotaro,
>
> On 3/18/16 3:22 AM, Pavel Stehule wrote:
>
> > I am looki
On 2016/03/25 17:16, Etsuro Fujita wrote:
The approach that we discussed would minimize the code for the FDW
author to write, by providing the support functions you proposed. I'll
post a patch for that early next week.
I added two helper functions: GetFdwScanTupleExtraData and
FillFdwScanTupl
On Mon, Mar 28, 2016 at 10:09 PM, Tom Lane wrote:
> Christian Ullrich writes:
>> * Tom Lane wrote:
>>> Yeah. I've been staring at that for awhile, but it's not clear where
>>> the problem is. There are a bunch of other SET TIME ZONE commands in
>>> the regression tests, how is it that this triv
I guess the question here is whether we want the part-c patch, which
removes the historical \setrandom syntax. That's technically no
longer needed since we now can use random() as a function directly
inside \set commands, but we might want it anyway for backward
compatibility.
This patch is i
Christian Ullrich writes:
> * Tom Lane wrote:
>> Yeah. I've been staring at that for awhile, but it's not clear where
>> the problem is. There are a bunch of other SET TIME ZONE commands in
>> the regression tests, how is it that this trivial case fails on the
>> Windows critters?
> zic aborts
On Tue, Mar 29, 2016 at 1:36 PM, Christian Ullrich wrote:
> * Tom Lane wrote:
>
>> Michael Paquier writes:
>>>
>>> Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana.
>>>
>>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse&dt=2016-03-29%2000%3A42%3A08
>>> The o
On Tue, Mar 29, 2016 at 1:56 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote:
>>> pgbench: Support double constants and functions.
>
>> Instead of INT64_MIN and INT64_MAX, I think that it would be better to
>> use PG_INT64_MIN and PG_INT64_MAX.
Michael Paquier writes:
> On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote:
>> pgbench: Support double constants and functions.
> Instead of INT64_MIN and INT64_MAX, I think that it would be better to
> use PG_INT64_MIN and PG_INT64_MAX.
Indeed.
> Note as well that DOUBLE is an
> existing va
On Tue, Mar 29, 2016 at 3:21 AM, Petr Jelinek wrote:
> On 28/03/16 14:46, Dilip Kumar wrote:
>
>>
>> Conclusion:
>> ---
>> 1. I think v15 is solving the problem exist with v13 and performance
>> is significantly high compared to base, and relation size is also
>> s
* Tom Lane wrote:
Michael Paquier writes:
Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana.
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse&dt=2016-03-29%2000%3A42%3A08
The origin of the problem is that, which prevents all the subsequent
queries to fail:
On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote:
> pgbench: Support double constants and functions.
>
> The new functions are pi(), random(), random_exponential(),
> random_gaussian(), and sqrt(). I was worried that this would be
> slower than before, but, if anything, it actually turns out to
Hello, I found that COMPLETE_SCHEMA_QUERY doesn't complete
only-one-matching schema names.
=# alter foreign table
information_schema. pg_temp_1. pg_toast_temp_1.
pg_catalog. pg_toast.public.
=# alter foreign table i
or
=# alter foreign table pu
This makes mor
Hi
>>> Anyway this is certainly not committable as-is, so I'm setting it back
>>> to Waiting on Author. But the fact that both libpq and ecpg would need
>>> updates makes me question whether we can safely pretend that this isn't
>>> a protocol break.
>>>
>>>
>>>
>>
>>
>> In that case I humbly su
Hi
2016-03-29 0:26 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > [ copy-raw-format-20160227-03.patch ]
>
> I looked at this patch. I'm having a hard time accepting that it has
> a use-case large enough to justify it, and here's the reason: it's
> a protocol break. Conveniently omitting to u
Michael Paquier writes:
> Buildfarm-not-being-happy-status: woodloose, mastodon, thrips, jacana.
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=woodlouse&dt=2016-03-29%2000%3A42%3A08
> The origin of the problem is that, which prevents all the subsequent
> queries to fail:
> SET TimeZon
2016-03-29 5:12 GMT+02:00 Andrew Dunstan :
>
>
> On 03/28/2016 06:26 PM, Tom Lane wrote:
>
>> Pavel Stehule writes:
>>
>>> [ copy-raw-format-20160227-03.patch ]
>>>
>> I looked at this patch. I'm having a hard time accepting that it has
>> a use-case large enough to justify it, and here's the re
On Thu, Mar 10, 2016 at 6:54 PM, Peter Geoghegan wrote:
> I've used amcheck [2] to test this latest revision -- the tool ought
> to not see any problems with any index created with the patch applied.
> Reviewers might find it helpful to use amcheck, too. As 9.6 is
> stabilized, I anticipate that a
On Tue, Mar 22, 2016 at 10:57 AM, Peter Geoghegan wrote:
> That's right - I have a small number of feedback items to work
> through. I also determined myself that there could be a very low
> probability race condition when checking the key space across sibling
> pages, and will work to address tha
On 03/28/2016 06:26 PM, Tom Lane wrote:
Pavel Stehule writes:
[ copy-raw-format-20160227-03.patch ]
I looked at this patch. I'm having a hard time accepting that it has
a use-case large enough to justify it, and here's the reason: it's
a protocol break. Conveniently omitting to update prot
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, March 29, 2016 10:54 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Petr Jelinek; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Reworks of Cus
On Mon, Mar 28, 2016 at 8:46 AM, Dilip Kumar wrote:
> Found one problem with V15, so sending the new version.
> In V15 I am taking prev_blkno as targetBlock instead it should be the last
> block of the relation at that time. Attaching new patch.
BlockNumber targetBlock,
-othe
On Sun, Mar 27, 2016 at 9:51 PM, Dilip Kumar wrote:
> I think this is better option, Since we will search last two pages of FSM
> tree, then no need to update the upper level of the FSM tree. Right ?
Well, it's less important in that case, but I think it's still worth
doing. Some people are goin
On Mon, Mar 28, 2016 at 9:36 PM, Kouhei Kaigai wrote:
> I don't have a strong reason to keep these stuff in separate files.
> Both stuffs covers similar features and amount of code are enough small.
> So, the attached v4 just merged custom-node.[ch] stuff into extensible.
>
> Once we put similar r
On Thu, Mar 17, 2016 at 2:26 AM, Ashutosh Bapat
wrote:
> On Wed, Mar 16, 2016 at 10:22 PM, Tom Lane wrote:
>> Robert Haas writes:
>> > On Wed, Mar 16, 2016 at 4:10 AM, Ashutosh Bapat <
>> > ashutosh.ba...@enterprisedb.com> wrote:
>> >> In 9.5, postgres_fdw allowed to prepare statements involving
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: Friday, March 25, 2016 12:27 AM
> To: Petr Jelinek
> Cc: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Reworks of Cust
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote:
> > On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote:
> >> v40 is yet another rebase.
> >
> > Thanks. Committed after removing an unnecessary parameter from the
> > coerceToXXX() functi
On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote:
> On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote:
>> v40 is yet another rebase.
>
> Thanks. Committed after removing an unnecessary parameter from the
> coerceToXXX() functions.
>
> I guess the question here is whether we want the part-c
On Tue, Mar 29, 2016 at 10:06 AM, Robert Haas wrote:
> On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier
> wrote:
>> On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
>>> OK, sounds good.
>>
>> Just a side-note. Andres has pushed the fix for the GinIs* macros as
>> af4472bc, making patch 00
On Tue, Mar 29, 2016 at 6:19 AM, Tom Lane wrote:
> Sync tzload() and tzparse() APIs with IANA release tzcode2016c.
>
> This brings us a bit closer to matching upstream, but since it affects
> files outside src/timezone/, we might choose not to back-patch it.
> Hence keep it separate from the main
On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier
wrote:
> On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote:
>> OK, sounds good.
>
> Just a side-note. Andres has pushed the fix for the GinIs* macros as
> af4472bc, making patch 0003 from the last series useless now.
I'm not prepared to get v
On Sat, Mar 26, 2016 at 4:21 PM, Thomas Munro
wrote:
> Here are a couple of patches to fix a typo in a comment in latch.c:
>
> - * The memory barrier has be to be placed here to ensure that any flag
> + * The memory barrier has to be placed here to ensure that any flag
Committed, but it hardly se
On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote:
> v40 is yet another rebase.
Thanks. Committed after removing an unnecessary parameter from the
coerceToXXX() functions.
I guess the question here is whether we want the part-c patch, which
removes the historical \setrandom syntax. That's t
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Saturday, March 19, 2016 8:57 AM
> To: Tom Lane
> Cc: Robert Haas; Petr Jelinek; David Rowley; pgsql-hackers@postgresql.org
> Subject: Re: [HACKER
On Tue, Mar 29, 2016 at 2:45 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera
>> wrote:
>> > Seems reasonable. For the last hunk in your patch, though, I would add
>> > a /* translator: */ comment explaining what each of the values is;
>> > o
Craig Ringer wrote:
> I found a minor issue with the new psql method while writing tests for
> failover slots. Patch attached.
Thanks, pushed.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
Michael McConville wrote:
> The below diff fixes one problem: you can't compare pthread_t values
> directly. Only the function pthread_equal(3) is defined. Direct
> comparison usually works because most implementations define pthread_t
> as an integer type.
So is there a platform where this assump
The below diff fixes one problem: you can't compare pthread_t values
directly. Only the function pthread_equal(3) is defined. Direct
comparison usually works because most implementations define pthread_t
as an integer type.
Relatedly, INVALID_THREAD is defined as (pthread_t)0. I don't think this
i
The C implementation is simple, the problem is with the makefile,
https://github.com/wulczer/first_last_agg/issues/2
*some clues?*
- - -
make
Makefile:25: /usr/lib/postgresql/9.5/lib/pgxs/src/makefiles/pgxs.mk:
No such file or directory
make: *** No rule to make target
`/usr/lib/postgresq
Pavel Stehule writes:
> [ copy-raw-format-20160227-03.patch ]
I looked at this patch. I'm having a hard time accepting that it has
a use-case large enough to justify it, and here's the reason: it's
a protocol break. Conveniently omitting to update protocol.sgml
doesn't make it not a protocol br
Petr Jediný wrote:
> Comments? This is my first patch to postgresql project, so comments
> are very much welcomed.
I think it's fine, so I pushed it. Thanks.
I hope you already read this
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
--
Álvaro Herrerahttp://
On 28/03/16 14:46, Dilip Kumar wrote:
Conclusion:
---
1. I think v15 is solving the problem exist with v13 and performance
is significantly high compared to base, and relation size is also
stable, So IMHO V15 is winner over other solution, what other thinks ?
I
On Mon, Mar 28, 2016 at 12:36 PM, Stephen Frost wrote:
> Having to figure out how each and every stdlib does versioning doesn't
> sound fun, I certainly agree with you there, but it hardly seems
> impossible. What we need, even if we look to move to ICU, is a place to
> remember that version info
While working on a tool to capture catalog/stats info and looking at
cross version compatibility, I noticed that the pg_am changes removed
SQL access to a bunch of AM info. [1] indicates that's part of the
purpose of the patch; are we sure no tools are using this info? Unlike
previous catalog c
* Peter Geoghegan (p...@heroku.com) wrote:
> On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote:
> > If we're going to talk about minimum requirements, I'd like to argue
> > that we require whatever system we're using to have versioning (which
> > glibc currently lacks, as I understand it...) to
On Thu, Mar 24, 2016 at 6:12 PM, Petr Jelinek wrote:
>
> Hi,
>
> I rebased this on top of the recently committed CREATE ACCESS METHOD.
>
Hi,
I got the above error trying to apply to the current master:
$ git apply /home/fabrizio/Downloads/0001-seqam-2016-03-24.patch
error: patch failed: src/bac
On Mon, Mar 28, 2016 at 7:57 AM, Stephen Frost wrote:
> If we're going to talk about minimum requirements, I'd like to argue
> that we require whatever system we're using to have versioning (which
> glibc currently lacks, as I understand it...) to avoid the risk that
> indexes will become corrupt
David Steele writes:
> On 3/10/16 11:00 AM, Petr Jelinek wrote:
>> The comment above errhidefromclient says "Only log levels below ERROR
>> can be hidden from the client." but use of the errhidefromclient(true)
>> actually does hide the error message from client, client just gets
>> failed query w
Michael Paquier wrote:
> On Wed, Mar 23, 2016 at 12:24 AM, Alvaro Herrera
> wrote:
> > Seems reasonable. For the last hunk in your patch, though, I would add
> > a /* translator: */ comment explaining what each of the values is;
> > otherwise it's just incomprehensible percent-sign-salad for the
On Thu, Mar 24, 2016 at 7:12 PM, Peter Geoghegan wrote:
> On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote:
>> I really like this idea, and the performance results seem impressive,
>> but I think we should push this out to 9.7. A btree patch that didn't
>> have WAL support until two and a half
Alexander Korotkov wrote:
> On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera
> wrote:
>
> > .. Oh crap. I just noticed I forgot to update a comment in pg_dump's
> > getAccessMethods. And we're missing psql tab-complete support for the
> > new commands.
>
> Attached patches fix both these issues
On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila
wrote:
>
> On Thu, Sep 3, 2015 at 5:11 PM, Andres Freund wrote:
> >
>
> Updated comments and the patch (increate_clog_bufs_v2.patch)
> containing the same is attached.
>
Andres mentioned to me in off-list discussion, that he thinks we should
first try
Comments? This is my first patch to postgresql project, so comments
are very much welcomed.
PJ
On Wed, Mar 23, 2016 at 8:40 PM, Petr Jediný wrote:
>>>
>>> Multicolumn BRIN is like GIN. Every column is indexed separately.
>>> The order of the columns doesn't matter.
>>
>> Right. You can use one
On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> I spent some time over the weekend trying out the different modes of
>> parallel query (seq scan, aggregate, join) in combination with PostGIS
>> and have written up the results he
Paul,
* Paul Ramsey (pram...@cleverelephant.ca) wrote:
> I spent some time over the weekend trying out the different modes of
> parallel query (seq scan, aggregate, join) in combination with PostGIS
> and have written up the results here:
>
> http://blog.cleverelephant.ca/2016/03/parallel-postgis
I spent some time over the weekend trying out the different modes of
parallel query (seq scan, aggregate, join) in combination with PostGIS
and have written up the results here:
http://blog.cleverelephant.ca/2016/03/parallel-postgis.html
The TL:DR; is basically
* With some adjustments to functio
On Mon, Mar 28, 2016 at 3:12 PM, Andres Freund wrote:
> On 2016-03-28 11:35:57 +0200, Magnus Hagander wrote:
> > On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> > wrote:
> >
> > > On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund
> wrote:
> > > > As pointed out in
Tomas Vondra wrote:
> I'm not sure about the prototypes though. It was a bit weird because
> prototypes in the same header file were formatted very differently.
Yeah, it is very odd. What happens is that the BSD indent binary does
one thing (return type is in one line and function name in follow
Andres Freund wrote:
> On 2016-03-28 15:46:43 +0300, Alexander Korotkov wrote:
> > @@ -932,8 +936,13 @@ ReadBuffer_common(SMgrRelation smgr, cha
> >
> > if (isLocalBuf)
> > {
> > - /* Only need to adjust flags */
> > - bufHdr->flags |= BM_VALID;
> > + /*
> >
On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane wrote:
> I'm also not exactly convinced by your implicit assumption that ICU is
> bug-free.
Noah spent some time looking at ICU back when he was EnterpriseDB, and
his conclusion was that ICU collations weren't stable across releases,
which is pretty much
All,
Changed the thread name (we're no longer talking about release
notes...).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Oleg Bartunov writes:
> > Should we start thinking about ICU ?
>
> Isn't it still true that ICU fails to meet our minimum requirements?
> That would include (a) working with t
25.03.2016 01:12, Peter Geoghegan:
On Thu, Mar 24, 2016 at 7:17 AM, Robert Haas wrote:
I really like this idea, and the performance results seem impressive,
but I think we should push this out to 9.7. A btree patch that didn't
have WAL support until two and a half weeks into the final CommitFe
Oleg Bartunov writes:
> Should we start thinking about ICU ?
Isn't it still true that ICU fails to meet our minimum requirements?
That would include (a) working with the full Unicode character range
(not only UTF16) and (b) working with non-Unicode encodings. No doubt
we could deal with (b) by i
Michael Paquier writes:
> While reading some code of pg_dump, I noticed that the following
> pattern is heavily present:
> lanname = pg_strdup(stuff)
> free(lanname);
> When pg_strdup or any pg-related allocation routines are called, I
> think that we should use pg_free() and not
On 2016-03-28 15:46:43 +0300, Alexander Korotkov wrote:
> diff --git a/src/backend/storage/buffer/bufmnew file mode 100644
> index 6dd7c6e..fe6fb9c
> --- a/src/backend/storage/buffer/bufmgr.c
> +++ b/src/backend/storage/buffer/bufmgr.c
> @@ -52,7 +52,6 @@
> #include "utils/resowner_private.h"
> #
21.03.2016 19:53, Anastasia Lubennikova:
19.03.2016 08:00, Peter Geoghegan:
On Fri, Mar 18, 2016 at 5:15 AM, David Steele
wrote:
It looks like this patch should be marked "needs review" and I have
done so.
Uh, no it shouldn't. I've posted an extensive review on the original
design thread. See
Hi all,
While reading some code of pg_dump, I noticed that the following
pattern is heavily present:
lanname = pg_strdup(stuff)
free(lanname);
One example is for example that:
lanname = get_language_name(fout, transforminfo[i].trflang);
if (typeInfo && lanname)
On Mon, Mar 28, 2016 at 10:08 PM, Thomas Munro
wrote:
> On Tue, Mar 29, 2016 at 1:56 AM, Thomas Munro
> wrote:
>> On Mon, Mar 28, 2016 at 8:54 PM, Michael Paquier
>> wrote:
>>> I have been also thinking a lot about this patch, and the fact that
>>> the WAL receiver latch is being used within the
On 2016-03-28 13:21:41 +0530, Pavan Deolasee wrote:
> On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier
> wrote:
>
> >
> >
> > I'd just add dots at the end of the sentences in the comment blocks
> > because that's project style, but I'm being picky, except that the
> > logic looks quite good.
> >
On 2016-03-28 11:35:57 +0200, Magnus Hagander wrote:
> On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier
> wrote:
>
> > On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund wrote:
> > > As pointed out in
> > >
> > http://www.postgresql.org/message-id/20160327232509.v5wgac5vskuse...@awork2.anarazel.de
>
On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote:
> On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote:
>
> >
> > What's sizeof(BufferDesc) after applying these patches? It should better
> > be <= 64...
> >
>
> It is 72.
Ah yes, miscalculated the required alignment. Hm. So we got to get this
sm
On Tue, Mar 29, 2016 at 1:56 AM, Thomas Munro
wrote:
> On Mon, Mar 28, 2016 at 8:54 PM, Michael Paquier
> wrote:
>> I have been also thinking a lot about this patch, and the fact that
>> the WAL receiver latch is being used within the internals of
>> libpqwalreceiver has been bugging me a lot, be
On Sun, Mar 27, 2016 at 4:31 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund wrote:
>
>> On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote:
>> > On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov <
>> > a.korot...@postgrespro.ru> w
On Mon, Mar 28, 2016 at 3:02 PM, Dilip Kumar wrote:
> 1. Relation Size : No change in size, its same as base and v13
>
> 2. INSERT 1028 Byte 1000 tuple performance
> ---
> Client base v13 v15
> 1 117 124 122
> 2 111 126 123
> 4 51 128 125
>
On 2016-03-28 11:33, Aleksander Alekseev wrote:
Hello, Piotr.
Thanks for report. But I'm having some difficulties reproducing issues
you described.
Oh, if you want backtraces then either set a conditional breakpoint or
add your own Assert like I did.
Also it would be a good idea to include
Hi, Petr!
On Thu, Mar 17, 2016 at 10:56 AM, Petr Jelinek wrote:
> On 16/03/16 15:31, Teodor Sigaev wrote:
>
>> Good catch, thanks! Tests were added.
>>>
>>
>> I don't see any objection, is consensus reached? I'm close to comiit
>> that...
>>
>>
> I did only cursory review on the bloom contrib mo
Hackers,
one our customer meet near xid wraparound situation. xid counter
reached xidStopLimit value. So, no transactions could be executed in
normal mode. But what I noticed is strange behaviour of autovacuum to
prevent wraparound. It vacuums tables, updates pg_class and pg_database,
but then
Oleg Bartunov-2 wrote
> But still, icu provides us abbreviated keys and collation stability,
Does include ICU mean that collation handling is identical across platforms?
E.g. a query on Linux involving string comparison would yield the same
result on MacOS and Windows?
If that is the case I'm al
On 2016/03/28 18:17, Rajkumar Raghuwanshi wrote:
I am testing postgres_fdw join pushdown feature for PostgreSQL 9.6 DB,
and I observed below issue._
Observation:_ Inner join and full outer join combination on a table
generating wrong result.
SELECT * FROM lt;
c1
1
2
(2 rows)
SELEC
Hi,
On 2016/03/25 23:49, Onder Kalaci wrote:
> Hi hackers,
>
> As it's documented in the source code, systable_beginscan() could be used
> to on non-system tables as well. My question is that, is it possible to
> write a C code with systable_beginscan(), systable_getnext() and ScanKeys
> which i
> I do not know whether this would be a meaningful improvement for
> common use-cases, though. (It'd help if people were more specific
> about the use-cases they need to work.)
For what its worth, in the company I am working for, InnoGames GmbH,
not being able to alter enums is the number one pai
On Mon, Mar 28, 2016 at 5:50 PM, Kyotaro HORIGUCHI
wrote:
> Thank you for the new patch. Sorry to have overlooked some
> versions. I'm looking the v19 patch now.
>
> make complains for an unused variable.
>
> | syncrep.c: In function ‘SyncRepGetSyncStandbys’:
> | syncrep.c:601:13: warning: variab
On Mon, Mar 28, 2016 at 3:11 AM, Michael Paquier
wrote:
> On Mon, Mar 28, 2016 at 8:30 AM, Andres Freund wrote:
> > As pointed out in
> >
> http://www.postgresql.org/message-id/20160327232509.v5wgac5vskuse...@awork2.anarazel.de
> > our backup tools (i.e. pg_basebackup, pg_dump[all]), currently d
Hello, Piotr.
Thanks for report. But I'm having some difficulties reproducing issues
you described.
I compiled PostgreSQL from master branch on FreeBSD 10.2 using this
command:
```
CC=/usr/local/bin/gcc49 CFLAGS="-O0 -g" \
./configure --enable-cassert --enable-debug \
--prefix=/home/eax/post
On Mon, Mar 28, 2016 at 7:21 AM, Dilip Kumar wrote:
> I agree with that conclusion. I'm not quite sure where that leaves
>> us, though. We can go back to v13, but why isn't that producing extra
>> pages? It seems like it should: whenever a bulk extend rolls over to
>> a new FSM page, concurren
On Mon, Mar 28, 2016 at 2:06 PM, Peter Geoghegan wrote:
> On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov
> wrote:
> > We'll post the patch.
>
> Cool.
>
> > Teodor made something to get abbreviated keys work as
> > I remember. I should say, that 27x improvement I got on my macbook. I
> will
> >
On 2016/03/28 17:50, Kyotaro HORIGUCHI wrote:
>
> # LISPers don't hesitate to dive into Sea of Parens.
Sorry in advance to be off-topic: https://xkcd.com/297 :)
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
Hi,
I am testing postgres_fdw join pushdown feature for PostgreSQL 9.6 DB, and
I observed below issue.
*Observation:* Inner join and full outer join combination on a table
generating wrong result.
SELECT * FROM lt;
c1
1
2
(2 rows)
SELECT * FROM ft;
c1
1
2
(2 rows)
\d+ ft
Hi!
On Sat, Mar 26, 2016 at 12:02 AM, David Steele wrote:
> On 3/25/16 3:54 PM, Artur Zakirov wrote:
> > On 25.03.2016 21:42, Dmitry Ivanov wrote:
> >> Sorry for the delay, I desperately needed some time to finish a bunch of
> >> dangling tasks.
> >>
> >> I've added some new comments and clarifi
Thank you for the new patch. Sorry to have overlooked some
versions. I'm looking the v19 patch now.
make complains for an unused variable.
| syncrep.c: In function ‘SyncRepGetSyncStandbys’:
| syncrep.c:601:13: warning: variable ‘next’ set but not used
[-Wunused-but-set-variable]
|ListCell *
On 03/26/2016 08:09 PM, Alvaro Herrera wrote:
Tomas Vondra wrote:
There are a few places where I reverted the pgindent formatting, because it
seemed a bit too weird - the first one are the lists of function prototypes
in common.h/mvstat.h, the second one are function calls to
_greedy/_exhaustiv
Hi,
On 03/26/2016 10:18 AM, Tatsuo Ishii wrote:
Fair point. Attached is v18 of the patch, after pgindent cleanup.
Here are some feedbacks to v18 patch.
1) regarding examples in create_statistics manual
Here are numbers I got. "with statistics" referrers to the case where
multivariate statist
On Mon, Mar 28, 2016 at 12:55 AM, Oleg Bartunov wrote:
> We'll post the patch.
Cool.
> Teodor made something to get abbreviated keys work as
> I remember. I should say, that 27x improvement I got on my macbook. I will
> check on linux.
I think that Linux will be much faster. The stxfrm() blob
On Mon, Mar 28, 2016 at 1:21 PM, Peter Geoghegan wrote:
> On Mon, Mar 28, 2016 at 12:08 AM, Oleg Bartunov
> wrote:
> > Should we start thinking about ICU ? I compare Postgres with ICU and
> without
> > and found 27x improvement in btree index creation for russian strings.
> This
> > includes eff
On Sun, Mar 27, 2016 at 7:30 AM, Thomas Munro
wrote:
> On Sat, Mar 26, 2016 at 2:48 AM, Michael Paquier
> wrote:
>> Should we worried about potential backward-incompatibilities with the
>> new return values of walrcv_receive?
>
> There are three changes to the walrcv_receive interface:
>
> 1. It
On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier
wrote:
>
>
> I'd just add dots at the end of the sentences in the comment blocks
> because that's project style, but I'm being picky, except that the
> logic looks quite good.
>
Since this is a bug affecting all stable branches, IMHO it will be a
Remove pgbench clientDone unused "ok" parameter.
I cannot get the point of keeping a useless parameter, which is probably
there because at some point in the past it was used. If it is needed some
day it can always be reinserted.
--
Fabien.diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbe
This minor patch shows the expected drawing percent in multi-script
reports, next to the relative weight.
--
Fabiendiff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 4196b0e..3b63d69 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -3080,10 +3080,
- that it does work:-) I'm not sure what happens by the script selection
process, it should be checked carefully because it was not designed
with allowing a zero weight, and it may depend on its/their positions.
It may already work, but it really needs checking.
Hmmm, it seems ok.
Attac
1 - 100 of 103 matches
Mail list logo
