Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 29 Aug 2016 12:10 PM, "Jim Nasby" wrote: > > On 8/26/16 4:08 PM, Andres Freund wrote: >> >> Splitting of ephemeral data seems to have a benefit, the rest seems more >> like rather noisy busywork to me. > > > People accidentally blowing away pg_clog or pg_xlog is a

Re: [HACKERS] patch proposal

On Fri, Aug 26, 2016 at 10:58 PM, Stephen Frost wrote: > * Venkata B Nagothi (nag1...@gmail.com) wrote: > > On Fri, Aug 26, 2016 at 12:30 PM, Stephen Frost > wrote: > > > * Venkata B Nagothi (nag1...@gmail.com) wrote: > > > > This behaviour will be

Re: [HACKERS] WAL consistency check facility

Thank you. I've updated it accordingly. On Sun, Aug 28, 2016 at 11:20 AM, Peter Geoghegan wrote: > On Sat, Aug 27, 2016 at 9:47 PM, Amit Kapila wrote: >> Right, I think there is no need to mask all the flags. However apart >> from BTP_HAS_GARBAGE, it

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On 8/26/16 4:08 PM, Andres Freund wrote: Splitting of ephemeral data seems to have a benefit, the rest seems more like rather noisy busywork to me. People accidentally blowing away pg_clog or pg_xlog is a pretty common occurrence, and I don't think there's all that many tools that reference

Re: [HACKERS] Why is a newly created index contains the invalid LSN?

On 8/26/16 4:17 PM, Andres Freund wrote: On 2016-08-26 18:46:42 +0300, Yury Zhuravlev wrote: Thanks all. Now understand LSN strongly connected with WAL. However how difficult put last system LSN instead 0? It's not so important but will allow make use LSN more consistent. Maybe explain why

Re: [HACKERS] PostgreSQL Version 10, missing minor version

On 2016-08-29 11:41:00 +0800, Craig Ringer wrote: > On 29 August 2016 at 02:52, Tom Lane wrote: > > "Regina Obe" writes: > >> The routine in PostGIS to parse out the version number from pg_config is > >> breaking in the 10 cycle > > > > TBH, I wonder why you

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

Hi, On 2016-08-29 11:25:39 +0800, Craig Ringer wrote: > ERROR: could not access status of transaction 778793573 > DETAIL: could not open file "pg_clog/02E6": No such file or directory > > What I'd really like is to be able to ask transam.c to handle the > xid_in_recent_past logic, treating

Re: [HACKERS] PostgreSQL Version 10, missing minor version

On 29 August 2016 at 02:52, Tom Lane wrote: > "Regina Obe" writes: >> The routine in PostGIS to parse out the version number from pg_config is >> breaking in the 10 cycle > > TBH, I wonder why you are doing that in the first place; it does not > seem like the

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 24 August 2016 at 03:10, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 12:59 PM, Craig Ringer wrote: > > Also fine by me. You're right, keep it simple. It means the potential set of > > values isn't discoverable the same way, but ... meh. Using

[HACKERS] VACUUM's ancillary tasks

On Monday, 29 August 2016, Andres Freund > wrote: > Hi, > > On 2016-08-29 03:26:06 +0200, Vik Fearing wrote: > > The attached two patches scratch two itches I've been having for a > > while. I'm attaching them together

Re: [HACKERS] VACUUM's ancillary tasks

Hi, On 2016-08-29 03:26:06 +0200, Vik Fearing wrote: > The attached two patches scratch two itches I've been having for a > while. I'm attaching them together because the second depends on the first. > > Both deal with the fact that [auto]vacuum has taken on more roles than > its original

[HACKERS] PassDownLimitBound for ForeignScan/CustomScan

Hello, The attached patch adds an optional callback to support special optimization if ForeignScan/CustomScan are located under the Limit node in plan-tree. Our sort node wisely switches the behavior when we can preliminary know exact number of rows to be produced, because all the Sort node has

[HACKERS] Sample configuration files

We have sample configuration files for postgresql.conf and recovery.conf, but we do not have them for contrib modules. This patch attempts to add them. Although the patch puts the sample configuration files in the tree, it doesn't try to install them. That's partly because I think it would need

[HACKERS] VACUUM's ancillary tasks

The attached two patches scratch two itches I've been having for a while. I'm attaching them together because the second depends on the first. Both deal with the fact that [auto]vacuum has taken on more roles than its original purpose. Patch One: autovacuum insert-heavy tables If you have a

[HACKERS] comment fix for CUSTOMPATH_* flags

Hello, I noticed the source code comment around CustomPath structure says "see above" for definition of CUSTOMPATH_* flags. It was originally right, but it was moved to nodes/extensible.h on the further development. So, no comments are above. The attached patch corrects the comment for the right

[HACKERS] Reminder: 9.6rc1 wraps tomorrow

Just making sure everyone's on the same page. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

