On Sun, Oct 21, 2018 at 11:24 PM Tom Lane wrote:
>
> Oleg Bartunov writes:
> > The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years
> > old, may be we could remove deprecated @@@ operator ?
>
> Is it actually causing any problem? AFAICS it's just a couple extra
> pg_operator
On Mon, Oct 22, 2018 at 11:10:09AM +0530, Dilip Kumar wrote:
> As part of the security fix
> (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the
> users from accessing the statistics of the table if the user doesn't
> have privileges on the table and the function is not leakproof.
>
Greetings,
* Dilip Kumar (dilipbal...@gmail.com) wrote:
> As part of the security fix
> (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the
> users from accessing the statistics of the table if the user doesn't
> have privileges on the table and the function is not leakproof. Now,
As part of the security fix
(e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the
users from accessing the statistics of the table if the user doesn't
have privileges on the table and the function is not leakproof. Now,
as a side effect of this, if the user has the privileges on the
Hi
ne 21. 10. 2018 v 21:47 odesílatel Paul A Jungwirth <
p...@illuminatedcomputing.com> napsal:
> On Sun, Oct 21, 2018 at 12:11 PM Heikki Linnakangas
> wrote:
> > On 21/10/2018 21:17, Paul A Jungwirth wrote:
> > > 3. Build our own abstractions on top of ranges, and then use those to
> > >
Hello.
At Fri, 12 Oct 2018 06:19:12 +, "Ideriha, Takeshi"
wrote in
<4E72940DA2BF16479384A86D54D0988A6F1C1779@G01JPEXMBKW04>
> Hi, let me clarify my understanding about the $title.
>
> It seems that the number of hash partitions is fixed at 128 in dshash and
> right now we cannot change it
Andres Freund writes:
> On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
>> (Well, I see the short answer: the code layer throwing the error
>> doesn't know. But that could be fixed easily enough.)
> I wonder if the better approach wouldn't be to add an errcontext for
> vaccuum, where continually
(moving to -hackers)
On Sun, Oct 14, 2018 at 10:42:40AM -0700, Andres Freund wrote:
> I'm unhappy this approach was taken over objections. Without a real
> warning.
Oops, that was not clear to me. Sorry about that! I did not see you
objecting again after the last arguments I raised. The end
Hi,
On 2018/10/22 11:09, Michael Paquier wrote:
> On Fri, Oct 19, 2018 at 06:46:15PM +0900, Amit Langote wrote:
>> Thanks. Attached a patch to set relhassubclass when an index partition is
>> added to a partitioned index.
>
> Thanks, committed after adding a test with ALTER TABLE ONLY, and
>
On Fri, Oct 19, 2018 at 06:46:15PM +0900, Amit Langote wrote:
> Thanks. Attached a patch to set relhassubclass when an index partition is
> added to a partitioned index.
Thanks, committed after adding a test with ALTER TABLE ONLY, and
checking upgrades as well as ATTACH partition for ALTER INDEX
Hi,
On 2018-10-21 10:24:16 -0400, Tom Lane wrote:
> =?UTF-8?Q?Johannes_Gra=c3=abn?= writes:
> > after upgrading to version 11, I see the error pattern "found xmin x
> > from before relfrozenxid y" in different databases on different hosts.
> > From
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Oct 21, 2018 at 11:03:30AM -0400, Stephen Frost wrote:
> > This doesn't change my opinion of the bigger question though, which is
> > to what extent we should be implicitly supporting extensions and
> > whatever else putting
From: Adelino Silva [mailto:adelino.j.si...@googlemail.com]
> What is the advantage to use archive_mode = always in a slave server compared
> to archive_mode = on (shared WAL archive) ?
>
> I only see duplication of Wal files, what is the purpose of this feature ?
This also saves you the network
On Sun, Oct 21, 2018 at 11:03:30AM -0400, Stephen Frost wrote:
> This doesn't change my opinion of the bigger question though, which is
> to what extent we should be implicitly supporting extensions and
> whatever else putting files into the database and tablespace
> directories.
Well, the whole
I agree with your arguments, and if instead we put an option to disable
this before compiling or a set in the psql cli?
On Sun, Oct 21, 2018, 20:20 Tom Lane wrote:
> Renato dos Santos writes:
> > I have been using psql for quite a few days. And I have accidentally
> pressed the CTRL + \ keys
Renato dos Santos writes:
> I have been using psql for quite a few days. And I have accidentally pressed
> the CTRL + \ keys that sends the signal QUIT+Coredump (CTRL+4 also sends the
> same signal).
> I hope it's relevant to more people. (This has bothered me.)
> this patch avoids the output
On Thu, Oct 18, 2018 at 6:28 AM Haribabu Kommi wrote:
> On Tue, Oct 16, 2018 at 6:06 AM Alexander Korotkov
> wrote:
>> * 0002-add-costing-function-to-API.patch – adds function for costing
>> sequential and table sample scan to tableam API. zheap costing
>> function are now copies of heap
On 17/08/2018 06:47, Andrey Lepikhov wrote:
I propose the patch for fix one small code defect.
The XLogReadRecord() function reads the pages of a WAL segment that
contain a WAL-record. Then it creates a readRecordBuf buffer in private
memory of a backend and copy record from the pages to the
Oleg Bartunov writes:
> The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years
> old, may be we could remove deprecated @@@ operator ?
Is it actually causing any problem? AFAICS it's just a couple extra
pg_operator entries, so why not leave it?
I'd be +1 for removing it from the
Hello,
The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years
old, may be we could remove deprecated @@@ operator ?
Author: Tom Lane
Date: Mon Apr 14 17:05:34 2008 +
Push index operator lossiness determination down to GIST/GIN opclass
"consistent" functions, and
On Sun, Oct 21, 2018 at 12:11 PM Heikki Linnakangas wrote:
> On 21/10/2018 21:17, Paul A Jungwirth wrote:
> > 3. Build our own abstractions on top of ranges, and then use those to
> > implement PERIOD-based features.
> +1 on this approach. I think [7] got the model right. If we can
> implement
On 21/10/2018 21:17, Paul A Jungwirth wrote:
3. Build our own abstractions on top of ranges, and then use those to
implement PERIOD-based features. This is the least clear option, and I
imagine it would require a lot more design effort. Our range types are
already a step in this direction. Does
On Sun, 21 Oct 2018 at 14:18, Paul A Jungwirth
wrote:
> Also, just how strictly do we have to follow the standard? Requiring
> sentinels like '01 JAN 3000` just seems so silly. Could Postgres
> permit nullable start/end PERIOD columns, and give them the same
> meaning as ranges (unbounded)? Even
Hello,
I'm interested in contributing some temporal database functionality to
Postgres, starting with temporal primary and foreign keys. I know some
other folks nearby interested in helping out, too. But before we begin
I'd like to ask the community about complying with the SQL:2011
standard [1]
Hello,I have been using psql for quite a few days. And I have accidentally pressed the CTRL + \ keys that sends the signal QUIT+Coredump (CTRL+4 also sends the same signal).I hope it's relevant to more people. (This has bothered me.)this patch avoids the output of the CLI using ctrl + \ is the
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> This is a follow-up of the following thread:
> https://www.postgresql.org/message-id/20181012010411.re53cwcistcpi...@alap3.anarazel.de
Thanks for starting this thread Michael.
> pg_verify_checksums used first a blacklist to decide if
=?UTF-8?Q?Johannes_Gra=c3=abn?= writes:
> after upgrading to version 11, I see the error pattern "found xmin x
> from before relfrozenxid y" in different databases on different hosts.
> From https://www.postgresql.org/docs/10/static/release-10-3.html, I
> learned that this was an error caused by
Hi all,
This is a follow-up of the following thread:
https://www.postgresql.org/message-id/20181012010411.re53cwcistcpi...@alap3.anarazel.de
In a nutshell, b34e84f1 has added TAP tests for pg_verify_checksums, and
the buildfarm has immediately complained about files generated by
EXEC_BACKEND
28 matches
Mail list logo
