On Mon, Feb 13, 2017 at 4:25 AM, Jim Nasby wrote:
> On 2/1/17 10:39 PM, Michael Paquier wrote:
>
>> On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila
>> wrote:
>>
>>> Many thanks to you for running the show. I think it might be okay if
>>> one consolidated mail is sent for all the patches that are ma
On Mon, Feb 13, 2017 at 3:29 AM, Jim Nasby wrote:
> On 2/11/17 4:36 AM, Michael Banck wrote:
>
>> I guess you're right, I've moved it further down. There is in fact a
>> message about the xlog location (unless you switch off wal entirely),
>> but having another one right before that mentioning th
On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby wrote:
> On 2/10/17 2:24 PM, Andrew Dunstan wrote:
>
>> There's a bunch of these things in /contrib which really ought to be
>>> PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
>>> steps in that would be getting the mainstream plat
2017-02-12 20:55 GMT+03:00 Vladimir Rusinov :
> Overall, when things go wrong debugging cmake requires cmake knowledge,
> while autotools mostly require shell knowledge which is much more common
> (again, for sysadmins/packagers).
It's not really true because of CMake scripts much easier than to
Sorry for delay in the review.
I started reviewing the patch again. Patch applied cleanly on latest source
as well as regression pass through with the patch. I also performed
few manual testing and haven't found any regression. Patch look
much cleaner the earlier version, and don't have any major
On 2017/02/13 16:39, Ashutosh Bapat wrote:
> Hi
> Bulletted list in Devel branch are all showing up bold as seen in the
> screenshot of [1] attached. But the same page for 9.6 branch shows
> normal bulletted lists. If I try to bulid docs from the latest
> resources (at commit ae0e550ce1703621efb3b7
Hi,
Am Montag, den 13.02.2017, 09:31 +0100 schrieb Magnus Hagander:
> On Mon, Feb 13, 2017 at 3:29 AM, Jim Nasby
> wrote:
> On 2/11/17 4:36 AM, Michael Banck wrote:
> I guess you're right, I've moved it further down.
> There is in fact a
> m
On 2017-02-09 02:25, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME-suppo
Hi all guys,
I have a database named edb. In this db , I have lots of schemas. Here I use
two schemas: a and b. The two schemas belong to different role.
Now , I want to export all objects of schema a . And then using these export
file to recover schema b. The user of the schema b can use the schem
On Thu, Feb 2, 2017 at 4:57 PM, Rafia Sabih
wrote:
> On Thu, Feb 2, 2017 at 1:19 AM, Thomas Munro
> wrote:
>> On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih
>> wrote:
>>> [ regressions ]
>>
>> Thanks Rafia. At first glance this plan is using the Parallel Shared
>> Hash in one place where it should
On 2017/02/13 14:21, Amit Langote wrote:
> On 2017/02/10 19:19, Simon Riggs wrote:
>> * The OID inheritance needs work - you shouldn't need to specify a
>> partition needs OIDS if the parent has it already.
>
> That sounds right. It's better to keep the behavior same as for regular
> inheritance.
Hi hackers,
I wonder why SUM aggregate is calculated for real (float4) type using
floating point accumulator?
It cause very confusing and unexpected behavior:
-- postgres=# select sum(l_quantity) from lineitem where l_shipdate <=
'1998-12-01';
sum
-
1.52688e+09
(1 row)
pos
Hello.
While playing with logical publications/subscriptions I’ve noted that walsender
crashes
when i’m trying to CREATE SUBSCRIPTION to a current server.
So having one running postgres instance on a standard port:
stas=# CREATE SUBSCRIPTION mysub CONNECTION 'dbname=stas host=127.0.0.1'
PUBLIC
Maybe this can be a discussed in a follow-up patch and Corey should
proceed to finalize the if patch?
In the event that we can leave prompting to a later patch, here are the v12
highlights:
My 0.02€ about v12: Patch applies, make check ok, psql make check ok.
- created conditional.h and c
Currently, an update of a partition key of a partition is not allowed,
since it requires to move the row(s) into the applicable partition.
Attached is a WIP patch (update-partition-key.patch) that removes this
restriction. When an UPDATE causes the row of a partition to violate
its partition const
On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote:
Why can't we rely on _bt_walk_left?
>>> The reason is mentioned in comments, but let me try to explain with
>>> some example. When you reach that point of code, it means that either
>>> the current page (assume page number is 10) doesn't co
Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra:
> Comparing averages of tps, measured on 5 runs (each 5 minutes long),
> the
> difference between master and patched master is usually within 2%,
> which
> is pretty much within noise.
>
> I'm attaching spreadsheets with summary of th
On Sat, Feb 11, 2017 at 1:41 AM, Dilip Kumar wrote:
> I tried my best, please check the latest patch (0001).
I don't think it's acceptable (or necessary) to move the DSA
definitions into postgres.h. Why do you think you need to do that,
vs. just including dsa.h in a few more places?
--
Robert
On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby wrote:
> On 2/7/17 9:16 AM, Daniele Varrazzo wrote:
>>
>> Thank you for the clarification: I will assume the behaviour cannot be
>> maintained on PG 10 and think whether the treatment of '{}' is too
>> magical and drop it instead.
>
>
> BTW, I would hope
On Mon, Feb 6, 2017 at 11:06 AM, Amit Khandekar wrote:
> Ashutosh Bapat wrote:
>>> We may want to think about a third goal: preventing too many workers
>>> from executing the same plan. As per comment in get_parallel_divisor()
>>> we do not see any benefit if more than 4 workers execute the same
On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas wrote:
> I don't think it's acceptable (or necessary) to move the DSA
> definitions into postgres.h. Why do you think you need to do that,
> vs. just including dsa.h in a few more places?
I need to access dsa_pointer in tidbitmap.h, which is included
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
0004-Add-RENAME-suppo
On Mon, Feb 13, 2017 at 3:34 PM, Bernd Helmle wrote:
> Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra:
> > Comparing averages of tps, measured on 5 runs (each 5 minutes long),
> > the
> > difference between master and patched master is usually within 2%,
> > which
> > is pretty much
Hello hackers,
There were many discussions concerning possible ways of speeding-up
Postgres. Different approaches were suggested:
- JIT (now we have three different prototype implementations based on LLVM)
- Chunked (vectorized) executor
- Replacing pull with push
- Columnar store (cstore_fdw
Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov:
> Thus, I see reasons why in your tests absolute results are lower than
> in my
> previous tests.
> 1. You use 28 physical cores while I was using 32 physical cores.
> 2. You run tests in PowerVM while I was running test on bare
On 2/9/17 7:15 PM, Jim Nasby wrote:
> Can you run a trace to see where all the time is going in the single row
> case? I don't see an obvious time-suck with a quick look through the code.
> It'd be interesting to see how things change if you eliminate the filler
> column from the SELECT.
Traces
On Sat, Feb 11, 2017 at 9:56 AM, Andrea Urbani wrote:
> I'm a beginner here... anyway I try to share my ideas.
>
> My situation is changed in a worst state: I'm no more able to make a pg_dump
> neither with my custom fetch value (I have tried "1" as value = one row at
> the time) neither without
On 2/8/17 4:44 PM, Andres Freund wrote:
>> Well, I find it a bit scary. If you do the big switch all at once, then
>> you will have to dedicate the following 3 months to fixing complaints
>> from developers and build farmers.
>
> That'll be the case just as well if we spread it out over two cycle
Alexander Korotkov wrote:
> Yes, influence seems to be low. But nevertheless it's important to insure
> that there is no regression here.
> Despite pg_prewarm'ing and running tests 300s, there is still significant
> variation.
> For instance, with clients count = 80:
> * pgxact-result-2.txt – 47
On Fri, Feb 10, 2017 at 1:41 PM, Robert Haas wrote:
> Anyway, it seems like the consensus here is unanimous. Unless there
> are a LARGE number of contrary votes in the meanwhile, I'll go make
> this happen sometime next week.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The E
Hi,
I wonder if it is possible to somehow benchmark your clustered index
implementation.
I tried to create VCI index for lineitem table from TPC and run Q6 query.
After index creation Postgres is not using parallel execution plan any
more but speed of sequential plan is not changed
and nothin
On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada wrote:
> On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek
> wrote:
>> On 10/02/17 19:55, Masahiko Sawada wrote:
>>> On Thu, Feb 9, 2017 at 12:44 AM, Petr Jelinek
>>> wrote:
On 08/02/17 07:40, Masahiko Sawada wrote:
> On Wed, Feb 8, 2017 at 9
Am Montag, den 13.02.2017, 16:55 +0300 schrieb Alexander Korotkov:
>
> Thank you for testing.
>
> Yes, influence seems to be low. But nevertheless it's important to
> insure
> that there is no regression here.
> Despite pg_prewarm'ing and running tests 300s, there is still
> significant
> variat
Konstantin Knizhnik writes:
> I wonder why SUM aggregate is calculated for real (float4) type using
> floating point accumulator?
If you can't deal with the vagaries of floating-point arithmetic, you
shouldn't be storing your data in float format. Use numeric.
> Are there are reasons of using
>
> ISTM that it is kind of a regression, because logically this is about the
> scan state so it should be in the corresponding structure, and having two
> structures to pass the scan state is not an improvement...
I wasn't too happy with the extra param, either. Having moved the guts to
conditio
On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO wrote:
>> Ok, so that's not just PROMPT_READY, that's every prompt...which might be
>> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd
>> level always being '.'?
>
> Yep. The idea is to keep it short, but to still have somethi
On Thu, Feb 9, 2017 at 8:15 PM, Peter Geoghegan wrote:
> BTW, aren't there cases where a PARALLEL SAFE function that needs to
> acquire locks on some arbitrary relation not referenced in the query
> can get locks on its own, which may only last as long as the parallel
> worker's lifetime? This cou
On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote:
> I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
> MAPPING statements
> for one of our customers.
> I think other users can also find it useful for scripting and
> automated tasks.
> The patches themselves are small and si
On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote:
> Remove all references to "xlog" from SQL-callable functions in pg_proc.
>
> Commit f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e renamed the pg_xlog
> directory to pg_wal. To make things consistent, and because "xlog" is
> terrible terminology for
On 13.02.2017 19:20, Tom Lane wrote:
Konstantin Knizhnik writes:
I wonder why SUM aggregate is calculated for real (float4) type using
floating point accumulator?
If you can't deal with the vagaries of floating-point arithmetic, you
shouldn't be storing your data in float format. Use numeri
On Thu, Feb 9, 2017 at 5:32 PM, Andres Freund wrote:
>> > Again, some parts of the code doing something bad isn't a good argument
>> > for doing again. Releasing locks early is a bad pattern, because backend
>> > code isn't generally safe against it, we have special code-paths for
>> > catalog tab
Hi All,
I too have performed benchmarking of this patch on a large machine
(with 128 CPU(s), 520GB RAM, intel x86-64 architecture) and would like
to share my observations for the same (Please note that, as I had to
reverify readings on few client counts, it did take some time for me
to share these
On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan wrote:
> On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund wrote:
>> Except that the proposed names aren't remotely like that... ;).
>
> Revision attached -- V5. We now REVOKE ALL on both functions, as
> Robert suggested, instead of the previous approa
On Fri, Feb 10, 2017 at 1:52 PM, Michael Paquier
wrote:
> On Tue, Feb 7, 2017 at 6:35 AM, Peter Eisentraut
> wrote:
>> On 2/6/17 10:54 AM, Fujii Masao wrote:
>>> Yes, that's an option. And, if we add dbid to pg_stat_subscription,
>>> I'm tempted to add all the pg_subscription's columns except sub
On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote:
> On 2/10/17 2:33 PM, Robert Haas wrote:
>> That having been said, I think it could certainly be useful to have
>> more control over what DDL gets logged in foreground processes.
>
> FWIW, this is a significant problem outside of DDL. Once you're p
On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote:
> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote:
>> Remove all references to "xlog" from SQL-callable functions in pg_proc.
>>
>> Commit f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e renamed the pg_xlog
>> directory to pg_wal. To make things c
On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote:
> According to the documentation for COPY IN mode, "If the COPY command
> was issued via an extended-query message, the backend will now discard
> frontend messages until a Sync message is received, then it will issue
> ReadyForQuery and return t
On Tue, Feb 14, 2017 at 2:06 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote:
>> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote:
>>> Remove all references to "xlog" from SQL-callable functions in pg_proc.
>>>
>>> Commit f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e re
On Mon, Feb 13, 2017 at 11:26 AM, Corey Huinker
wrote:
> ISTM that it is kind of a regression, because logically this is about the
>> scan state so it should be in the corresponding structure, and having two
>> structures to pass the scan state is not an improvement...
>
>
> I wasn't too happy wi
On Mon, Feb 13, 2017 at 10:52 AM, Peter Eisentraut
wrote:
> People have all kinds of expectations on how the build system behaves.
> It's not just ./configure; make; make install. All kinds of niche and
> edge cases have evolved over the years. Variables you can set,
> overrides, targets in some
On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote:
> Note that these views have not been consistently maintained and have
> ended up including some role attributes from recent versions
That's not a bug. According to the documentation, these views exist
for compatibility with PostgreSQL version
On 02/13/2017 03:16 PM, Bernd Helmle wrote:
Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov:
Thus, I see reasons why in your tests absolute results are lower than
in my
previous tests.
1. You use 28 physical cores while I was using 32 physical cores.
2. You run tests in Powe
>
> I wasn't too happy with the extra param, either. Having moved the guts to
>> conditional.c, I'm happy with that change and can move the stack head back
>> to scan_state with a clear conscience.
>>
>
>
That effort was creating as many headaches as it solved. Rolled back v12
except for doc paragr
On 02/13/2017 11:00 AM, Robert Haas wrote:
> My big objection to removing these views is that it will break pgAdmin
> 3, which uses all three of these views. I understand that the pgAdmin
> community is now moving away from pgAdmin 3 and toward pgAdmin 4, but
> I bet that pgAdmin 3 still has signi
Robert Haas wrote:
> My big objection to removing these views is that it will break pgAdmin
> 3, which uses all three of these views. I understand that the pgAdmin
> community is now moving away from pgAdmin 3 and toward pgAdmin 4, but
> I bet that pgAdmin 3 still has significant usage and will c
Hi
2017-02-13 6:46 GMT+01:00 Michael Paquier :
> On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule
> wrote:
> > here is new update - check is done before any creating
>
> It may be better to do any checks before dropping existing databases
> as well... It would be as well just simpler to complain w
Hello Corey,
That effort was creating as many headaches as it solved. Rolled back v12
except for doc paragraph, added more descriptive tap test names. Enjoy.
The TAP tests are missing from the patch, not sure why...
The stack cleanup is nicer with pop calls.
Two debatable suggestions about
On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> My big objection to removing these views is that it will break pgAdmin
>> 3, which uses all three of these views. I understand that the pgAdmin
>> community is now moving away from pgAdmin 3 and toward pgAdmin 4, but
>
On Mon, Feb 13, 2017 at 3:04 PM, Fabien COELHO wrote:
>
> Hello Corey,
>
> That effort was creating as many headaches as it solved. Rolled back v12
>> except for doc paragraph, added more descriptive tap test names. Enjoy.
>>
>
> The TAP tests are missing from the patch, not sure why...
>
I went
On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
wrote:
> Tomas Vondra pointed out to me that there's an error in parallel.sgml
> which confuses the inner and outer sides of the join.
>
> I've attached a patch which fixes this, although I think I'm still
> missing the point to text's explanation of w
On 14 February 2017 at 09:21, Robert Haas wrote:
> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
> -table. Each worker will execute the outer side of the plan in full, which
> -is why merge joins are not supported here. The outer side of a merge join
> -will often involve sorting the e
On Mon, Feb 13, 2017 at 3:29 PM, David Rowley
wrote:
> On 14 February 2017 at 09:21, Robert Haas wrote:
>> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
>> -table. Each worker will execute the outer side of the plan in full,
>> which
>> -is why merge joins are not supported here. The out
Hello Robert,
[...] I think we should try to make this REALLY simple. We don't really
want to have everybody have to change their PROMPT1 and PROMPT2 strings
for this one feature.
Ok. I think that we agree that the stack was too much details.
How about just introducing a new value for %R?
On Mon, Feb 13, 2017 at 11:29 AM, Robert Haas wrote:
> possible states here. Just when you've figured out what tfzffft
I agree with what you've said, but wanted to point out that any condition
that follows a 'z' would itself be 'z'. Not that tfz is much better.
Hello Corey,
I went back to master and re-applied v11, something must have gotten lost
in translation.
Probably you need "git add" for added files?
About v14: patch applies, make check ok, psql tap tests ok.
All seems fine to me. Test coverage is better than a lot of other
features. Code &
On Mon, Feb 13, 2017 at 8:46 AM, Kyle Gearhart
wrote:
> On 2/9/17 7:15 PM, Jim Nasby wrote:
>> Can you run a trace to see where all the time is going in the single row
>> case? I don't see an obvious time-suck with a quick look through the code.
>> It'd be interesting to see how things change if
Robert Haas wrote:
> +COUNT(*), each worker must compute subtotals which later must
> +be combined to produce an overall total in order to produce the final
> +answer. If the query involves a GROUP BY clause,
> +separate subtotals must be computed for each group seen by each paral
On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote:
>
> Hello Robert,
>
> [...] I think we should try to make this REALLY simple. We don't really
>> want to have everybody have to change their PROMPT1 and PROMPT2 strings for
>> this one feature.
>>
>
> Ok. I think that we agree that the stack
On 14 Feb. 2017 06:15, "Robert Haas" wrote:
On Mon, Jan 23, 2017 at 9:12 PM, Robert Haas wrote:
> According to the documentation for COPY IN mode, "If the COPY command
> was issued via an extended-query message, the backend will now discard
> frontend messages until a Sync message is received, t
On 14 February 2017 at 10:10, Brad DeJong wrote:
> Robert Haas wrote:
>
>> +COUNT(*), each worker must compute subtotals which later
>> must
>> +be combined to produce an overall total in order to produce the final
>> +answer. If the query involves a GROUP BY clause,
>> +separate
David Rowley wrote:
> I propose we just remove the whole paragraph, and mention about
> the planning and estimated number of groups stuff in another new paragraph.
>
> I've attached a patch to this effect ...
s/In a worse case scenario/In the worst case scenario,/
Other than that, the phrasing i
On Tue, Feb 14, 2017 at 2:31 AM, Fujii Masao wrote:
> On Tue, Feb 14, 2017 at 2:06 AM, Robert Haas wrote:
>> On Mon, Feb 13, 2017 at 11:43 AM, Fujii Masao wrote:
>>> On Fri, Feb 10, 2017 at 5:36 AM, Robert Haas wrote:
Remove all references to "xlog" from SQL-callable functions in pg_proc.
On 14 February 2017 at 10:56, Brad DeJong wrote:
> David Rowley wrote:
>> I propose we just remove the whole paragraph, and mention about
>> the planning and estimated number of groups stuff in another new paragraph.
>>
>> I've attached a patch to this effect ...
>
> s/In a worse case scenario/In
On Thu, Feb 9, 2017 at 2:03 AM, Ashutosh Bapat
wrote:
>>
>> 0004-hj-refactor-batch-increases-v4.patch:
>>
>> Modify the existing hash join code to detect work_mem exhaustion at
>> the point where chunks are allocated, instead of checking after every
>> tuple insertion. This matches the logic used
On 13 February 2017 at 17:12, Robert Haas wrote:
> On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote:
>> On 2/10/17 2:33 PM, Robert Haas wrote:
>>> That having been said, I think it could certainly be useful to have
>>> more control over what DDL gets logged in foreground processes.
>>
>> FWIW, th
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote:
> > Note that these views have not been consistently maintained and have
> > ended up including some role attributes from recent versions
>
> That's not a bug. According to the documentation, thes
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera
> wrote:
> > Well, we can remove them from PG10 and pgAdmin3 (and others) be adjusted
> > to use the new ones, conditionally on server version. Surely pgAdmin3
> > is going to receive further u
Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to
be able to do something like WHEN tag LIKE 'ALTER%'.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.c
On Mon, Feb 13, 2017 Merlin Moncure wrote:
>A barebones callback mode ISTM is a complete departure from the classic
>PGresult interface. This code is pretty unpleasant IMO:
acct->abalance = *((int*)PQgetvalue(res, 0, i)); abalance =
acct->__bswap_32(acct->abalance);
> Your code is faster but fo
Upgrading from 9.6 to dev, I now get:
$ rm bisectdata -r ; bisect/bin/pg_ctl initdb -D bisectdata;
bisect/bin/pg_upgrade -b /usr/local/pgsql9_6/bin/ -B bisect/bin/ -d 96 -D
bisectdata/
check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or
directory
This looks somewhat complica
Hi all,
Beginning a new thread to raise awareness... As already reported here,
I had a look at what has been committed in a507b869:
https://www.postgresql.org/message-id/CAB7nPqRzCQb=vdfhvmtp0hmlbhu6z1agdo4gjsup-hp8jx+...@mail.gmail.com
Here are a couple of things I have noticed while looking at
On Tue, Feb 14, 2017 at 12:48 AM, Dilip Kumar wrote:
> On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas
> wrote:
> > I don't think it's acceptable (or necessary) to move the DSA
> > definitions into postgres.h. Why do you think you need to do that,
> > vs. just including dsa.h in a few more places?
On Tue, Feb 14, 2017 at 2:57 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> Hi,
>
> I wonder if it is possible to somehow benchmark your clustered index
> implementation.
> I tried to create VCI index for lineitem table from TPC and run Q6 query.
> After index creation Postgres is n
On Mon, Feb 13, 2017 at 5:47 PM, Robert Haas wrote:
> On Sat, Feb 11, 2017 at 6:35 PM, Amit Kapila wrote:
> Why can't we rely on _bt_walk_left?
The reason is mentioned in comments, but let me try to explain with
some example. When you reach that point of code, it means that either
On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes wrote:
> check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or
> directory
>
> This looks somewhat complicated to fix. Should check_bin_dir test the old
> cluster version, and make a deterministic check based on that? Or just
> check
Hi,
On 2017-02-11 14:40:18 +0100, Tomas Vondra wrote:
> On 02/11/2017 02:33 AM, Andres Freund wrote:
> > > I have a hard time believing this the cache efficiency of linked lists
> > > (which may or may not be real in this case) out-weights this, but if you
> > > want to try, be my guest.
> >
> >
At Sat, 4 Feb 2017 21:27:32 +0100, Petr Jelinek
wrote in
> Hmm I wonder if we should just make the subscriber send the
> client_encoding always (based on server encoding of the subscriber).
> That should solve the issue in combination with your patch no?
Yeah, right. I considered that a subscri
On 02/13/2017 06:31 AM, Michael Paquier wrote:
- What should we do with REINDEX DATABASE CONCURRENTLY and the system
catalog? I so not think we can reindex the system catalog concurrently
safely, so what should REINDEX DATABASE do with the catalog indexes? Skip
them, reindex them while taking loc
On 2017-02-13 20:59:43 +0100, Pavel Stehule wrote:
> Hi
>
> 2017-02-13 6:46 GMT+01:00 Michael Paquier :
>
> > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule
> > wrote:
> > > here is new update - check is done before any creating
> >
> > It may be better to do any checks before dropping existing
On Tue, Feb 14, 2017 at 11:36 AM, Andres Freund wrote:
> On 2017-02-13 20:59:43 +0100, Pavel Stehule wrote:
>> Hi
>>
>> 2017-02-13 6:46 GMT+01:00 Michael Paquier :
>>
>> > On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule
>> > wrote:
>> > > here is new update - check is done before any creating
>> >
On 2017-02-14 11:46:52 +0900, Michael Paquier wrote:
> > I still fail to see why --use-existing as suggested in
> > https://www.postgresql.org/message-id/20170208002900.vkldujzfkwbvq...@alap3.anarazel.de
> > isn't sufficient.
>
> Some tests create objects without removing them, meaning that
> cont
Jim Nasby writes:
> Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to
> be able to do something like WHEN tag LIKE 'ALTER%'.
Seems like it would be a seriously bad idea for such an expression to be
able to invoke arbitrary SQL code. What if it calls a user-defined
function
On Tue, Feb 14, 2017 at 2:07 AM, Fujii Masao wrote:
> No, the tab-completions for ALTER/DROP PUBLICATION should show the local
> publications because those commands drop and alter the local ones. OTOH,
> CREATE/ALTER SUBSCRIPTOIN ... PUBLICATION should show nothing because
> the remote publication
Dilip complained on another thread about the apparent difficulty of
getting the system to compile after adding a reference to dsa_pointer
to tidbitmap.c:
https://www.postgresql.org/message-id/CAFiTN-u%3DBH_b0QE9FG%2B%2B_Ht6Q%3DF84am%3DJ-rt7fNbQkq3%2BqX3VQ%40mail.gmail.com
I dug into the problem a
On Mon, Feb 13, 2017 at 5:19 PM, Simon Riggs wrote:
> On 13 February 2017 at 17:12, Robert Haas wrote:
>> On Sun, Feb 12, 2017 at 9:20 PM, Jim Nasby wrote:
>>> On 2/10/17 2:33 PM, Robert Haas wrote:
That having been said, I think it could certainly be useful to have
more control over w
On Mon, Feb 13, 2017 at 8:48 AM, Dilip Kumar wrote:
> On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas wrote:
>> I don't think it's acceptable (or necessary) to move the DSA
>> definitions into postgres.h. Why do you think you need to do that,
>> vs. just including dsa.h in a few more places?
>
> I
On Mon, Feb 13, 2017 at 5:29 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote:
>> > Note that these views have not been consistently maintained and have
>> > ended up including some role attributes from recent versions
On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson wrote:
> On 02/13/2017 06:31 AM, Michael Paquier wrote:
>> Er, something like that as well, no?
>> DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
>
> REINDEX (VERBOSE) currently prints one such line per index, which does not
> really
On Mon, Feb 13, 2017 at 5:38 PM, Stephen Frost wrote:
> I really do not think the PG core project should be held hostage by an
> external and apparently not-really-maintained project. What if we
> introduce some other difference in PG10 that breaks pgAdmin3? Are we
> going to roll that change ba
On Thu, Feb 2, 2017 at 9:23 AM, Amit Kapila wrote:
> On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote:
>> On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote:
>>> Moved this patch to next CF.
>>
>> So here is what seems to be the key hunk from this patch:
>>
>> /*
>> - * Since we don't
1 - 100 of 114 matches
Mail list logo