On Mon, Aug 22, 2016 at 10:19 AM, Robert Haas wrote: > On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: > > Jeff Janes writes: > >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > >>> It does know it, what

Re: [HACKERS] src/include/catalog/pg_foreign_table.h still refers genbki.sh

Tomas Vondra writes: > I've noticed the comment in src/include/catalog/pg_foreign_table.h still > talks about genbki.sh, but AFAIK it was replaced with genbki.pl. Hmm, somebody must have copied-and-pasted this header comment from some old catalog include file.

Re: [HACKERS] RLS related docs

On 05/30/2016 01:56 PM, Joe Conway wrote: > On 05/26/2016 12:26 AM, Dean Rasheed wrote: >> On 25 May 2016 at 02:04, Joe Conway wrote: >>> Please see attached two proposed patches for the docs related to RLS: >>> >>> 1) Correction to pg_restore >>> 2) Additional mentions that

Re: [HACKERS] PostgreSQL Version 10, missing minor version

"Regina Obe" writes: > The routine in PostGIS to parse out the version number from pg_config is > breaking in the 10 cycle TBH, I wonder why you are doing that in the first place; it does not seem like the most reliable source of version information. If you need to do

Re: [HACKERS] PostgreSQL Version 10, missing minor version

On 08/28/2016 09:55 AM, Regina Obe wrote: > The routine in PostGIS to parse out the version number from pg_config is > breaking in the 10 cycle. > > Issue seems to be because there is no minor specified. > > e.g. > > pgconfig --version > > returns: > > PostgreSQL 10devel > > Instead of

[HACKERS] PostgreSQL Version 10, missing minor version

The routine in PostGIS to parse out the version number from pg_config is breaking in the 10 cycle. Issue seems to be because there is no minor specified. e.g. pgconfig --version returns: PostgreSQL 10devel Instead of expected PostgreSQL 10.0devel Is this the way it's going to be or will

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

On 08/28/2016 04:59 PM, Tom Lane wrote: Tomas Vondra writes: I'm however pretty sure this will have absolutely no impact on profiles. Yeah, I do not believe that either. Also, I think that the intent of the existing code is to defend against bad parameters even

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

Tomas Vondra writes: > I'm however pretty sure this will have absolutely no impact on profiles. Yeah, I do not believe that either. Also, I think that the intent of the existing code is to defend against bad parameters even in non-assert builds. Which might argue

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

On 08/28/2016 04:41 PM, Tom Lane wrote: Robert Haas writes: Also, I think we ought to replace this code in aset.c: initBlockSize = MAXALIGN(initBlockSize); if (initBlockSize < 1024) initBlockSize = 1024; maxBlockSize = MAXALIGN(maxBlockSize);

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

On 08/28/2016 04:41 PM, Tom Lane wrote: Robert Haas writes: Also, I think we ought to replace this code in aset.c: initBlockSize = MAXALIGN(initBlockSize); if (initBlockSize < 1024) initBlockSize = 1024; maxBlockSize = MAXALIGN(maxBlockSize);

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

Robert Haas writes: > Also, I think we ought to replace this code in aset.c: > initBlockSize = MAXALIGN(initBlockSize); > if (initBlockSize < 1024) > initBlockSize = 1024; > maxBlockSize = MAXALIGN(maxBlockSize); > With this: >

Re: [HACKERS] increasing the default WAL segment size

On Fri, Aug 26, 2016 at 4:45 AM, Eduardo Morras wrote: > From my ignorance, could block size affect this WAL size increase? > > In past (didn't tried with >9 versions) you can change disk block page size > from 8KB to 16 KB or 32KB (or 4) modifing src/include/pg_config.h

Re: [HACKERS] increasing the default WAL segment size

On Fri, Aug 26, 2016 at 12:39 AM, Andres Freund wrote: > Maybe I'm missing something here - but why would we need to do any of > that? The WAL already isn't compatible between versions, and we don't > reuse the old server's WAL anyway? Isn't all that's needed relaxing some >

Re: [HACKERS] Checksum error and VACUUM FULL

On Thu, Aug 25, 2016 at 5:45 AM, Tatsuki Kadomoto < tatsuki.kadom...@proceranetworks.com> wrote: > I faced incorrect checksum on "global/pg_filenode.map" at the right > timing "VACUUM FULL" is executed and session was aborted. > > Aug 16 20:51:19 postgres[22329]: [2-1] FATAL: relation mapping

Re: [HACKERS] Bogus sizing parameters in some AllocSetContextCreate calls

On Sat, Aug 27, 2016 at 2:08 PM, Tom Lane wrote: > The standard calling pattern for AllocSetContextCreate is > > cxt = AllocSetContextCreate(parent, name, > ALLOCSET_DEFAULT_MINSIZE, >

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova wrote: @@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState *state, IndexTuple itup) if (last_off == P_HIKEY) { Assert(state->btps_minkey == NULL); - state->btps_minkey =