Attached a patch that ensures the header of postgresql.auto.conf is
consistent, whether created by initdb or recreated when ALTER SYSTEM
is issued.
The tiny difference caused some false-positives on our configuration
management identifying changes, which was enough of an itch for me to
scratch.
r
Hello,
> I'd like to put comments on 0001 and 0004 only now:
...
I don't have a comment on 0002.
About 0003:
> @@ -4487,21 +4486,21 @@ circle_in(PG_FUNCTION_ARGS)
> ...
> circle->radius = single_decode(s, &s, "circle", str);
> - if (circle->radius < 0)
> + if (float8_lt(circle->r
Oops! The previous patch is forgetting the default case and crashes.
At Wed, 08 Nov 2017 13:14:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20171108.131431.170534842.horiguchi.kyot...@lab.ntt.co.jp>
> > I don't think 'distance' is a good metric - that's going to continually
> > c
On Wed, Nov 8, 2017 at 6:48 PM, Robert Haas wrote:
> On Wed, Nov 8, 2017 at 7:26 AM, Amit Kapila wrote:
>> We do want to generate it later when there isn't inheritance involved,
>> but only if there is a single rel involved (simple_rel_array_size
>> <=2). The rule is something like this, we will
Hi Dilip,
v6 patch:
42 + /*
43 +* Estimate number of hashtable entries we can have within
maxbytes. This
44 +* estimates the hash cost as sizeof(PagetableEntry).
45 +*/
46 + nbuckets = maxbytes /
47 + (sizeof(PagetableEntry) + sizeof(Pointer) + sizeof(Pointer));
It too
Hi
2017-11-06 14:00 GMT+01:00 Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp>:
> Thank you for the new patch.
>
> - The latest patch is missing xpath_parser.h at least since
> ns-3. That of the first (not-numbered) version was still
> usable.
>
> - c29c578 conflicts on doc/src/sgml/func.
Em qui, 9 de nov de 2017 às 06:15, Feike Steenbergen <
feikesteenber...@gmail.com> escreveu:
> Attached a patch that ensures the header of postgresql.auto.conf is
> consistent, whether created by initdb or recreated when ALTER SYSTEM
> is issued.
>
> The tiny difference caused some false-positives
On Thu, Nov 9, 2017 at 6:25 PM, Fabrízio de Royes Mello
wrote:
> Interesting... IMHO this typo should be backpatched to 9.4 when ALTER SYSTEM
> was introduced.
Yeah, that's harmless.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
On Wed, Nov 8, 2017 at 5:46 AM, Masahiko Sawada
wrote:
> > So I think
> > that you should instead do something like that:
> >
> > --- a/contrib/bloom/Makefile
> > +++ b/contrib/bloom/Makefile
> > @@ -20,5 +20,12 @@ include $(top_builddir)/src/Makefile.global
> > include $(top_srcdir)/contrib/con
On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
wrote:
> On 2017/11/06 14:32, David Rowley wrote:
>> On 6 November 2017 at 17:30, Amit Langote wrote:
>>> On 2017/11/03 13:32, David Rowley wrote:
On 31 October 2017 at 21:43, Amit Langote wrote:
[]
>
> Attached updated set of patches, includin
Hello all,
Here is the updated patch which is rebased over v10 of Amit Langote's
path towards faster pruning patch [1]. It modifies the PartScanKeyInfo
struct to hold expressions which is then evaluated by the executor to
fetch the correct partitions using the function.
The code still chooses the
Hi all,
According to the docs at
https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-CONNSTRING
there are various parameters that control ssl from the client side, including
providing the ssl certs, keys, etc.
Is there a parameter or mechanism for setting the required ssl ciphe
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello Anthony,
Great job!
I decided to take a closer look o
Hello,
On Sun, Oct 01, 2017 at 04:49:17PM -0300, Martin Marques wrote:
> Updated patch with documentation of the new option.
>
I have checked the patch.
The patch is applied and compiled correctly without any errors. Tests passed.
The documentation doesn't have errors too.
I have a little sugg
Hi,
Attached is a patch to reorder header files in joinrels.c and pathnode.c
in alphabetical order, removing unnecessary ones.
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/path/joinrels.c
--- b/src/backend/optimizer/path/joinrels.c
***
*** 16,30
#include "miscadmi
Hello!
I've came across a weird bit in pg_upgrade/exec.c
We have a function check_bin_dir() which goes like this (old_cluster and
new_cluster are global variables):
void check_bin_dir(ClusterInfo *cluster)
{
...
get_bin_version(&old_cluster);
get_bin_version(&new_cluster);
...
}
On Wed, Nov 8, 2017 at 9:40 AM, Masahiko Sawada wrote:
> Speaking of the acquiring these four lock types and heavy weight lock,
> there obviously is a call path to acquire any of four lock types while
> holding a heavy weight lock. In reverse, there also is a call path
> that we acquire a heavy we
On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson wrote:
> The code still chooses the custom plan instead of the generic plan for
> the prepared statements. I am working on it.
I don't think it's really the job of this patch to do anything about
that problem.
--
Robert Haas
EnterpriseDB: http://www
Robert Haas writes:
> No, that's not right. Now that you mention it, I realize that tuple
> locks can definitely cause deadlocks. Example:
Yeah. Foreign-key-related tuple locks are another rich source of
examples.
> ... So I don't
> think we can remove speculative insertion locks from the dea
Thomas Munro writes:
> On Thu, Nov 9, 2017 at 6:27 PM, Tom Lane wrote:
>> Is there really much interest in Bonjour support on non-macOS platforms?
>> I hadn't heard that anybody but Apple was invested in it.
> Not from me. My only interest here was to pipe up because I knew that
> what was orig
a.akent...@postgrespro.ru wrote:
> This function has two calls:
> check_bin_dir(&old_cluster);
> check_bin_dir(&new_cluster);
>
> I'd like to substitute these last two lines with this:
> get_bin_version(cluster);
Odd indeed. One would think that if a cluster variable is passed as
parameter, the
a.akent...@postgrespro.ru writes:
> I've came across a weird bit in pg_upgrade/exec.c
> We have a function check_bin_dir() which goes like this (old_cluster and
> new_cluster are global variables):
> void check_bin_dir(ClusterInfo *cluster)
> {
> ...
> get_bin_version(&old_cluster);
>
Alvaro Herrera writes:
> I think odd coding this was introduced recently because of the
> pg_resetxlog -> pg_resetwal renaming.
Dunno about that, but certainly somebody fat-fingered a refactoring
there. The 9.6 code looks quite different but doesn't seem to be
doing anything silly.
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> Em qui, 9 de nov de 2017 às 06:15, Feike Steenbergen <
> feikesteenber...@gmail.com> escreveu:
>> Attached a patch that ensures the header of postgresql.auto.conf is
>> consistent, whether created by initdb or recreated when ALTER SYSTEM
>> is iss
There is a huge thread concerning pushing-down aggregates to FDW:
https://www.postgresql.org/message-id/flat/CAFjFpRcnueviDpngJ3QSVvj7oyukr9NkSiCspqd4N%2BdCEdvYvg%40mail.gmail.com#cafjfprcnuevidpngj3qsvvj7oyukr9nksicspqd4n+dcedv...@mail.gmail.com
but as far as I understand nothing is done for ef
On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier
wrote:
>
> On Thu, Nov 9, 2017 at 2:42 AM, Fabrízio de Royes Mello
> wrote:
> > On Wed, Nov 8, 2017 at 12:47 AM, Michael Paquier <
michael.paqu...@gmail.com>
> > wrote:
> >> - Let's restrict the logging to a role name instead of a database
> >> nam
Hi,
Occasionally, when debugging issues, I find it quite useful to be able
to do a heap_page_items() on a page that's actually locked exclusively
concurrently. E.g. investigating the recent multixact vacuuming issues,
it was very useful to attach a debugger to one backend to step through
freezing,
On Thu, Nov 9, 2017 at 9:49 AM, Andres Freund wrote:
> Currently the locking in get_raw_page_internal() prevents that. If it's
> an option defaulting to off, I don't see why we couldn't allow that to
> skip locking the page's contents. Obviously you can get corrupted
> contents that way, but we a
On 11/09/2017 03:27 AM, Graham Leggett wrote:
> Is there a parameter or mechanism for setting the required ssl cipher list
> from the client side?
I don't believe so. That is controlled by ssl_ciphers, which requires a
restart in order to change.
https://www.postgresql.org/docs/10/static/runtime
Michael Paquier writes:
> On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
>> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
>> so that people who wanted true write-only could get it, without breaking
>> backwards-compatible behavior. But I'm inclined to wait for some f
On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund wrote:
> Occasionally, when debugging issues, I find it quite useful to be able
> to do a heap_page_items() on a page that's actually locked exclusively
> concurrently. E.g. investigating the recent multixact vacuuming issues,
> it was very useful to
On 2017-11-09 12:55:30 -0500, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund wrote:
> > Occasionally, when debugging issues, I find it quite useful to be able
> > to do a heap_page_items() on a page that's actually locked exclusively
> > concurrently. E.g. investigating the re
On Thu, Nov 9, 2017 at 12:58 PM, Andres Freund wrote:
> You can already pass arbitrary byteas to heap_page_items(), so I don't
> see how this'd change anything exposure-wise? Or are you thinking that
> users would continually do this with actual page contents and would be
> more likely to hit edge
On Sat, Oct 28, 2017 at 5:50 AM, Robert Haas wrote:
> No, because the Append node is *NOT* getting copied into shared
> memory. I have pushed a comment update to the existing functions; you
> can use the same comment for this patch.
I spent the last several days working on this patch, which had
Tom, Michael,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
> >> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
> >> so that people who wanted true write-only could get it, without breaking
> >> bac
Hi
2017-08-24 5:50 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> I have added the patch to the next commitfest.
>
> Patch applies, compiles, works.
>
> I'm okay with the names graw/graw+, and for having such short-hands.
>
> Missing break in switch, even if last item and useless, because other
>
On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote:
> This change looks suspicious to me. I think here we can't use the
> tupDesc constructed from targetlist. One problem, I could see is that
> the check for hasOid setting in tlist_matches_tupdesc won't give the
> correct answer. In case of th
On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote:
> While we have been working to reduce the number of superuser() checks in
> the backend in favor of having the ability to GRANT explicit rights, one
> of the guideing principles has always been that capabilities which can
> be used to gain supe
Hi Konstantin!
09.11.17 20:14, Konstantin Knizhnik wrote:
It is still far from ideal plan because each worker is working with
all partitions, instead of spitting partitions between workers and
calculate partial aggregates for each partition.
But if we add FDW as a child of parent table, then
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote:
> > While we have been working to reduce the number of superuser() checks in
> > the backend in favor of having the ability to GRANT explicit rights, one
> > of the guideing principles has
On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote:
>> I disagree that that is, or should be, a guiding principle.
>
> It was what I was using as the basis of the work which I did in this
> area and, at least at that time, there seemed to be little issue with
> that.
Well, there actually kind of
On Thu, Nov 9, 2017 at 3:47 AM, Amit Kapila wrote:
> I think I understood your concern after some offlist discussion and it
> is primarily due to the inheritance related check which can skip the
> generation of gather paths when it shouldn't. So what might fit
> better here is a straight check on
>> This is also effecting lseg ## box operator.
>
> Mmm.. It returns (1.5, 1.5) with the 0004 patch. It is surely a
> point on the second operand but I'm not sure it's right that the
> operator returns a specific point for two parallel segments.
I am changing it to return NULL, when they are paral
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote:
> > This is not unlike the discussions we've had in the past around allowing
> > non-owners of a table to modify properties of a table, where the
> > argument has been successfully and clea
Hello Pavel,
I hope so I fixed all mentioned issues.
Patch applies with a warning:
> git apply ~/psql-graw-2.patch
/home/fabien/psql-graw-2.patch:192: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Otherwise it compiles. "make check" ok. doc gen ok.
Two spurious empty
All,
As we try and make PostGIS more "parallel sensitive" we have been added
costs to our functions, so that their relative CPU cost is more accurately
reflected in parallel plans.
This has resulted in an odd side effect: some of our "wrapper" functions
stop giving index scans in plans [1]. This
2017-11-09 21:03 GMT+01:00 Fabien COELHO :
>
> Hello Pavel,
>
> I hope so I fixed all mentioned issues.
>>
>
> Patch applies with a warning:
>
> > git apply ~/psql-graw-2.patch
> /home/fabien/psql-graw-2.patch:192: new blank line at EOF.
> +
> warning: 1 line adds whitespace errors.
>
> Otherw
On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
> I agree that it may not be obvious which cases lead to a relatively easy
> way to obtain superuser and which don't, and that's actually why I'd
> much rather it be something that we're considering and looking out for
> because, frankly, we're
Hi All,
I am using PostgreSQL version *9.5.7* on Red hat enterprise Linux *7.2.*
*OpenSSL version : * OpenSSL 1.0.1e-fips 11 Feb 2013.
I have a requirement to enable the SSL in my environment with specific
cipher suites,we want to restrict weak cipher suites from open SSL default
list.
We have
Hi
We checked some check query based on some operations on pg_depend table.
This query did different result when database was migrated with pg_dump or
with pg_upgrade. I found so this query was broken, but I found interesting
thing.
The count is 1 for any objid
select distinct count(distinct cla
Robert Haas writes:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
>> Further, I agree entirely that we
>> shouldn't be deciding that certain capabilities are never allowed to be
>> given to a user- but that's why superuser *exists* and why it's possible
>> to give superuser access to mul
Robert Haas writes:
> On Thu, Nov 9, 2017 at 12:58 PM, Andres Freund wrote:
>> You can already pass arbitrary byteas to heap_page_items(), so I don't
>> see how this'd change anything exposure-wise? Or are you thinking that
>> users would continually do this with actual page contents and would be
On 2017-11-09 17:14:11 -0500, Tom Lane wrote:
> If we do this, I'd suggest exposing it as a separate SQL function
> get_raw_page_unlocked() rather than as an option to get_raw_page().
>
> The reasoning is that if we ever allow these functions to be controlled
> via GRANT instead of hardwired super
On 2017-11-04 06:15:00 -0700, Andres Freund wrote:
> The reason for that is that I hadn't yet quite figured out how the bug I
> described in the commit message (and the previously committed testcase)
> would cause that. I was planning to diagnose / experiment more with this
> and write an email if
On Fri, Nov 10, 2017 at 2:32 AM, Fabrízio de Royes Mello
wrote:
> On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier
> wrote:
>> +++ b/src/test/modules/test_session_hooks/session_hooks.conf
>> @@ -0,0 +1 @@
>> +shared_preload_libraries = 'test_session_hooks'
>> Don't you think that this should be a
On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote:
> Fixed in the 0003 patch.
I have committed this patch set with the attached adjustments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hash-adjustments.patch
Description: Binary data
--
Sent via pg
On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
> I did miss the need to fix the docs, and am happy to put in some strong
> wording about the security hazards of these functions while fixing the
> docs. But I do not think that leaving them with hardwired superuser
> checks is an improvement over
On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote:
> On 11/09/2017 03:27 AM, Graham Leggett wrote:
>> Is there a parameter or mechanism for setting the required ssl cipher list
>> from the client side?
>
> I don't believe so. That is controlled by ssl_ciphers, which requires a
> restart in order
Michael Paquier writes:
> On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
>> I did miss the need to fix the docs, and am happy to put in some strong
>> wording about the security hazards of these functions while fixing the
>> docs. But I do not think that leaving them with hardwired superuser
>
On 11/09/2017 03:17 PM, Michael Paquier wrote:
> On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote:
>> On 11/09/2017 03:27 AM, Graham Leggett wrote:
>>> Is there a parameter or mechanism for setting the required ssl cipher list
>>> from the client side?
>>
>> I don't believe so. That is controlle
On Fri, Sep 29, 2017 at 4:00 PM, Martin Marques <
martin.marq...@2ndquadrant.com> wrote:
> Hi,
>
> Some time ago I had to work on a system where I was cloning a standby
> using pg_basebackup, that didn't have screen or tmux. For that reason I
> redirected the output to a file and ran it with nohup
On Thu, Nov 9, 2017 at 2:24 PM, Andres Freund wrote:
> Attached is a version of the already existing regression test that both
> reproduces the broken hot chain (and thus failing index lookups) and
> then also the tuple reviving. I don't see any need for letting this run
> with arbitrary permutat
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
> > Further, I agree entirely that we
> > shouldn't be deciding that certain capabilities are never allowed to be
> > given to a user- but that's why superuser *exists* and why it's possibl
On 2017-11-09 16:02:17 -0800, Peter Geoghegan wrote:
> > What I'm currently wondering about is how much we need to harden
> > postgres against such existing corruption. If e.g. the hot chains are
> > broken somebody might have reindexed thinking the problem is fixed - but
> > if they then later vac
On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
>> I don't follow you here. Why would REINDEXing make the rows that
>> should be dead disappear again, even for a short period of time?
>
> It's not the REINDEX that makes them reappear.
Of course. I was just trying to make sense of what you sa
Hi Amul.
On 2017/11/09 20:05, amul sul wrote:
> On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
> wrote:
>> On 2017/11/06 14:32, David Rowley wrote:
>>> On 6 November 2017 at 17:30, Amit Langote wrote:
On 2017/11/03 13:32, David Rowley wrote:
> On 31 October 2017 at 21:43, Amit Langote wrot
Hi,
We are getting the bellow error while trying use Logical Replication
with user defined data types in a C program (when call elog function).
ERROR: XX000: cache lookup failed for type X
# X is remote type's oid
It occurs in worker.c:slot_store_error_callback function when remotety
On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
>> Actually, on second thought, I take that back -- I don't think that
>> REINDEXing will even finish once a HOT chain is broken by the bug.
>> IndexBuildHeapScan() actually does quite a good job of making sure
>> that HOT chains are sane, which
On Thu, Nov 9, 2017 at 7:51 PM, Alexander Korotkov
wrote:
> On Wed, Nov 8, 2017 at 5:46 AM, Masahiko Sawada
> wrote:
>> > So I think
>> > that you should instead do something like that:
>> >
>> > --- a/contrib/bloom/Makefile
>> > +++ b/contrib/bloom/Makefile
>> > @@ -20,5 +20,12 @@ include $(top_
On 2017-11-09 16:45:07 -0800, Peter Geoghegan wrote:
> On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote:
> >> Actually, on second thought, I take that back -- I don't think that
> >> REINDEXing will even finish once a HOT chain is broken by the bug.
> >> IndexBuildHeapScan() actually does quite
Stephen Frost writes:
> I'm guessing no, which essentially means that *we* consider access to
> lo_import/lo_export to be equivilant to superuser and therefore we're
> not going to implement anything to try and prevent the user who has
> access to those functions from becoming superuser. If we ar
On Thu, Nov 9, 2017 at 4:53 PM, Andres Freund wrote:
> Primarily because it's not an anti-corruption tool. I'd be surprised if
> there weren't ways to corrupt the page using these corruptions that
> aren't detected by it.
It's very hard to assess the risk of missing something that's actually
dete
On Thu, Nov 9, 2017 at 9:01 PM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson wrote:
>> The code still chooses the custom plan instead of the generic plan for
>> the prepared statements. I am working on it.
>
> I don't think it's really the job of this patch to do anything ab
On Fri, Nov 10, 2017 at 12:05 AM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote:
>> This change looks suspicious to me. I think here we can't use the
>> tupDesc constructed from targetlist. One problem, I could see is that
>> the check for hasOid setting in tlist_match
On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
> Stephen Frost writes:
>> I'm guessing no, which essentially means that *we* consider access to
>> lo_import/lo_export to be equivilant to superuser and therefore we're
>> not going to implement anything to try and prevent the user who has
>> acc
On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote:
> Have you set force_parallel_mode=regress; before running the
> statement?
Yes, I tried that first.
> If so, then why you need to tune other parallel query
> related parameters?
Because I couldn't get it to break the other way, I then tried th
Hello,
At Fri, 10 Nov 2017 09:34:57 +0900, Amit Langote
wrote in
<5fcb1a9f-b4ad-119d-14c7-282c30c7f...@lab.ntt.co.jp>
> Hi Amul.
>
> On 2017/11/09 20:05, amul sul wrote:
> > On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote
> > wrote:
> >> On 2017/11/06 14:32, David Rowley wrote:
> >>> On 6 Novemb
On Fri, Nov 10, 2017 at 8:36 AM, Robert Haas wrote:
> On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote:
>> Have you set force_parallel_mode=regress; before running the
>> statement?
>
> Yes, I tried that first.
>
>> If so, then why you need to tune other parallel query
>> related parameters?
>
>
Hello, this is the second part of the review.
At Fri, 10 Nov 2017 12:30:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20171110.123000.151902771.horiguchi.kyot...@lab.ntt.co.jp>
> In 0002, bms_add_range has a bit naive-looking loop
> In 0003,
In 0004,
The name get_partitions_fro
On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas wrote:
> On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote:
>> Fixed in the 0003 patch.
>
> I have committed this patch set with the attached adjustments.
>
Thanks a lot for your support & a ton of thanks to all reviewer.
Regards,
Amul
--
Sent via pg
Ooops! The following comment is wrong. Please ignore it.
At Fri, 10 Nov 2017 14:38:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20171110.143811.97616847.horiguchi.kyot...@lab.ntt.co.jp>
> Those two conditions are not orthogonal. Maybe something like
> following seems more underst
2017-11-09 21:12 GMT+01:00 Pavel Stehule :
>
>
> 2017-11-09 21:03 GMT+01:00 Fabien COELHO :
>
>>
>> Hello Pavel,
>>
>> I hope so I fixed all mentioned issues.
>>>
>>
>> Patch applies with a warning:
>>
>> > git apply ~/psql-graw-2.patch
>> /home/fabien/psql-graw-2.patch:192: new blank line at EO
Hello,
At Fri, 10 Nov 2017 14:44:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20171110.144455.117208639.horiguchi.kyot...@lab.ntt.co.jp>
> > Those two conditions are not orthogonal. Maybe something like
> > following seems more understantable.
> >
> > > if (!constfalse)
> > > {
ISTM that you can remove "force_column_header" and just set "tuple_only"
to what you need, that is you do not need to change anything in function
"print_unaligned_text".
Last point is not possible - I would not to break original tuple only mode.
Hmmm... I do not understand. I can see only on
2017-11-10 8:12 GMT+01:00 Fabien COELHO :
>
> ISTM that you can remove "force_column_header" and just set "tuple_only"
>>> to what you need, that is you do not need to change anything in function
>>> "print_unaligned_text".
>>>
>>
>> Last point is not possible - I would not to break original tuple
Hi
I am sending some notes, experience about usage of pgAudit.
pgAudit provides basic functionality and usually is good enough. But it is
not good enough for some applications in financial services.
The requirements:
1. structured output - attached query is not good enough - column name,
table
On 10 November 2017 at 16:30, Kyotaro HORIGUCHI
wrote:
> In 0002, bms_add_range has a bit naive-looking loop
>
> + while (wordnum <= uwordnum)
> + {
> + bitmapword mask = (bitmapword) ~0;
> +
> + /* If working on the lower word, zero out bits below 'lower'.
On 9 November 2017 at 09:27, Thomas Munro wrote:
> On Wed, Nov 8, 2017 at 5:57 PM, Amit Khandekar wrote:
>> On 8 November 2017 at 07:55, Thomas Munro
>> wrote:
>>> On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas wrote:
The changes to trigger.c still make me super-nervous. Hey THOMAS
MUN
88 matches
Mail list logo
