On Tue, Jul 24, 2018 at 01:34:13AM -0400, Alvaro Herrera wrote:
> But I don't see why RangeVarCallbackOwnsTable isn't sufficient.
The set of relkinds checked by truncate_check_rel and
RangeVarCallbackOwnsTable is different (toast and matviews). And in the
case of VACUUM, partitioned tables can
On Tue, Jul 24, 2018 at 02:23:02PM +0900, Michael Paquier wrote:
> Well, letting any users take an exclusive lock on system catalogs at
> will is not acceptable either, so two possible answers would be to fail
> or skip such relations. The first concept applies if a relation list is
> given by
On Tue, Jul 17, 2018 at 1:55 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2018-07-15 16:41:35 -0400, Tom Lane wrote:
>>> Andres Freund writes:
On 2018-07-09 19:56:25 -0400, Tom Lane wrote:
> Or, perhaps, use a struct in assert builds and int64 otherwise?
> You could hide the
On Mon, Jul 23, 2018 at 09:51:54PM -0700, Andres Freund wrote:
> On July 23, 2018 9:50:10 PM PDT, Michael Paquier wrote:
>> Oh, yes, that would be bad. My mind has slipped here. I have seen
>> manual VACUUMs on system catalogs for applications using many temp
>> tables... So we would want to
Hi,
I was trying sqlsmith on REL_11_STABLE (commit
1b957e59b92dc44c14708762f882d7910463a9ac) with a database i have at
hand, and got an assertion failure.
It seems to happen during planning on prunning time but only when
tables get bigger than certain size.
I configured it with "--enable-debug
On July 23, 2018 9:50:10 PM PDT, Michael Paquier wrote:
>On Mon, Jul 23, 2018 at 09:17:53PM -0700, Andres Freund wrote:
>> I might be mis-parsing this due to typos. Are you actually suggesting
>> vacuum on system tables should depend on that GUC? If so, why? That's
>> seems like a terrible
On Mon, Jul 23, 2018 at 09:17:53PM -0700, Andres Freund wrote:
> I might be mis-parsing this due to typos. Are you actually suggesting
> vacuum on system tables should depend on that GUC? If so, why? That's
> seems like a terrible idea. It's pretty normal to occasionally have
> to vacuum them?
On July 23, 2018 9:14:03 PM PDT, Michael Paquier wrote:
>- While it would make sense, at least to me, to make VACUUM fall into
>if
>allow_system_table_mods is allowed,
I might be mis-parsing this due to typos. Are you actually suggesting vacuum on
system tables should depend on that GUC? If
On Mon, Jul 23, 2018 at 11:29:33AM -0400, Robert Haas wrote:
> ExecuteTruncate needs to be refactored to use RangeVarGetRelidExtended
> with a non-NULL callback rather than heap_openrv, and
> expand_vacuum_rel needs to use RangeVarGetRelidExtended with a
> callback instead of RangeVarGetRelid.
On Tue, Jul 24, 2018 at 2:10 PM, Craig Ringer wrote:
>> Grabbing it from a process's memory is a bit harder than grabbing contents
>> of a file, but not much harder. If the agent is remote then that's harder,
>> but you can just ask the script to decrypt the pgpass for you, so again, not
>> much
Further investigation I did:
CopyFrom() calls ExecFindPartition() to identify the destination child
table of partitioned table.
Then, it internally calls get_partition_for_tuple() to get partition
index according to the key value.
This invocation is not under the per-tuple context.
In case of
On Mon, Jul 23, 2018 at 02:27:48PM +, Bossart, Nathan wrote:
> Sorry for the delay on these patches! This is nearly identical to
> what I started writing last night, so it looks good to me.
Thanks for double-checking. I have pushed this one to move on with the
rest of the feature.
>
On 24 July 2018 at 05:53, Jeff Janes wrote:
> On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane wrote:
>
>> Thomas Munro writes:
>> > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck
>> wrote:
>> >> Since .pgpass files contain plain-text passwords, I searched for an
>> >> alternative.
>> >> In the
On 24 July 2018 at 03:31, Brian Faherty
wrote:
> Hey Hackers,
>
> If a postmaster is running and the pg_control file is removed postgres
> will PANIC.
How does that happen?
"Don't go deleting stuff in pgdata" is pretty fundamental.
On Mon, Jul 23, 2018 at 07:00:30PM -0400, Tom Lane wrote:
> I would vote to reject any such patch; it's too likely to cause more
> problems than it solves. Generally, if critical files like that one
> have disappeared, trying to write new data isn't going to be enough
> to fix it and could well
On Mon, Jul 23, 2018 at 07:47:44AM -0400, Fabien COELHO wrote:
>> I don't think that it is a bad idea to improve things the way you are
>
> For the record, this is not my patch, I'm merely reviewing it.
Of course, any input is welcome. It is nice to see that you took some
time to look at the
On Tue, Jul 24, 2018 at 09:41:52AM +0900, Kohei KaiGai wrote:
> In PG11beta2, my backend process gets terminated during COPY FROM of
> large text file (544GB) on partitioned table.
> The kernel log says OOM Killer send SIGKILL due to memory pressure.
> In fact, 63GB of system physical 64GB was
On Mon, Jul 23, 2018 at 07:55:57PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 23 Jul 2018 15:59:16 +0900, Michael Paquier
> wrote in <20180723065916.gi2...@paquier.xyz>
>> This is an open item for v11.
>
> Mmm. Thanks. I wrongly thought this was v10 item. Removed this
> from the next CF.
Thanks
Hello,
In PG11beta2, my backend process gets terminated during COPY FROM of
large text file (544GB) on partitioned table.
The kernel log says OOM Killer send SIGKILL due to memory pressure.
In fact, 63GB of system physical 64GB was consumed by the PostgreSQL
backend just before the termination.
"Regina Obe" writes:
>> You don't really need any new syntax for this particular case, I think.
>> You can declare the function in the extension like this:
>> create function ... set search_path from current;
> But then the search_path would be local variable to the function. Wouldn't
> that
>
> > a) In this particular case, I have a function that uses fuzzystrmatch
and is
> used in functional indexes.
> > I unfortunately can't schema qualify the use of soundex, because I
> > don't know where the user may have installed fuzzystrmatch is
> > installed
> > b) Stephen Frost had
"Regina Obe" writes:
> Sorry for not posting from the thread. Paul alerted me to this one and I am
> aware of the issue.
> 1) I do have fuzzstrmatch listed as a dependency in the control file. I know
> because I often install the geocoder with
> CREATE EXTENSION postgis_tiger_geocoder
Hi Tomas!
I did a few tests on my own Linux machine, but the problem is that my resources
on AWS(CPU, RAM and even Disk space) are very limited. I considered
establishing virtual machine on my own PC but the performance is even worse.
My original patch has two main optimizations: (1) switch to
On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck
> wrote:
> >> Since .pgpass files contain plain-text passwords, I searched for an
> >> alternative.
> >> In the attached patch I've added the possibility to run a command
On 23.07.18 19:38, Andrew Gierth wrote:
>> "Robert" == Robert Haas writes:
>
> >> However, connecting via Npgsql, which uses the extended protocol, I
> >> see something quite different. As a response to a Describe
> >> PostgreSQL message, I get back a NoData response rather than a
> >>
On Fri, Jul 20, 2018 at 5:56 PM, Marko Tiikkaja wrote:
> On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider
> wrote:
>
>> I'd like to bump this old bug that Lloyd filed for more discussion. It
>> seems serious enough to me that we should at least talk about it.
>>
>> Anyone with simply the login
On July 23, 2018 12:31:13 PM PDT, Brian Faherty
wrote:
>Hey Hackers,
>
>If a postmaster is running and the pg_control file is removed postgres
>will PANIC.
>
>Steps to recreate:
>
>1.) start a new cluster
>2.) rm $DATADIR/pg_control
>3.) psql => CHECKPOINT;
>
>PANIC: could not open control
On Mon, Jul 23, 2018 at 12:31 PM, Brian Faherty <
anothergenericu...@gmail.com> wrote:
> There does not really seem to be a need for this behavior as all the
> information postgres needs is in memory at this point. I propose with
> a patch to just recreate pg_control on updates if it does not
Hey Hackers,
If a postmaster is running and the pg_control file is removed postgres
will PANIC.
Steps to recreate:
1.) start a new cluster
2.) rm $DATADIR/pg_control
3.) psql => CHECKPOINT;
PANIC: could not open control file "global/pg_control": No such file
or directory
After the PANIC
On Mon, Jul 23, 2018 at 12:12:03PM -0700, Joshua D. Drake wrote:
> On 07/23/2018 12:06 PM, Bruce Momjian wrote:
> >>So, is it FUD? The core needs paid-for legal advice, not speculation.
> >>
> >>I'm quite certain that a software license can make a patent grant to the
> >>satisfaction of many open
> From: Paul Ramsey [mailto:pram...@cleverelephant.ca]
> Sent: Monday, July 23, 2018 2:42 PM
> To: Regina Obe
> Subject: Fwd: "interesting" issue with restore from a pg_dump with a
> database-wide search_path
>
> Seen this one?
> P
>
>
> -- Forwarded message --
> From: Tom Lane
On Mon, Jul 23, 2018 at 03:06:13PM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 02:02:40PM -0500, Nico Williams wrote:
> > On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote:
> > > On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote:
> > > > Perhaps patent law [in
On 2018-Apr-11, Peter Eisentraut wrote:
> On 4/10/18 06:29, Pavan Deolasee wrote:
> > One of our 2ndQuadrant support customers recently reported a sudden rush
> > of TOAST errors post a crash recovery, nearly causing an outage. Most
> > errors read like this:
> >
> > ERROR: unexpected chunk
On 07/23/2018 12:06 PM, Bruce Momjian wrote:
So, is it FUD? The core needs paid-for legal advice, not speculation.
I'm quite certain that a software license can make a patent grant to the
satisfaction of many open source communities, and almost certainly to
the satisfaction of the PG
On Mon, Jul 23, 2018 at 01:12:49PM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 11:37:05AM -0500, Nico Williams wrote:
> > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> > > Sun Microsystems seemed reasonably trustworthy too.
> >
> > Are there patent grants from Sun
Andrew>does it fail on the latest 11-stable
1) Current "build from Git/master PostgreSQL" produces the data row for
both simple and extended queries.
2) Just a side note: `CALL my_proc()` is not suitable for functions. That
looks weird.
Is the client expected to lookup system catalogs in order
On Mon, Jul 23, 2018 at 02:02:40PM -0500, Nico Williams wrote:
> On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote:
> > > Perhaps patent law [in some countries] requires contracts as opposed to
> > > licenses?
> >
> >
On Mon, Jul 23, 2018 at 01:12:19PM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote:
> > Perhaps patent law [in some countries] requires contracts as opposed to
> > licenses?
>
> Yes, I really don't know. I have just seen enough "oh, we didn't think
>
On 2018-07-23 12:03:32 -0400, Alvaro Herrera wrote:
> On 2018-Jul-24, Amit Langote wrote:
>
> > On Mon, Jul 23, 2018 at 11:20 PM, Andres Freund wrote:
>
> > > I think it's correct to check the plan time value, rather than the
> > > execution time value. Other enable_* GUCs also take effect
On 20.07.18 16:57, David Rowley wrote:
> One final note: I'm not entirely convinced we need this adaptive
> code, but it seems easy enough to rip it back out if it's more trouble
> than it's worth. But if the other option is a GUC, then I'd rather
> stick with the adaptive code, it's likely going
Hi,
On 2018-07-23 12:38:25 -0400, Robert Haas wrote:
> On Mon, Jul 23, 2018 at 12:13 PM, Andres Freund wrote:
> > My point is that we could just make HTSV treat them as recently dead,
> > without incurring the issues of the bug you referenced.
>
> That doesn't seem sufficient. For example, it
On 2018-07-23 13:14:04 -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 11:38:47AM -0500, Nico Williams wrote:
> > On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote:
> > > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> > > > On Mon, Jul 23, 2018 at 08:19:35AM
On Mon, Jul 23, 2018 at 3:49 AM, Etsuro Fujita
wrote:
> I have to admit that that is not a good idea. So, I'll update the patch so
> that we don't assume the projection capability of the subplan anymore, if we
> go this way.
Isn't that assumption fundamental to your whole approach?
>> Also,
Hi!
> 21 июля 2018 г., в 17:11, Andrey Borodin написал(а):
>
> <0001-Physical-GiST-scan-in-VACUUM-v13.patch>
Just in case, here's second part of patch series with actual page deletion.
I was considering further decreasing memory footprint by using bloom filters
instead of bitmap, but it will
> "Robert" == Robert Haas writes:
>> However, connecting via Npgsql, which uses the extended protocol, I
>> see something quite different. As a response to a Describe
>> PostgreSQL message, I get back a NoData response rather than a
>> RowDescription message, In other words, it would
On Mon, Jul 23, 2018 at 11:38:47AM -0500, Nico Williams wrote:
> On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> > > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> > > > I'm fairly sure that I'm
On Mon, Jul 23, 2018 at 11:37:05AM -0500, Nico Williams wrote:
> On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> > > I'm fairly sure that I'm right. But my point isn't that we should "trust
> > > Andres implicitly
On Mon, Jul 23, 2018 at 11:27:49AM -0500, Nico Williams wrote:
> On Mon, Jul 23, 2018 at 09:56:47AM -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > > It explicitly says irrevocable and successors. Why seems squarely
> > > aimed at your concern.
On Mon, Jul 23, 2018 at 2:23 AM, Shay Rojansky wrote:
> Hi hackers, I've encountered some odd behavior with the new stored procedure
> feature, when using INOUT parameters, running PostgreSQL 11-beta2.
>
> With the following procedure:
>
> CREATE OR REPLACE PROCEDURE my_proc(INOUT results text)
>
On Mon, Jul 23, 2018 at 11:55:01AM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> > > I'm fairly sure that I'm right. But my point isn't that we should "trust
> > > Andres implicitly
On Mon, Jul 23, 2018 at 12:13 PM, Andres Freund wrote:
> My point is that we could just make HTSV treat them as recently dead, without
> incurring the issues of the bug you referenced.
That doesn't seem sufficient. For example, it won't keep the
predecessor tuple's ctid field from being
On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> > I'm fairly sure that I'm right. But my point isn't that we should "trust
> > Andres implicitly ™" (although that's obviously not a bad starting point
> > ;)). But
On Mon, Jul 23, 2018 at 10:13:48AM -0400, Chapman Flack wrote:
> On 07/23/2018 10:01 AM, Bruce Momjian wrote:
>
> > And the larger question is whether a patent free for use by software
> > under any license can be used in a defensive way. If not, it means we
> > have no way forward here.
>
>
> "Tom" == Tom Lane writes:
Tom> As I said before, I think that we should change the existing
Tom> contrib modules to be coded likewise, all using a single -I switch
Tom> that points at SRCDIR/contrib. That'd help give people the right
Tom> coding model to follow.
I don't see that
On Mon, Jul 23, 2018 at 09:56:47AM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > It explicitly says irrevocable and successors. Why seems squarely
> > aimed at your concern. Bankruptcy wouldn't just invalidate that.
>
> They can say whatever they
On July 23, 2018 9:11:13 AM PDT, Robert Haas wrote:
>On Thu, Jul 19, 2018 at 3:42 PM, Andres Freund
>wrote:
>> I don't think this reasoning actually applies for making HOT pruning
>> weaker as necessary for decoding. The xmin horizon on catalog tables
>is
>> already pegged, which'd prevent
Peter Eisentraut writes:
> Also, let's recall that the point of this exercise is that you want to
> install the header files so that you can build things (another
> extension) that somehow interacts with those extensions. Then, even if
> you put things in separate directories per extension, you
On Thu, Jul 19, 2018 at 3:42 PM, Andres Freund wrote:
> I don't think this reasoning actually applies for making HOT pruning
> weaker as necessary for decoding. The xmin horizon on catalog tables is
> already pegged, which'd prevent similar problems.
That sounds completely wrong to me. Setting
Robert Haas writes:
> I also think your other question is a good one. It seems like the
> fact that we need to reconnect -- rather than just prompting for the
> password and then sending it when we get it -- is an artifact of how
> libpq is designed rather than an intrinsic limitation of the
On Sun, Jul 22, 2018 at 7:14 PM, Fabien COELHO wrote:
> I noticed that hash functions appear twice in the list of pgbench functions,
> although once is enough. The code is functional nevertheless, but it looks
> silly. This was added by "e51a04840a1" back in March, so should be removed
> from 11
On Mon, Jul 23, 2018 at 11:20 PM, Andres Freund wrote:
> Hi,
>
> On 2018-07-23 18:31:43 +0900, Amit Langote wrote:
>> It seems that because enable_partition_pruning's value is only checked
>> during planning, turning it off *after* a plan is created and cached does
>> not work as expected.
[ ...
Hi,
On 2018-07-23 11:40:41 -0400, Bruce Momjian wrote:
> Sun Microsystems seemed reasonably trustworthy too.
I don't really agree with that characterization (they've a long history
of weird behaviour around open source, LONG before the Oracle
acquisition). But it doesn't really matter, as
On Mon, Jul 23, 2018 at 11:40:41AM -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> > I'm fairly sure that I'm right. But my point isn't that we should "trust
> > Andres implicitly ™" (although that's obviously not a bad starting point
> > ;)). But
Hi Andres,
>> We can find out if the snapshot is a logical decoding one by virtue of
>> its "satisfies" function pointing to HeapTupleSatisfiesHistoricMVCC.
>
> I think we even can just do something like a global
> TransactionId check_if_transaction_is_alive = InvalidTransactionId;
> and just
On Mon, Jul 23, 2018 at 08:19:35AM -0700, Andres Freund wrote:
> I'm fairly sure that I'm right. But my point isn't that we should "trust
> Andres implicitly ™" (although that's obviously not a bad starting point
> ;)). But rather, given that that is a reasonable assumption that such
> agreements
On Sun, Jul 22, 2018 at 4:42 PM, Fabien COELHO wrote:
> Basically I'm against having something called YCSB if it is not YCSB;-)
Yep, that seems pretty clear.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> "Peter" == Peter Eisentraut writes:
Peter> Nobody said anything about one-file-per-extension. You can of
Peter> course have hstore_this.h and hstore_that.h or if you want to
Peter> have many, use postgis/this.h and postgis/that.h.
So now you want the extension to be able to
On Thu, Jul 19, 2018 at 7:17 PM, Jeremy Schneider wrote:
> I'd like to bump this old bug that Lloyd filed for more discussion. It
> seems serious enough to me that we should at least talk about it.
>
> Anyone with simply the login privilege and the ability to run SQL can
> instantly block all new
On Mon, Jul 23, 2018 at 11:20:46AM -0400, Robert Haas wrote:
> On Sun, Jul 22, 2018 at 9:35 AM, Fabien COELHO wrote:
> > Otherwise ISTM that "-W/--password" still has some minimal value thus does
> > not deserve to be thrown out that quickly.
>
> I think I agree. I don't think this option is
Hi,
On 2018-07-23 17:11:30 +0200, David Fetter wrote:
> Yet again, you are assuming contrary to reality that you can simply
> read and understand how legal code will operate without court cases to
> back it.
Oh, FFS. You're implying serious bad faith here (and not just on my
part, but also on
On 23.07.18 06:15, Tom Lane wrote:
> Michael Paquier writes:
>> On Sun, Jul 22, 2018 at 09:42:08PM -0400, Stephen Frost wrote:
>>> So, +1 from me for having a directory for each extension.
>
>> So, like Stephen, that's a +1 from me.
>
> Same here. One-file-per-extension is too strongly biased
On Sun, Jul 22, 2018 at 9:35 AM, Fabien COELHO wrote:
> Otherwise ISTM that "-W/--password" still has some minimal value thus does
> not deserve to be thrown out that quickly.
I think I agree. I don't think this option is really hurting
anything, so I'm not quite sure why we would want to
On 2018-07-23 11:06:25 -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2018-07-23 16:32:55 +0200, David Fetter wrote:
> > > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > > > On July 23, 2018 6:25:42 AM PDT, Bruce
On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-07-23 16:32:55 +0200, David Fetter wrote:
> > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian wrote:
> > > >Notice this makes no mention of what
On Wed, Jul 18, 2018 at 11:19 PM, Tom Lane wrote:
> Sorry, I don't buy that line of argument. The *only* reason for this
> feature to exist is if it allows ready creation of security solutions
> that are actually more secure than a non-world-readable .pgpass file.
> That's a much higher bar than
On 23.07.18 15:14, Andrey Klychkov wrote:
> Moreover, if you rename Table without query locking, it may crushes your
> services that
> do queries at the same time, therefore, this is unlikely that someone
> will be do it
> with concurrent queries to renamed table, in other words, with running
>
On Mon, Jul 23, 2018 at 07:59:20AM -0700, Andres Freund wrote:
> Hi,
>
> On 2018-07-23 16:32:55 +0200, David Fetter wrote:
> > On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian wrote:
> > > >Notice this makes no mention of what
Hi,
On 2018-07-23 16:32:55 +0200, David Fetter wrote:
> On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian wrote:
> > >Notice this makes no mention of what happens to the patents if the
> > >company goes bankrupt. My guess is that
On Mon, Jul 23, 2018 at 10:42:11AM -0400, Chapman Flack wrote:
> On 07/23/2018 10:25 AM, Bruce Momjian wrote:
>
> >> Isn't 'defensive', in patent-speak, used to mean 'establishing prior
> >> art usable to challenge future patent claims by others on the same
> >> technique'?
> >>
> >> Is there any
On 07/23/2018 10:25 AM, Bruce Momjian wrote:
>> Isn't 'defensive', in patent-speak, used to mean 'establishing prior
>> art usable to challenge future patent claims by others on the same
>> technique'?
>>
>> Is there any way that conditions of use, or lack of them, on an
>> existing patent, would
Hello
23.07.2018, 17:08, "Tom Lane" :
> Sergei Kornilov writes:
>> Please test with logging command tag %i in log_line_prefix. Extended
>> protocol has three different messages, each can be canceled by timeout. But
>> here is completely no parameters in PARSE and i did not change BIND in
On Sat, Jul 21, 2018 at 4:22 AM, Michael Paquier wrote:
> On Sat, Jul 21, 2018 at 09:38:38AM +0300, Sergei Kornilov wrote:
>> Currently log_autovacuum_min_duration log message has no difference
>> between regular autovacuum and to prevent wraparound autovacuum. There
>> are important differences,
On Mon, Jul 23, 2018 at 07:32:34AM -0700, Andres Freund wrote:
> On 2018-07-23 10:27:10 -0400, Bruce Momjian wrote:
> > On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote:
> > > On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote:
> > > > They can say whatever they want, but if they are
On Fri, Jul 20, 2018 at 4:53 AM, Heikki Linnakangas wrote:
> ISTM that no-one has any great ideas on what to do about the ereport() in
> quickdie(). But I think we have consensus on replacing the exit(2) calls
> with _exit(2). If we do just that, it would be better than the status quo,
> even if
On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> On July 23, 2018 6:25:42 AM PDT, Bruce Momjian wrote:
> >Notice this makes no mention of what happens to the patents if the
> >company goes bankrupt. My guess is that in such a situation the
> >company
> >would have no control over
On 2018-07-23 10:27:10 -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote:
> > On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote:
> > > They can say whatever they want, but if they are bankrupt, what they say
> > > doesn't matter much. My guess is that
On 7/22/18, 10:12 PM, "Michael Paquier" wrote:
> The refactoring for CLUSTER is pretty obvious, and makes the API a bit
> cleaner, so attached is a proposal of patch to do so. Thoughts?
Sorry for the delay on these patches! This is nearly identical to
what I started writing last night, so it
On Mon, Jul 23, 2018 at 07:08:32AM -0700, Andres Freund wrote:
> On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote:
> > They can say whatever they want, but if they are bankrupt, what they say
> > doesn't matter much. My guess is that they would have to give their
> > patents to some legal entity
On 2018-07-23 19:37:46 +0530, Nikhil Sontakke wrote:
> Hi Andres,
>
> >> > what I'm proposing is that that various catalog access functions throw a
> >> > new class of error, something like "decoding aborted transactions".
> >>
> >> When will this error be thrown by the catalog functions? How
On Mon, Jul 23, 2018 at 10:13:48AM -0400, Chapman Flack wrote:
> On 07/23/2018 10:01 AM, Bruce Momjian wrote:
>
> > And the larger question is whether a patent free for use by software
> > under any license can be used in a defensive way. If not, it means we
> > have no way forward here.
>
>
On Mon, Jul 23, 2018 at 5:12 PM Arthur Zakirov wrote:
> On Mon, Jul 23, 2018 at 04:30:43PM +0300, Arthur Zakirov wrote:
> > I looked for some tradeoffs of the patch. I think it could be parsing
> > strings like the following input strings:
> >
> > SELECT TO_TIMESTAMP('2011年5月1日', '-MM-DD');
>
Hi,
On 2018-07-23 18:31:43 +0900, Amit Langote wrote:
> It seems that because enable_partition_pruning's value is only checked
> during planning, turning it off *after* a plan is created and cached does
> not work as expected.
>
> create table p (a int) partition by list (a);
> create table p1
On 07/23/2018 10:01 AM, Bruce Momjian wrote:
> And the larger question is whether a patent free for use by software
> under any license can be used in a defensive way. If not, it means we
> have no way forward here.
Isn't 'defensive', in patent-speak, used to mean 'establishing prior
art usable
On Mon, Jul 23, 2018 at 04:30:43PM +0300, Arthur Zakirov wrote:
> I looked for some tradeoffs of the patch. I think it could be parsing
> strings like the following input strings:
>
> SELECT TO_TIMESTAMP('2011年5月1日', '-MM-DD');
> SELECT TO_TIMESTAMP('2011y5m1d', '-MM-DD');
>
> HEAD
On 2018-07-23 09:56:47 -0400, Bruce Momjian wrote:
> On Mon, Jul 23, 2018 at 06:31:14AM -0700, Andres Freund wrote:
> > On July 23, 2018 6:25:42 AM PDT, Bruce Momjian wrote:
> > >On Mon, Jul 9, 2018 at 08:29:08AM +, Tsunakawa, Takayuki wrote:
> > >> Thank you for supporting me, Andres. And
Hi Andres,
>> > what I'm proposing is that that various catalog access functions throw a
>> > new class of error, something like "decoding aborted transactions".
>>
>> When will this error be thrown by the catalog functions? How will it
>> determine that it needs to throw this error?
>
> The
Sergei Kornilov writes:
> Please test with logging command tag %i in log_line_prefix. Extended protocol
> has three different messages, each can be canceled by timeout. But here is
> completely no parameters in PARSE and i did not change BIND in first patch.
This patch scares me to death. It
On Mon, Jul 23, 2018 at 09:53:26AM -0400, Bruce Momjian wrote:
> On Tue, Jul 10, 2018 at 09:47:09AM -0400, Tom Lane wrote:
> > The core team has considered this matter, and has concluded that it's
> > time to establish a firm project policy that we will not accept any code
> > that is known to be
On Tue, Jul 10, 2018 at 08:20:53AM +, Tsunakawa, Takayuki wrote:
> > One possible answer is that you wouldn't. But that might reduce the
> > size of the community, or lead to a fork.
>
> Yes, that's one unfortunate future, which I don't want to happen
> of course. I believe PostgreSQL should
Michael Paquier writes:
> This does not need a configure switch.
It probably is there because the OP realizes that most people wouldn't
accept having this code compiled in.
> What's the performance penalty? I am pretty sure that this is
> measurable as wait events are stored for a backend for
1 - 100 of 144 matches
Mail list logo
