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 miss
=?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 p
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 fi
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 same
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] f
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
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 a
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 SQL
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 re
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
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 read
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 costi
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 o
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 th
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 p
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
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 files
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 https://www.postgresql.org/docs/10/static/releas
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/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
> che
(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 of
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 u
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
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
> > > implem
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 r
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,
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.
>
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 ent
On Sat, Oct 20, 2018 at 01:48:56PM +0900, Michael Paquier wrote:
> On Sat, Oct 20, 2018 at 06:24:28AM +0200, Laurenz Albe wrote:
>> Here is another version, with a fix in pg_proc.dat, an improved comment
>> and "wait_seconds" exercised in the regression test.
>
> Thanks for the new version. This
Hi,
On 2018/10/22 14:41, Stephen Frost wrote:
> 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 privileg
On 10/16/18, Amit Kapila wrote:
> I think we can avoid using prevBlockNumber and try_every_block, if we
> maintain a small cache which tells whether the particular block is
> tried or not. What I am envisioning is that while finding the block
> with free space, if we came to know that the relatio
31 matches
Mail list logo
