On Wed, Sep 07, 2016 at 05:14:44PM +0300, Aleksander Alekseev wrote:
> Here is another idea for a contribution - refactoring.
Refactoring is not a good early contribution. Refactoring is more likely to
succeed once you internalize community code practices through much study of
functional patches.
On 09/08/2016 03:36 AM, Peter Geoghegan wrote:
On Wed, Sep 7, 2016 at 2:42 PM, Tom Lane wrote:
The reason it's called siftup is that that's what Knuth calls it.
See Algorithm 5.2.3H (Heapsort), pp 146-147 in the first edition of
Volume 3; tuplesort_heap_siftup corresponds directly to steps H3-H
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro
> HORIGUCHI
>
> $ time psql postgres -c 'select t.a from t, generate_series(0, )' >
> /dev/null
>
> real 0m22.696s
> user 0m16.991s
> sys 0m0.182s>
>
> Using binsearch the result f
On 09/08/2016 09:39 AM, Михаил Бахтерев wrote:
Excuse me for intervention.
It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which
does not have sqrt support.
But you are right, it is supported in most cases. And if execution speed
of this very fuction is of concern, sqrtf(x) s
On 08/29/2016 03:34 AM, Vik Fearing wrote:
> We have sample configuration files for postgresql.conf and
> recovery.conf, but we do not have them for contrib modules. This patch
> attempts to add them.
>
> Although the patch puts the sample configuration files in the tree, it
> doesn't try to inst
On Wed, Sep 7, 2016 at 7:22 PM, Kuntal Ghosh wrote:
> Hello,
Could you avoid top-posting please? More reference here:
http://www.idallen.com/topposting.html
> - If WAL consistency check is enabled for a rmgrID, we always include
> the backup image in the WAL record.
What happens if wal_consiste
On Wed, Sep 7, 2016 at 4:11 PM, Simon Riggs wrote:
> On 7 September 2016 at 04:13, Masahiko Sawada wrote:
>
>> Since current HEAD could scan visibility map twice, the execution time
>> of Patched is approximately half of HEAD.
>
> Sounds good.
>
> To ensure we are doing exactly same amount of wor
On 7 September 2016 at 22:14, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > Here is version 6 of the patch, which just adds RENAME VALUE with no IF
> > [NOT] EXISTS, rebased onto current master (particularly the
> > transactional ADD VALUE patch).
>
>
>autoconf check for IEEE 754 floats
Autoconf man says folowing:
>it is safe to assume IEEE-754 in most portable code these days
https://www.gnu.org/software/autoconf/manual/autoconf.html#Floating-Point-Portability
> A union might be more readable
Here is union version of the patch. It's slower 10%
On Wed, Sep 7, 2016 at 2:39 AM, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 10:28 PM, Claudio Freire
> wrote:
>>> The problem with this is that we allocate the entire amount of
>>> maintenance_work_mem even when the number of actual dead tuples turns
>>> out to be very small. That's not so bad
On 8 Sep. 2016 1:38 pm, "Andres Freund" wrote:
>
> I kind of dislike this approach for a different reason than already
> mentioned in this thread: Namely it's not re-usable for implementing
> streaming logical replication of large transaction, i.e. allow to decode
> & apply un-committed changes.
On Wed, Sep 7, 2016 at 12:47 AM, Masahiko Sawada wrote:
> On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs wrote:
>> On 29 August 2016 at 14:52, Fujii Masao wrote:
>>> On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek wrote:
On 04/08/16 06:40, Masahiko Sawada wrote:
>
> On Wed, Aug 3, 2016
On 7 September 2016 at 14:58, Tom Lane wrote:
>> That may not be perceived as a "fix" by everybody, so we should not do
>> it without an explicit agreement by many.
>
> Agreed, but I vote with Fujii-san for back-patching.
No problem with backpatching, just wanted some +1s before I did it.
Will
On Wed, Sep 7, 2016 at 4:03 AM, Josh Berkus wrote:
> On 08/29/2016 06:52 AM, Fujii Masao wrote:
>> Also I like the following Simon's idea.
>>
>> https://www.postgresql.org/message-id/canp8+jlhfbvv_pw6grasnupw+bdk5dctu7gwpnap-+-zwvk...@mail.gmail.com
>> ---
>> * first k (n1, n2,
On 7 September 2016 at 15:44, Vladimir Gordiychuk wrote:
> Fixed patch in attach.
It'd helpful if you summarize the changes made when posting revisions.
>> * There are no tests. I don't see any really simple way to test this,
>> though.
>
> I will be grateful if you specify the best way how to
On Thu, Sep 8, 2016 at 12:13 PM, Michael Paquier
wrote:
> On Wed, Sep 7, 2016 at 10:48 PM, Stas Kelvich
> wrote:
> > Some time ago two-phase state file format was changed to have variable
> size GID,
> > but several places that read that files were not updated to use new
> offsets. Problem
> > e
> Given that you are now familiar with the internals of how enums are
> implemented would it be possible to continue the work and add the "ALTER
> TYPE DROP VALUE " command?
I was thinking to try developing it, but I would be more than happy to
help by testing and reviewing, if someone else would
On Thu, Sep 8, 2016 at 2:23 AM, Tom Lane wrote:
> I really don't like this solution. Changing this one function, out of the
> dozens just like it in lsyscache.c, seems utterly random and arbitrary.
>
> I'm actually not especially convinced that passing domain_in a random
> OID needs to not produc
On 8 September 2016 at 07:43, Michael Paquier wrote:
> On Wed, Sep 7, 2016 at 10:48 PM, Stas Kelvich
> wrote:
>> Some time ago two-phase state file format was changed to have variable size
>> GID,
>> but several places that read that files were not updated to use new offsets.
>> Problem
>> exi
On 2016/09/06 22:07, Ashutosh Bapat wrote:
On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/08/22 15:49, Ashutosh Bapat wrote:
1. deparsePlaceHolderVar looks odd - each of the deparse*
function is
named as deparse + .
On 2016/09/07 13:21, Ashutosh Bapat wrote:
* with the patch:
postgres=# explain verbose delete from ft1 using ft2 where ft1.a =
ft2.a;
QUERY PLAN
-
On 8 Sep. 2016 7:38 am, "Robins Tharakan" wrote:
>
> Hi,
>
> An SQL (with only information_schema related JOINS) when triggered, runs
with max CPU (and never ends - killed after 2 days).
> - It runs similarly (very slow) on a replicated server that acts as a
read-only slave.
> - Top shows only pos
On 4 Sep. 2016 3:36 am, "Tom Lane" wrote:
>
> After further thought I concluded that not providing any labeling of
> days is a bad idea.
Yeah. I think labeling days is definitely good. I'm glad you changed that.
Personally I'd like to trim milliseconds when dealing with minute+ long
runs and se
On Tue, 6 Sep 2016 07:58:28 +0530
Mithun Cy wrote:
> On Mon, Sep 5, 2016 at 4:33 PM, Aleksander Alekseev <
> a.aleks...@postgrespro.ru> wrote:
> >After a brief examination I've found following ways to improve the
> >patch.
> Adding to above comments.
>
I'm sending new version of patch.
I've r
Heikki Linnakangas writes:
> BTW, I would be OK with the bit-twiddling hack, if we had an autoconf
> check for IEEE 754 floats, and a graceful fallback for other systems.
I would still object to the version submitted, on the grounds of the
compiler warnings it causes. Possibly those could be a
2016-09-08 13:10 GMT+02:00 Craig Ringer :
> On 4 Sep. 2016 3:36 am, "Tom Lane" wrote:
> >
>
> > After further thought I concluded that not providing any labeling of
> > days is a bad idea.
>
> Yeah. I think labeling days is definitely good. I'm glad you changed that.
>
> Personally I'd like to tr
>BTW, would someone explain to me why using a float here will not fail
>catastrophically for inputs outside the range of float?
Indeed, it will. And that's one of the reason I'm considering
advancing GiST API instead of advancing extensions.
It won't crash, but will produce terrible index, not s
On Wed, Sep 7, 2016 at 10:14 AM, Aleksander Alekseev
wrote:
> Here is another idea for a contribution - refactoring.
>
> Currently there are a lot of procedures in PostgreSQL code that
> definitely don't fit on one screen (i.e. ~50 lines). Also many files are
> larger than say 1000 lines of code.
Michael Paquier writes:
> But I don't understand the reason behind such a restriction to be
> honest because libxml2 does not depend on libxslt. The contrary is
> true: libxslt needs libxml2.
Right.
> Note as well that libxml2 does depend on ICONV though.
Hm, is that true either? I don't see a
On Wed, Sep 7, 2016 at 10:34 AM, Yury Zhuravlev
wrote:
> Christian Convey wrote:
>>
>> Yury doesn't seem to need help
>> with CMake
>
> Hello.
> I am sorry that the only answer is now.
> I need help but with write CMake code:
> 1. Make ecpg tests
> 2. Make MinGW/Msys support
> 3. many many ...
On Wed, Sep 7, 2016 at 10:44 AM, Stas Kelvich wrote:
> There is also a list of projects for google summer of code:
> https://wiki.postgresql.org/wiki/GSoC_2016
>
> That topics expected to be doable by a newcomer during several months. It is
> also slightly
> outdated, but you always can check cu
Excuse me for intervention.
It depends. For instance, i run PostgreSQL on the modern MIPS CPU, which
does not have sqrt support.
But you are right, it is supported in most cases. And if execution speed
of this very fuction is of concern, sqrtf(x) should be used instead of
sqrt(x).
Despite this,
On Wed, Sep 7, 2016 at 3:58 PM, Amit Langote
wrote:
>
> Hi,
>
> On 2016/09/07 17:56, Rajkumar Raghuwanshi wrote:
> > Hi,
> >
> > I have a query regarding list partitioning,
> >
> > For example if I want to store employee data in a table, with "IT" dept
> > employee in emp_p1 partition, "HR" dept
On Thu, Sep 8, 2016 at 2:27 PM, Tom Lane wrote:
> Michael Paquier writes:
> > But I don't understand the reason behind such a restriction to be
> > honest because libxml2 does not depend on libxslt. The contrary is
> > true: libxslt needs libxml2.
>
> Right.
>
Pretty sure this goes back to *our
On Thu, Sep 8, 2016 at 9:27 PM, Tom Lane wrote:
> Michael Paquier writes:
>> But I don't understand the reason behind such a restriction to be
>> honest because libxml2 does not depend on libxslt. The contrary is
>> true: libxslt needs libxml2.
>
> Right.
>
>> Note as well that libxml2 does depen
Vik Fearing writes:
> I noticed that this patch has been marked Waiting on Author with no
> comment. Peter, what more should I be doing right now while waiting for
> MartÃn's review?
FWIW, I agree with the upthread misgivings about whether this is actually
a useful effort. Even if we installed
On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote:
> Pretty sure this goes back to *our* XML support requiring both. As in you
> couldn't turn on/off xslt independently, so the "xml requires xslt" comment
> is that *our* xml support required both.
>
> This may definitely not be true anymore, a
On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier
wrote:
> On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander
> wrote:
> > Pretty sure this goes back to *our* XML support requiring both. As in you
> > couldn't turn on/off xslt independently, so the "xml requires xslt"
> comment
> > is that *our* xml
Michael Paquier writes:
> On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote:
>> Pretty sure this goes back to *our* XML support requiring both. As in you
>> couldn't turn on/off xslt independently, so the "xml requires xslt" comment
>> is that *our* xml support required both.
>>
>> This may
Dilip Kumar writes:
> On Thu, Sep 8, 2016 at 2:23 AM, Tom Lane wrote:
>> In the case of record_in, it seems like it'd be easy enough to use
>> lookup_rowtype_tupdesc_noerror() instead of lookup_rowtype_tupdesc()
>> and then throw a user-facing error right there.
> Actually when we are passing in
Thank you for comments.
>But there's a function in startup.c which might be the ideal location
>or the check, as it looks like the one and only place where the
>autocommit flag actually changes:
>static void
>autocommit_hook(const char *newval)
Thank you for pointing out this. This indeed is the
On 9/8/16 3:03 AM, Masahiko Sawada wrote:
Current manual vacuum doesn't output how may all_frozen pages we
skipped according to visibility map.
That's why I attached 0001 patch which makes the manual vacuum emit
such information.
I think we should add that, and info about all-frozen skips, rega
On 9/8/16 3:48 AM, Masahiko Sawada wrote:
If we replaced dead_tuples with an array-of-array, isn't there
negative performance impact for lazy_tid_reap()?
As chunk is added, that performance would be decrease.
Yes, it certainly would, as you'd have to do 2 binary searches. I'm not
sure how much
Hello, Victor.
> I'm sending new version of patch.
>
> I've replaced readonly option with target_server_type (with JDBC
> compatibility alias targetServerType),
>
> use logic of setting defaults based on number of hosts in the connect
> string instead of complicated condition in the state machi
> Hello, Victor.
>
> > I'm sending new version of patch.
> >
> > I've replaced readonly option with target_server_type (with JDBC
> > compatibility alias targetServerType),
> >
> > use logic of setting defaults based on number of hosts in the connect
> > string instead of complicated condition
Hi,
On 07/09/16 14:10, Erik Rijkers wrote:
On 2016-08-31 22:51, Petr Jelinek wrote:
and one more version with bug fixes, improved code docs and couple
I am not able to get the replication to work. Would you (or anyone) be
so kind to point out what I am doing wrong?
Patches applied, compile
On Wed, Sep 7, 2016 at 10:18 PM, Claudio Freire
wrote:
> On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote:
> > On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs
> wrote:
> >> On 6 September 2016 at 19:59, Tom Lane wrote:
> >>
> >>> The idea of looking to the stats to *guess* about how many tuples a
On Thu, Sep 8, 2016 at 4:03 AM, Masahiko Sawada wrote:
> On Wed, Sep 7, 2016 at 4:11 PM, Simon Riggs wrote:
>> On 7 September 2016 at 04:13, Masahiko Sawada wrote:
>>
>>> Since current HEAD could scan visibility map twice, the execution time
>>> of Patched is approximately half of HEAD.
>>
>> So
On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee
wrote:
> For example, for a table with 60 bytes wide tuple (including 24 byte
> header), each page can approximately have 8192/60 = 136 tuples. Say we
> provision for 136*2 = 272 bits per page i.e. 34 bytes per page for the
> bitmap. First 272 offset
Peter Eisentraut writes:
> On 9/6/16 1:40 PM, Doug Doole wrote:
>> We carried the ICU version numbers around on our collation and locale
>> IDs (such as fr_FR%icu36) . The database would load multiple versions of
>> the ICU library so that something created with ICU 3.6 would always be
>> processe
On 8/15/16 7:33 AM, Andreas 'ads' Scherbaum wrote:
> postgres=# SELECT to_date('2011 12 18', ' MM DD');
>to_date
>
> 2011-12-08
> (1 row)
>
>
> That is from the regression tests, and obviously handles the date
> transformation wrong. My attempt catches this, because I c
On Thu, Sep 8, 2016 at 11:27 PM, Jim Nasby wrote:
> On 9/8/16 3:03 AM, Masahiko Sawada wrote:
>>
>> Current manual vacuum doesn't output how may all_frozen pages we
>> skipped according to visibility map.
>> That's why I attached 0001 patch which makes the manual vacuum emit
>> such information.
>
Craig Ringer wrote:
> Hi all
>
> Now that it's becoming more common to post patch series, not just
> standalone patches, it might be worth looking at how the CF app can
> help manage them.
>
> Any ideas?
I agree that we don't consider this case at all currently and that it's
causing some pain.
On Tue, Sep 6, 2016 at 8:28 PM, Peter Geoghegan wrote:
>> In the meanwhile, I'll go and do some perf testing.
>>
>> Assuming the speedup is realized during testing, LGTM.
>
> Thanks. I suggest spending at least as much time on unsympathetic
> cases (e.g., only 2 or 3 tapes must be merged). At the
I have updated the patch with additional tests and comments per your
review. Final(?) version attached.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From ee34d7d64a4b10c9f7fbe8c905a56cea1584c8c9 Mon Sep 17 00:0
On 9/6/16 1:08 PM, Tom Lane wrote:
>> As just mentioned elsewhere, this accidentally introduces a failure if
>> > the PostgreSQL installation path contains LF/CR, because of the use of
>> > appendShellString().
> I think that's intentional, not accidental. What actual use case is
> there for allow
On 9/6/16 1:42 PM, Robert Haas wrote:
> If we were talking about pathnames containing spaces, I would agree,
> but I've never heard of a legitimate pathname containing CR or LF. I
> can't see us losing much by refusing to allow such pathnames, except
> for security holes.
The flip side of that is
On 9/8/16 11:16 AM, Tom Lane wrote:
> This is a problem, if ICU won't guarantee cross-version compatibility,
> because it destroys the argument that moving to ICU would offer us
> collation behavior stability.
It would offer a significant upgrade over the current situation.
First, it offers stabi
Rahila Syed wrote:
> However, including the check here will require returning the status
> of command from this hook. i.e if we throw error inside this
> hook we will need to return false indicating the value has not changed.
Looking at the other variables hooks, they already emit errors
On 9/4/16 7:36 PM, Stephen Frost wrote:
> Perhaps if the versioned install script was actually a non-versioned
> install script in the source tree, and the Makefile simply installed it
> into the correct place, then we could eliminate that part. (All very
> hand-wavy, I've not looked at what it'd
I happened to notice that if you type "make" in
src/test/modules/test_pg_dump, you will get a "make check" action
not "make all". I hope this is just somebody being thoughtless
about Makefile ordering and not an intentional override of the
default make target. If the latter, I beg to differ about
Tom Lane wrote:
> I happened to notice that if you type "make" in
> src/test/modules/test_pg_dump, you will get a "make check" action
> not "make all". I hope this is just somebody being thoughtless
> about Makefile ordering and not an intentional override of the
> default make target. If the lat
Peter Eisentraut writes:
> More generally, I'm concerned that appendShellString() looks pretty
> attractive for future use. It's not inconceivable that someone will
> want to use it for say calling pg_dump from pg_dumpall or pg_upgrade at
> some point, and then maybe we'll accidentally disallow L
On Thu, Sep 8, 2016 at 8:42 PM, Claudio Freire
wrote:
> On Thu, Sep 8, 2016 at 11:54 AM, Pavan Deolasee
> wrote:
> > For example, for a table with 60 bytes wide tuple (including 24 byte
> > header), each page can approximately have 8192/60 = 136 tuples. Say we
> > provision for 136*2 = 272 bits
Alvaro Herrera writes:
> Tom Lane wrote:
>> I happened to notice that if you type "make" in
>> src/test/modules/test_pg_dump, you will get a "make check" action
>> not "make all".
> Strange. Don't all these makefiles depend on the pgxs stuff emitting
> something sane, which would have "all" as t
> While checking for shippability, we build the target list which is passed
> to
> the foreign server as fdw_scan_tlist. The target list contains
> a. All the GROUP BY expressions
> b. Shippable entries from the target list of upper relation
> c. Var and Aggref nodes from non-shippable entries from
On Thu, Sep 8, 2016 at 8:53 AM, Claudio Freire wrote:
> setup:
>
> create table lotsofitext(i text, j text, w text, z integer, z2 bigint);
> insert into lotsofitext select cast(random() * 10.0 as text)
> || 'blablablawblabla', cast(random() * 10.0 as text) ||
> 'blablablawjjjbl
Michael Paquier writes:
> On Tue, Aug 30, 2016 at 5:43 AM, MartÃn Marqués
> wrote:
>> This is v4 of the patch, which is actually a cleaner version from the
>> v2 one Michael sent.
> Let's do as you suggest then, and just focus on the schema issue. I
> just had an extra look at the patch and i
On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
> I still think tuplesort_heap_siftup is a confusing name, although I'm not
> sure that Peter's "compact" is much better. I suggest that we rename it to
> tuplesort_heap_delete_top(). In comments within the function, explain that
> the *lo
On Thu, Sep 8, 2016 at 2:13 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 8:53 AM, Claudio Freire wrote:
>> setup:
>>
>> create table lotsofitext(i text, j text, w text, z integer, z2 bigint);
>> insert into lotsofitext select cast(random() * 10.0 as text)
>> || 'blablablawblabl
On Thu, Sep 8, 2016 at 10:18 AM, Claudio Freire wrote:
> That particular case I believe is using work_mem=4MB, easy strings, 1.5GB
> table.
Cool. I wonder where this leaves Heikki's draft patch, that completely
removes batch memory, etc.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailin
Hi,
Attached patch add --disable-page-skipping option to vacuumed command for 9.6.
If by any chance the freeze map causes the serious data corruption bug
then the user will want to run pg_check_visible() and vacuum with
DISABLE_PAGE_SKIPPING option to the multiple tables having problem.
In this ca
Hi,
I found these steps to a reliable crash (I know the patch is WIP but I
assume you want to hear about these).
(Running a single instance suffices)
psql (10devel_logical_replication_20160901_1237_6f7c0ea32f80)
Type "help" for help.
(PID 9809) [testdb] # CREATE PUBLICATION pub_all;
CREATE
My apologies if this was already requested before...
I think it would be fantastic if postgres had an "explain the explain" option:
Today's explain tells us what loops and scans were used, and relative
costs, etc. It doesn't seem to tell *why* the planner elected to use
what it did.
For instance
Peter Geoghegan writes:
> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
>> I still think tuplesort_heap_siftup is a confusing name, although I'm not
>> sure that Peter's "compact" is much better. I suggest that we rename it to
>> tuplesort_heap_delete_top(). In comments within the fu
Tom Lane wrote:
> Alvaro Herrera writes:
> > I suppose this is a very easy mistake to make -- but also fortunately an
> > easy one to correct. Do you want me to fix the affected modules?
>
> I was going to do it, but if you want to, feel free.
Done.
> (BTW, I notice that test_pg_dump's Makefi
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I suppose this is a very easy mistake to make -- but also fortunately an
>>> easy one to correct. Do you want me to fix the affected modules?
>> I was going to do it, but if you want to, feel free.
> Done.
Thanks.
On 09/05/2016 02:50 PM, Mithun Cy wrote:
On Sep 2, 2016 7:38 PM, "Jesper Pedersen"
wrote:
Could you provide a rebased patch based on Amit's v5 ?
Please find the the patch, based on Amit's V5.
I have fixed following things
1. now in "_hash_first" we check if (opaque->hasho_prevblkno ==
Inval
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I happened to notice that if you type "make" in
> src/test/modules/test_pg_dump, you will get a "make check" action
> not "make all". I hope this is just somebody being thoughtless
> about Makefile ordering and not an intentional override of the
> default m
On Thu, Sep 8, 2016 at 11:54 PM, Pavan Deolasee
wrote:
>
>
> On Wed, Sep 7, 2016 at 10:18 PM, Claudio Freire
> wrote:
>>
>> On Wed, Sep 7, 2016 at 12:12 PM, Greg Stark wrote:
>> > On Wed, Sep 7, 2016 at 1:45 PM, Simon Riggs
>> > wrote:
>> >> On 6 September 2016 at 19:59, Tom Lane wrote:
>> >>
Greetings!
* Stephen Frost (sfr...@snowman.net) wrote:
> Based on Robert's suggestion and using Thom's verbiage, I've tested this
> out:
>
> CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
>
> and it appears to work fine with the grammar, etc.
>
> Unless there's other thoughts on this,
People,
I made a small modification in pg_dump to prevent parallel backup failures
due to exclusive lock requests made by other tasks.
The modification I made take shared locks for each parallel backup worker
at the very beginning of the job. That way, any other job that attempts to
acquire exclu
Ildar> Could you please try the patch and tell if it works for you?
I've tested patch6 against recent head. The patch applies with no problems.
The previous case (filter on top of i-o-s) is fixed. Great work.
Here are the test cases and results:
https://gist.github.com/vlsi/008e18e18b609fcaaec53
Andrew Borodin writes:
> Thank you for your corrections.
> Here is the patch with suggestions taken into account, except 6th.
I'll pick this up, unless some other committer is already on it.
I think that we should buy back the addition of PageIndexTupleOverwrite
to bufpage.c by getting rid of Pa
On 09/06/2016 10:26 PM, Peter Geoghegan wrote:
On Tue, Sep 6, 2016 at 12:08 PM, Peter Geoghegan wrote:
Offhand, I would think that taken together this is very important. I'd
certainly want to see cases in the hundreds of megabytes or gigabytes
of work_mem alongside your 4MB case, even just to b
On Wed, Sep 7, 2016 at 3:29 AM, Ashutosh Sharma
wrote:
> > Thanks to Ashutosh Sharma for doing the testing of the patch and
> > helping me in analyzing some of the above issues.
>
> Hi All,
>
> I would like to summarize the test-cases that i have executed for
> validating WAL logging in hash inde
All,
I have discovered a bug with the COPY command, specifically related to RLS.
The issue:
When running COPY as superuser on a table that has RLS enabled, RLS is
bypassed and therefore no issue exists. However, when performing a
COPY as a non-privileged user on the same table causes issues whe
Lucas writes:
> I made a small modification in pg_dump to prevent parallel backup failures
> due to exclusive lock requests made by other tasks.
> The modification I made take shared locks for each parallel backup worker
> at the very beginning of the job. That way, any other job that attempts to
On Thu, Sep 8, 2016 at 10:40 AM, Tom Lane wrote:
>> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
>>> I still think tuplesort_heap_siftup is a confusing name, although I'm not
>>> sure that Peter's "compact" is much better. I suggest that we rename it to
>>> tuplesort_heap_delete_top
Tom Lane wrote:
> Andrew Borodin writes:
> > Thank you for your corrections.
> > Here is the patch with suggestions taken into account, except 6th.
>
> I'll pick this up, unless some other committer is already on it.
>
> I think that we should buy back the addition of PageIndexTupleOverwrite
> t
Stephen Frost wrote:
> Greetings!
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > Based on Robert's suggestion and using Thom's verbiage, I've tested this
> > out:
> >
> > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
Can't you keep those words as Sconst or something (DefElems?) u
On Thu, Sep 8, 2016 at 4:20 PM, Peter Geoghegan wrote:
> On Thu, Sep 8, 2016 at 10:40 AM, Tom Lane wrote:
>>> On Thu, Sep 8, 2016 at 12:01 AM, Heikki Linnakangas wrote:
I still think tuplesort_heap_siftup is a confusing name, although I'm not
sure that Peter's "compact" is much better.
Sift means shift up. There is no such thing as sift down, though, only
shift down. That is my understanding, based on the Wikipedia article on
heaps.
--
Peter Geoghegan
On Tue, Sep 6, 2016 at 11:44 PM, Craig Ringer
wrote:
> On 7 September 2016 at 11:37, Corey Huinker
> wrote:
> > On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer <
> craig.rin...@2ndquadrant.com>
> > wrote:
> >>
> >> On 7 September 2016 at 11:21, Corey Huinker
> >> wrote:
> >> > On Tue, Sep 6, 2016
Peter Geoghegan writes:
> Attached patch does it that way, then. I stuck with the reference to
> "shift down", though, since I think we all agree that that is
> unambiguous.
I dunno. What you've now got is
/*
* The tuple at state->memtuples[0] has been removed from the heap.
- * Decrement me
>It'd helpful if you summarize the changes made when posting revisions.
Can we use as summary about changes first message? If not, summary can be
something like that:
This parches fix scenarios interrupt logical replication from client side
and allow the client to end a logical decoding session b
Alvaro,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Stephen Frost (sfr...@snowman.net) wrote:
> > > Based on Robert's suggestion and using Thom's verbiage, I've tested this
> > > out:
> > >
> > > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ...
>
> Can
On 9/3/16 2:41 PM, Vik Fearing wrote:
> On 08/31/2016 06:22 AM, Peter Eisentraut wrote:
>> Here is a patch that adds the notion of a data type to a sequence. So
>> it might be CREATE SEQUENCE foo AS integer. The types are restricted to
>> int{2,4,8} as now.
>
> This patch does not apply cleanly
On Thu, Sep 8, 2016 at 12:46 PM, Tom Lane wrote:
>
> /*
> * The tuple at state->memtuples[0] has been removed from the heap.
> - * Decrement memtupcount, and sift up to maintain the heap invariant.
> + * Decrement memtupcount, and shift down to maintain the heap invariant.
> */
> static void
Hi,
Is this issue really worth keeping several hackers busy?
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
1 - 100 of 155 matches
Mail list logo
