On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao wrote:
> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi
> wrote:
> >
> > Update patch attached.
>
> + if (userid != 0 && dbid != 0 && queryid != 0)
>
> UINT64CONST() should be used for the constant for queryid?
>
OK.
> It's rare case, but 0 can be as
On Sat, Jul 7, 2018 at 12:31 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I tool a look at this patch. It looks good for me. It applies
> > cleanly on last master, builds without warnings, passes tests.
> > Functionality seems to be well-covered by documentation and regression
> > tests.
Hi,
On 2017-12-08 13:44:37 -0800, Andres Freund wrote:
> On 2017-12-08 10:17:34 -0800, Andres Freund wrote:
> > the strtoll is libc functionality triggered by pg_atoi(), something I've
> > seen show up in numerous profiles. I think it's probably time to have
> > our own optimized version of it rat
On Sat, Jul 07, 2018 at 12:01:10PM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-07-07 20:51:56 +0200, David Fetter wrote:
> > As to "dual license," that's another legal thicket in which we've been
> > wise not to involve ourselves. "Dual licensing" is generally used to
> > assert proprietary righ
> On Wed, 27 Jun 2018 at 17:49, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On 26 June 2018 at 22:56, Andres Freund wrote:
> > On 2018-06-26 21:55:07 +0100, Andrew Gierth wrote:
> >> > "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
> >>
> >> Dmitry> Yep, my bad, forgot to tu
Hi,
On 2018-07-07 20:51:56 +0200, David Fetter wrote:
> As to "dual license," that's another legal thicket in which we've been
> wise not to involve ourselves. "Dual licensing" is generally used to
> assert proprietary rights followed immediately by a demand for
> payment. This is a thing we don't
On Sat, Jul 07, 2018 at 11:05:48AM -0700, Andres Freund wrote:
> On 2018-07-07 19:37:45 +0200, David Fetter wrote:
> > On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:
> > > Hi,
> > > On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> > > > On Thu, Jul 05, 2018 at 01:15:15AM +, T
I wrote:
> Huh. So what that suggests is that the problem is related to picking
> up copies of our libraries from outside the build tree. Do you have
> any copies of libpgport.a/.so or libpgcommon.a/.so in
> /usr/local/lib or /usr/lib or /lib ?
Ah, no, scratch that, I see the problem. In v10, p
On Sat, Jul 07, 2018 at 01:33:26PM -0500, Larry Rosenman wrote:
> On Sat, Jul 07, 2018 at 02:28:17PM -0400, Tom Lane wrote:
> > Larry Rosenman writes:
> > > And the winner is:
> >
> > > dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit
> > > commit dddfc4cb2edcfa5497f5d50190a7fb046
On Sat, Jul 07, 2018 at 02:28:17PM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > And the winner is:
>
> > dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit
> > commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16
> > Author: Tom Lane
> > Date: Tue Apr 3 16:26:05 2018 -0400
> >
Larry Rosenman writes:
> And the winner is:
> dddfc4cb2edcfa5497f5d50190a7fb046c51da16 is the first bad commit
> commit dddfc4cb2edcfa5497f5d50190a7fb046c51da16
> Author: Tom Lane
> Date: Tue Apr 3 16:26:05 2018 -0400
>
> Prevent accidental linking of system-supplied copies of libpq.so etc
On Thu, Jul 5, 2018 at 10:45 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 29.06.18 05:15, Jeff Janes wrote:
> > Since pg_dump calls pg_get_expr once over and over again on the same
> > table consecutively, perhaps we could cache the column alias assignments
> > in a single-
On 2018-07-07 19:37:45 +0200, David Fetter wrote:
> On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:
> > Hi,
> > On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> > > On Thu, Jul 05, 2018 at 01:15:15AM +, Tsunakawa, Takayuki wrote:
> > > > I believe that accepting patented code
On Sat, Jul 07, 2018 at 10:20:35AM -0700, Andres Freund wrote:
> Hi,
> On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> > On Thu, Jul 05, 2018 at 01:15:15AM +, Tsunakawa, Takayuki wrote:
> > > I believe that accepting patented code from companies would be
> > > practically more useful for Po
Hi,
On 2018-07-07 19:12:58 +0200, David Fetter wrote:
> On Thu, Jul 05, 2018 at 01:15:15AM +, Tsunakawa, Takayuki wrote:
> > I believe that accepting patented code from companies would be
> > practically more useful for PostgreSQL enhancement and growth.
> > PostgreSQL is now a mature software
On Thu, Jul 05, 2018 at 01:15:15AM +, Tsunakawa, Takayuki wrote:
> From: Craig Ringer [mailto:cr...@2ndquadrant.com]
> > I'm assuming you don't want to offer a grant that lets anyone use
> > them for anything. But if you have a really broad grant to
> > PostgreSQL, all someone would have to do
On Sat, Jul 07, 2018 at 11:24:48AM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote:
> >> Larry Rosenman writes:
> >>> f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it.
>
> >> Don't think I believe that conclusion; that patch shouldn't
Larry Rosenman writes:
> On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote:
>> Larry Rosenman writes:
>>> f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it.
>> Don't think I believe that conclusion; that patch shouldn't
>> have affected anything at all for non-ARM architectures.
> Those
On Sat, Jul 07, 2018 at 11:11:24AM -0400, Tom Lane wrote:
> Larry Rosenman writes:
> > f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it.
>
> Don't think I believe that conclusion; that patch shouldn't
> have affected anything at all for non-ARM architectures.
>
> regards,
On Saturday, July 7, 2018, Brent Kerby wrote:
>
> Also, there are cases where it may not be desired to have a primary key,
> as the index maintenance and constraint checking are not free and not
> always necessary.
>
Btree uniqueness enforcement is worth the price.
> I'd be happy to try to work
Larry Rosenman writes:
> f044d71e331d77a0039cec0a11859b5a3c72bc95 fixed it.
Don't think I believe that conclusion; that patch shouldn't
have affected anything at all for non-ARM architectures.
regards, tom lane
Greeting Fabien,
* Fabien COELHO (coe...@cri.ensmp.fr) wrote:
> >I set it to Rejected. This seems like a misuse of the CF process,
> >which is about discussing actual patches.
>
> Somehow.
So, I tend to agree w/ Andrew that while this is a good topic to have on
-hackers, it shouldn't be a CF ent
On Sat, Jul 7, 2018 at 11:57 PM, Emre Hasegeli wrote:
>> FreeBSD's setproctitle() is a bit slow because it contains a syscall
>> or two, so people often run PostgreSQL with update_process_title set
>> to off on that OS. That makes the user experience not quite as nice
>> as Linux. As a weekend l
This is a possible workaround. But even if a table has a primary key, it
seems like there's some inefficiency in doing things this way: the old and
new row versions start out linked together (for instance this information
is available in a FOR EACH ROW trigger), but we're throwing away that
informa
> FreeBSD's setproctitle() is a bit slow because it contains a syscall
> or two, so people often run PostgreSQL with update_process_title set
> to off on that OS. That makes the user experience not quite as nice
> as Linux. As a weekend learn-me-some-kernel-hacking project I fixed
> that and got
Hello Andrew,
I set it to Rejected. This seems like a misuse of the CF process,
which is about discussing actual patches.
Somehow.
As I have not received feedback from committers about the desirability of
the feature, I interpret that as "the feature is not desirable", and I
will not deve
Hello Peter,
+
+
+ Check constraints are not designed to enforce business rules across
tables.
+ Avoid using check constraints with a function accessing other tables and
+ use instead. Although PostgreSQL won't prevent
you
+ from doing so, beware that dumps generated
27 matches
Mail list logo
