On Sat, Sep 10, 2016 at 3:55 AM, Adam Brightwell
wrote:
>> Perhaps we should extend rowsecurity test with a more comprehensive
>> set of tests rather than just fix the COPY one?
>
> I think more tests that provide value are always a *good* thing,
> however, would argue that other tests 'unrelated'
This entry, should be closed, because this patch is part of another patch
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2016-09-06 15:00 GMT+02:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Hello, this is the new version of this patch. Rebased on the
> current master.
>
> At Tue, 06 Sep 2016 13:06:51 +0900 (Tokyo Standard Time), Kyotaro
> HORIGUCHI wrote in <
> 20160906.130651.171572544.horiguchi.kyot
Hello Sehrope Sarkuni,
I have reviewed the patch.
It is very simple (only an SQL query in the "psql" application changed).
It applies at the top of master.
It implements completion database names ("") for commands like
"CREATE DATABASE ... TEMPLATE ".
According to the documentation since 9.2 till
Hello Peter,
I have reviewed the patch.
Currently it does not applies at the top of master, the last commit
without a conflict is 975768f
It compiles and passes "make check" tests, but fails with "make check-world" at:
test foreign_data ... FAILED
It tries to implement SQL:2011 featu
For external sorts, cost_sort() assumes the following:
* The disk traffic is assumed to be 3/4ths sequential and 1/4th random
* accesses (XXX can't we refine that guess?)
...
/* Assume 3/4ths of accesses are sequential, 1/4th are not */
startup_cost += npageaccesses *
On Wed, Sep 7, 2016 at 12:32 AM, Marko Tiikkaja wrote:
> I've tested and reviewed this, and it looks good to me, other than this
> part:
>
> + /*
> +* kevent guarantees that the change list has been processed in the
> EINTR
> +* case. Here we are only applying a change list so EINTR cou
On Fri, Sep 9, 2016 at 9:51 PM, Claudio Freire wrote:
> On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>>
>> Claudio, if you could also repeat the tests you ran on Peter's patch set on
>> the other thread, with these patches, that'd be nice. These patches are
>> effectively a replaceme
On Fri, Sep 9, 2016 at 8:13 AM, Heikki Linnakangas wrote:
>
> Claudio, if you could also repeat the tests you ran on Peter's patch set on
> the other thread, with these patches, that'd be nice. These patches are
> effectively a replacement for
> 0002-Use-tuplesort-batch-memory-for-randomAccess-sor
...
On Fri, Sep 9, 2016 at 9:22 PM, Claudio Freire wrote:
> Since it is true that doing so would make it impossible to keep the
> asserts about tupindex in tuplesort_heap_root_displace, I guess it
> depends on how useful those asserts are (ie: how likely it is that
> those conditions could be viol
I wrote:
> ... BTW, a quick grep for other calls of PageIndexTupleDelete suggests
> that SPGiST could make very good use of PageIndexTupleOverwrite, and
> there may be use for it in GIN too.
I've pushed this patch with some editorializing and some followup
work. The above remains as possible mate
Hello Andrew (from back in 2004),
Have things improved at all regarding Postgres and the configurability of
reduced public privileges for databases?
We have a goal to hide unneeded database objects from our database-challenged
users - as they might see in a simple database viewer application -
On Wed, Sep 7, 2016 at 2:36 PM, Heikki Linnakangas wrote:
> 3. If we do that, we'll still have to reserve the tape buffers for all the
> tapes that we use during merge. So after we've built the initial runs, we'll
> need to reserve memory for those buffers. That might require shrinking
> memtuples
v6 fixes recently-introduced bit-rot.
Kevin Grittner
On Wed, Aug 31, 2016 at 3:24 PM, Kevin Grittner wrote:
> I have merged in the changes since v4 (a year and a half ago) and
> cured all bit-rot I found, to get the attached v5 which runs `make
> check world` without problem -- including the te
On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote:
>> The first patch fails to apply due to bit-rot. That's easy enough
>> to correct, but then it runs into warnings on make:
>
> Rebased and fixed.
These patches apply and build on top of 5c609a74 with no problems,
but `make check` finds diffe
Peter Geoghegan writes:
> I know that in practice, even virtual address space is significantly
> less than 64-bits on x86_64, so I think that there should be several
> bits there for the taking, even if the addresses are not aligned
> (although, they are). However, I have no idea if there is any
>
... BTW, a quick grep for other calls of PageIndexTupleDelete suggests
that SPGiST could make very good use of PageIndexTupleOverwrite, and
there may be use for it in GIN too.
I see one place in btree where there's a PageIndexTupleDelete and then
an insert, but it's unlikely to be worth touching b
On Fri, Sep 9, 2016 at 1:54 PM, Peter Geoghegan wrote:
>> 2. We could easily categorize incoming tuples as the come in, into those
>> that have a leading NULL, and others. If we kept them in separate arrays, or
>> perhaps grow memtuples from bottom-up for non-NULLs and from top-down for
>> NULLs,
On Fri, Sep 9, 2016 at 6:14 AM, Heikki Linnakangas wrote:
> A few things caught my eye while hacking on the latest round of sorting
> patches.
This is how it begins. :-)
> Starting a new thread because these are orthogonal to the things
> discussed on the other threads:
>
> 1. SortTuple.tupinde
On 9/6/16 8:56 PM, Peter Eisentraut wrote:
> Some thoughts on pg_dump and such:
Another issue to add to this list:
With the current patch set, pg_dump will fail for unprivileged users,
because it can't read pg_subscription. The include_subscription flag
ought to be checked in getSubscriptions()
Magnus wrote:
> I ran the web application mentioned in Marti's original mail on a patched
> Postgres server. It looks like it is working correctly now, no more test
> failures.
Thanks for the confirmation. I pushed the fix, along with the presented
test case.
I chose to backpatch all the way bac
Marko Tiikkaja wrote:
> Hi,
>
> Running one specific test from our application against REL9_5_STABLE
> (current as of today) gives me this:
Just pushed the fix. Thanks for the report!
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
On 6/6/16 9:59 AM, Merlin Moncure wrote:
> Thanks for the review. All your comments look pretty reasonable. I'll
> touch it up and resubmit.
This is the last email in this thread that the commit fest app shows. I
think we are waiting on an updated patch, with docs and tests.
--
Peter Eisentrau
> Thanks for the report and the fix.
Yup. I have added it to the 2016-11 commitfest:
https://commitfest.postgresql.org/11/794/
> This seems a rather basic error to occur a year after release.
>
> Is this a problem with the testing of RLS? What other RLS related
> failures exist in other commands?
On Thu, Sep 8, 2016 at 9:29 AM, Andrew Borodin wrote:
>>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
Personally I wouldn't
Here's a draft patch that replaces BRIN's use of PageIndexDeleteNoCompact
and an immediately following PageAddItemExtended with
PageIndexTupleOverwrite. It turns out that there are two use-cases in
BRIN for PageIndexDeleteNoCompact, and the other one can't be replaced
because while there is a Page
Fujii Masao writes:
> On Sat, Aug 20, 2016 at 6:13 AM, Tom Lane wrote:
>> Use LEFT JOINs in some system views in case referenced row doesn't exist.
> This change causes pg_stat_activity to report the "bogus" information about
> walsenders as follows.
Hmm ... but if we want to exclude walsenders
On Sat, Aug 20, 2016 at 6:13 AM, Tom Lane wrote:
> Use LEFT JOINs in some system views in case referenced row doesn't exist.
>
> In particular, left join to pg_authid so that rows in pg_stat_activity
> don't disappear if the session's owning user has been dropped.
> Also convert a few joins to pg_
On Fri, Sep 9, 2016 at 5:25 AM, Greg Stark wrote:
> Wow, this is really cool. We should do something like this for query
> execution too.
We should certainly do this for tuplestore.c, too. I've been meaning
to adopt it to use batch memory. I did look at it briefly, and recall
that it was surprisi
On Fri, Sep 9, 2016 at 4:55 AM, Heikki Linnakangas wrote:
> I'm happy with the amount of testing I've done now, and the results. Does
> anyone want to throw out any more test cases where there might be a
> regression? If not, let's get these reviewed and committed.
I'll try to look at this proper
On Fri, Sep 9, 2016 at 6:51 PM, Tom Lane wrote:
> Pushed with cosmetic adjustments --- mostly, I thought we needed some
> comments about the topic.
Okay, Thanks.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Andres Freund writes:
> On 2016-09-07 09:46:32 -0400, Tom Lane wrote:
>> + * If reject_indirect is true, ignore paths that go through installable
>> + * versions (presumably, caller will consider starting from such versions).
> Reading this I was initially confused, only after reading
> find_inst
Stephen Frost writes:
> I saw the various list-based cases and commented in my reply (the one you
> quote part of above) why those didn't seem to make sense for this case
> (it's not a list and I don't see it ever growing into one).
I think Alvaro was simply questioning whether there would ever b
Haribabu Kommi writes:
> On Thu, Jun 2, 2016 at 6:51 PM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
>> After a process termination without PQfinish() of a client,
>> server emits the following log message not seen on Linux boxes.
>> LOG: could not receive data from client: An e
On 9/4/16 12:26 PM, Pavel Stehule wrote:
> I am sending review of this trivial patch.
>
> 1. No problems with patching, compiling
> 2. all regress tests passed
> 3. There are not any visible change, so tests, docs are not necessary
> 4. Using enum instead int is generally good idea
>
> I will mar
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> Can't you keep those words as Sconst or something (DefElems?) until the
> >> execution phase, so that they don't need to be keywords at all?
>
> > Seems like we could do that
Review of the patch in the commit fest:
- Various naming/spelling inconsistencies: In the source, the module
is require_where, the documentation titles it require-where, the GUC
parameters are requires_where.*, but incorrectly documented.
- Unusual indentation in the Makefile
- Needs tests
If you are still interested in. Here are 3 versions of pack-float. The
union version of pack-float should run faster. The code is simpler, the
dependencies are easier.
But it may be less accurate or even wrong, as for signed integers (x>>2)
and (x/4) are not the same. Consider x = -1.
You may try
Yes. You are right, ANSI C allows only load-time initializers. Attached
ANSI compatible version leads to the same assembly.
And let me suggest a bit-twiddling version as well. It gives 12
instructions, instead of 13. 12 is better, as modern x86 CPU will fetch
them at most in 3 cycles, one less tha
s in Pg where dynamic types are used - the
> result tupdesc is generated few times more - but it is not on critical path.
> 3. More comments, few more lines in doc.
> 4. Reformated by pgindent
>
new update
more regress tests
Regards
Pavel
>
> Regards
>
> Pavel
>
>
On Fri, Sep 9, 2016 at 2:27 PM, Tom Lane wrote:
> Dave Page writes:
>> We needed a specific version that was newer than that shipped with
>> RHEL 6 (or in EPEL) iirc.
>
> Sure hope that's not true of the currently-proposed patch :-(
Looking back at my old emails, apparently ICU 5.0 and later inc
I often see mention of project policies for various things (the one
triggering this email is in commit 967a7b0).
Where can I find documentation for these policies?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
Dave Page writes:
> We needed a specific version that was newer than that shipped with
> RHEL 6 (or in EPEL) iirc.
Sure hope that's not true of the currently-proposed patch :-(
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
I ran the web application mentioned in Marti's original mail on a
patched Postgres server. It looks like it is working correctly now, no
more test failures.
Thanks
-Magnus
On 07.09.2016 21:49, Marko Tiikkaja wrote:
On 07/09/16 7:29 PM, Alvaro Herrera wrote:
Marko, does this fix your reported
Dilip Kumar writes:
> Seems like a better option, done it this way..
> attaching the modified patch..
Pushed with cosmetic adjustments --- mostly, I thought we needed some
comments about the topic.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On 9/6/16 10:25 PM, Michael Paquier wrote:
>
On Wed, Sep 7, 2016 at 12:16 AM, David Steele wrote:
Attached is a new patch that adds sgml documentation. I can expand on each
directory individually if you think that's necessary, but thought it was
better to lump them into a few categories.
+
A few things caught my eye while hacking on the latest round of sorting
patches. Starting a new thread because these are orthogonal to the
things discussed on the other threads:
1. SortTuple.tupindex is not used when the sort fits in memory. If we
also got rid of the isnull1 flag, we could shr
On Fri, Sep 9, 2016 at 9:02 AM, Devrim Gündüz wrote:
>
> Hi,
>
> On Fri, 2016-09-09 at 09:48 +0800, Craig Ringer wrote:
>> Personally I would be pretty reluctant to package libicu when it's
>> already in RH/Fedora. If it were bundled in Pg's source tree and a
>> private copy was built/installed by
On 9/8/16 8:07 PM, Peter Geoghegan wrote:
> Not exactly. Peter E. didn't seem to be aware that there is an ICU
> collator versioning concept (perhaps I misunderstood, though).
You appear to have missed the part about the collversion column that my
patch adds. That's exactly the collator version o
On 09/09/2016 03:25 PM, Greg Stark wrote:
On Fri, Sep 9, 2016 at 1:01 PM, Heikki Linnakangas wrote:
I'm happy with what it looks like. We are in fact getting a more sequential
access pattern with these patches, because we're not expanding the pre-read
tuples into SortTuples. Keeping densely-pac
On 9/8/16 11:08 PM, Peter Geoghegan wrote:
> In principle, and assuming I haven't gotten something wrong, it ought
> to be possible to unambiguously identify a collation based on a
> matching UCA version (i.e. DUCET table), plus the collation tailorings
> matching exactly, even across ICU versions
On 2016/09/08 19:51, Etsuro Fujita wrote:
On 2016/09/06 22:07, Ashutosh Bapat wrote:
This patch tries to do two things at a time 1. support join pushdown for
FULL join when the joining relations have remote conditions 2. better
support for fetching placeholder vars, whole row references and some
On Fri, Sep 9, 2016 at 1:01 PM, Heikki Linnakangas wrote:
> I'm happy with what it looks like. We are in fact getting a more sequential
> access pattern with these patches, because we're not expanding the pre-read
> tuples into SortTuples. Keeping densely-packed blocks in memory, instead of
> Sort
On 8 September 2016 at 11:18, Simon Riggs wrote:
> 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 f
On Fri, Sep 9, 2016 at 9:12 PM, Simon Riggs wrote:
> Fix corruption of 2PC recovery with subxacts
>
> Reading 2PC state files during recovery was borked, causing corruptions during
> recovery. Effect limited to servers with 2PC, subtransactions and
> recovery/replication.
Thanks!
--
Michael
--
Andrey Borodin writes:
> That storage assertion fired during usual update table set x=random() without
> conditions. Also Make check fails without it (for brin usage, gist is ok with
> it).
I'm confused by that assertion, because the patch-as-submitted didn't
touch BRIN. Based on Alvaro's comm
On 09/08/2016 09:59 PM, Heikki Linnakangas wrote:
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
On Fri, Sep 9, 2016 at 3:17 PM, Ashutosh Bapat
wrote:
>
> 4. Remove bms_to_char(): I have added this function to print Relids in the
> debugger. I have found it very useful to quickly examine Relids in debugger,
> which otherwise wasn't so easy. If others find it useful too, I can create a
> separ
On Thu, Sep 8, 2016 at 5:48 PM, Alvaro Herrera
wrote:
> 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
On 9 September 2016 at 16:21, Magnus Hagander wrote:
> On Thu, Sep 8, 2016 at 6:19 PM, Peter Eisentraut
> wrote:
>>
>> 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 off
On 8 September 2016 at 10:26, Masahiko Sawada wrote:
> "k (n1, n2, n3)" == "first k (n1, n2, n3)" doesn't break backward
> compatibility but most users would think "k(n1, n2, n3)" as quorum
> after introduced quorum.
> I wish we can change the s_s_names syntax of 9.6 to "first k(n1, n2,
> n3)" st
On Fri, 9 Sep 2016 11:20:59 +0530
Mithun Cy wrote:
> If concern is only about excluding address which was tried
> previously. Then I think we can try this way, randomly permute given
> address list (for example fisher-yates shuffle) before trying any of
> those address in it. After that you can t
On 08.09.2016 17:31, Peter Eisentraut wrote:
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 atte
On 09/09/16 08:23, Vik Fearing wrote:
On 09/09/2016 03:28 AM, Michael Paquier wrote:
On Thu, Sep 8, 2016 at 6:26 PM, Masahiko Sawada wrote:
"k (n1, n2, n3)" == "first k (n1, n2, n3)" doesn't break backward
compatibility but most users would think "k(n1, n2, n3)" as quorum
after introduced qu
Hi,
I am sending new version of this patch
1. now generic TableExpr is better separated from a real content generation
2. I removed cached typmod - using row type cache everywhere - it is
consistent with other few places in Pg where dynamic types are used - the
result tupdesc is generated few tim
On Thu, Sep 8, 2016 at 6:19 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> 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
I have updated the patch with additional tests and comments per your
review. Final(?) version attached.
Applied on head, make check ok. No more comments on the code which does
what it says. I'm fine with this patch.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Hi,
On Fri, 2016-09-09 at 09:48 +0800, Craig Ringer wrote:
> Personally I would be pretty reluctant to package libicu when it's
> already in RH/Fedora. If it were bundled in Pg's source tree and a
> private copy was built/installed by the build system so it was part of
> the main postgresql-serve
On 8 September 2016 at 20:13, Adam Brightwell
wrote:
> I have discovered a bug with the COPY command, specifically related to RLS.
...
> Connecting as a non-privileged user provides the following results:
...
> COPY foo (a, b, c) TO stdout; -- fail
> ERROR: missing FROM-clause entry for table "b
On Fri, Sep 9, 2016 at 12:33 PM, Pavan Deolasee
wrote:
>
>
> On Thu, Sep 8, 2016 at 11:40 PM, Masahiko Sawada
> wrote:
>>
>>
>>
>> Making the vacuum possible to choose between two data representations
>> sounds good.
>> I implemented the patch that changes dead tuple representation to bitmap
>> b
Hello Michael,
Thanks for your detailed review.
>> - If WAL consistency check is enabled for a rmgrID, we always include
>> the backup image in the WAL record.
>
> What happens if wal_consistency has different settings on a standby
> and its master? If for example it is set to 'all' on the standb
71 matches
Mail list logo