Re: [HACKERS] Priority table or Cache table

On Tue, Aug 11, 2015 at 11:31 AM, Haribabu Kommi wrote: > On Mon, Aug 10, 2015 at 3:09 PM, Amit Kapila > wrote: > > On Thu, Aug 6, 2015 at 12:24 PM, Haribabu Kommi < > kommi.harib...@gmail.com> > > wrote: > > > > What is the configuration for test (RAM of m/c, shared_buffers, > > scale_factor, e

Re: [HACKERS] max_connections and standby server

Michael Paquier writes: > On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane wrote: >> Somebody refresh my memory as to why we have this restriction (that is, >> slave's max_connections >= master's max_connections) in the first place? >> Seems like it should not be a necessary requirement, and working tow

Re: [HACKERS] Priority table or Cache table

On Mon, Aug 10, 2015 at 3:09 PM, Amit Kapila wrote: > On Thu, Aug 6, 2015 at 12:24 PM, Haribabu Kommi > wrote: > > What is the configuration for test (RAM of m/c, shared_buffers, > scale_factor, etc.)? Here are the details: CPU - 16 core, RAM - 252 GB shared_buffers - 1700MB, buffer_cache_rati

Re: [HACKERS] max_connections and standby server

On Tue, Aug 11, 2015 at 2:57 PM, Michael Paquier wrote: > On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane wrote: >> Tatsuo Ishii writes: >>> I think this is because pg_control on the standby remembers that the >>> previous primary server's max_connections = 1100 even if the standby >>> server fails to

Re: [HACKERS] max_connections and standby server

On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane wrote: > Tatsuo Ishii writes: >> I think this is because pg_control on the standby remembers that the >> previous primary server's max_connections = 1100 even if the standby >> server fails to start. Shouldn't we update pg_control file only when >> standb

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Aug 11, 2015 at 1:50 AM, Alvaro Herrera wrote: > Masahiko Sawada wrote: > >> This topic may have been already discussed but, why don't we use just >> total scanned pages and total pages? > > Because those numbers don't extrapolate nicely. If the density of dead > tuples is irregular acros

Re: [HACKERS] max_connections and standby server

> Somebody refresh my memory as to why we have this restriction (that is, > slave's max_connections >= master's max_connections) in the first place? > Seems like it should not be a necessary requirement, and working towards > getting rid of it would be far better than any other answer. If you care

Re: [HACKERS] max_connections and standby server

Tatsuo Ishii writes: > I think this is because pg_control on the standby remembers that the > previous primary server's max_connections = 1100 even if the standby > server fails to start. Shouldn't we update pg_control file only when > standby succeeds to start? Somebody refresh my memory as to w

Re: [HACKERS] linux sparc compile issue

Hi Tom, Tom Lane wrote, > Waldemar Brodkorb writes: > > while doing regular builds via buildroot autobuilders > > a compile problem for sparc 32bit v8 was found. > > It seems the defines for Linux are other than for Solaris. > > > Following patch fixes it for buildroot: > > The gcc predefines fo

[HACKERS] max_connections and standby server

Today I encountered an interesting situation. 1) A streaming replication primary server and a standby server is running. At this point max_connections = 100 on both servers. 2) Shutdown both servers. 3) Change max_connections to 1100 on both servers and restart both servers. 4) The primar

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

On 08/10/2015 07:29 PM, Tom Lane wrote: I wrote: Peter Eisentraut writes: This was probably just copied from how proacl and lanacl are handled, which predate typacl by quite a bit. Maybe there was a reason in those days. Hm ... I wonder whether those are well-thought-out either. They're n

Re: [HACKERS] fix oversight converting buf_id to Buffer

On Mon, Aug 10, 2015 at 4:15 PM, Andres Freund wrote: > > That's a very nice catch! Did you trigger the error or just found it > when reading the code? > My fellow colleagues hit the issue during some stress: I am not clear the exact repro but from the failed assertion, the cause is kinda clear.

Re: [HACKERS] [patch] A \pivot command for psql

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2015 04:03 PM, David Fetter wrote: >> I am wrong on that? I feel like you guys are all telling me that >> \pivot should happen on the server, but the point that it would >> not be realistic to begin with is not considered. > > I think that s

Re: [HACKERS] checkpointer continuous flushing

On Tue, Aug 11, 2015 at 4:28 AM, Andres Freund wrote: > On August 10, 2015 8:24:21 PM GMT+02:00, Fabien COELHO wrote: >>> You can't allocate 4GB with palloc(), it has a builtin limit against >>> allocating more than 1GB. >> >>Argh, too bad, I assumed very naively that palloc was malloc in >>disguis

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

I wrote: > Peter Eisentraut writes: >> This was probably just copied from how proacl and lanacl are handled, >> which predate typacl by quite a bit. Maybe there was a reason in those >> days. > Hm ... I wonder whether those are well-thought-out either. They're not. Testing with ancient servers

Re: [HACKERS] fix oversight converting buf_id to Buffer

Hi, That's a very nice catch! Did you trigger the error or just found it when reading the code? On 2015-08-10 12:12:01 -0700, Qingqing Zhou wrote: > Attached patch fixes oversights converting buf_id to Buffer in > PrintBufferDescs() and InvalidateBuffer(). Especially for the latter, > the reason

Re: [HACKERS] [patch] A \pivot command for psql

On Mon, Aug 10, 2015 at 07:10:41PM +0200, Daniel Verite wrote: > David Fetter wrote: > > > I'm working up a proposal to add (UN)PIVOT support to the back-end. > > I was under the impression that a server-side PIVOT *with dynamic > columns* was just unworkable as an SQL query, because it cou

Re: [HACKERS] ON CONFLICT DO UPDATE using EXCLUDED.column gives an error about mismatched types

On Wed, Aug 5, 2015 at 12:58 AM, Amit Langote wrote: > I forgot mentioning one thing later yesterday. The way exclRelTlist is > initialized, all the way in the beginning (transformOnConflictClause), is > most probably to blame. It uses expandRelAttrs() for other valid reasons; > but within it, exp

Re: [HACKERS] tap tests remove working directories

On 08/10/2015 10:32 AM, Andrew Dunstan wrote: On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/09/2015 08:58 PM, Michael Paquier wrote: Sure. Attached is what I have in mind. Contrary to your version we keep around temp paths should a run succeed after one that has fai

Re: [HACKERS] linux sparc compile issue

On 2015-08-10 17:36:57 -0400, Tom Lane wrote: > Waldemar Brodkorb writes: > > while doing regular builds via buildroot autobuilders > > a compile problem for sparc 32bit v8 was found. > > It seems the defines for Linux are other than for Solaris. > > > Following patch fixes it for buildroot: > >

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

I wrote: > But now that you mention it, isn't that completely broken? What pg_dump > actually prints given this made-up data is > REVOKE ALL ON TYPE myshell FROM PUBLIC; > REVOKE ALL ON TYPE myshell FROM postgres; > GRANT ALL ON TYPE myshell TO PUBLIC; > which seems like a completely insane inte

Re: [HACKERS] linux sparc compile issue

Waldemar Brodkorb writes: > while doing regular builds via buildroot autobuilders > a compile problem for sparc 32bit v8 was found. > It seems the defines for Linux are other than for Solaris. > Following patch fixes it for buildroot: > The gcc predefines for Linux are __sparc_v8__/__sparc_v7__

Re: [HACKERS] [sqlsmith] subplan variable reference / unassigned NestLoopParams

Andreas Seltenreich writes: > Tom Lane writes: >> Andreas Seltenreich writes: >>> Tom Lane writes: Well, I certainly think all of these represent bugs: 3 | ERROR: plan should not reference subplan's variable 2 | ERROR: failed to assign all NestLoopParams to plan nodes >>> These

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

Peter Eisentraut writes: > On 8/9/15 6:23 PM, Tom Lane wrote: >> It looks to me like the reason for this is that pg_dump forces the >> "typacl" of a type to be '{=U}' when reading the schema data for a >> pre-9.2 type, rather than reading it as NULL (ie default permissions) >> which would result i

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

Having a freeze map would be wholly unnecessary if we don't ever need to freeze whole tables again. Freezing would still be needed on individual blocks where an old row has been updated or deleted; a freeze map would not help there either. So there is no conflict, but options 2) and 3) are complet

Re: [HACKERS] FSM versus GIN pending list bloat

On Tue, Aug 4, 2015 at 12:38 PM, Jeff Janes wrote: > On Tue, Aug 4, 2015 at 1:39 AM, Simon Riggs wrote: > >> On 4 August 2015 at 06:03, Jeff Janes wrote: >> >> >>> The attached proof of concept patch greatly improves the bloat for both >>> the insert and the update cases. You need to turn on b

Re: [HACKERS] Asynchronous execution on FDW

* Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Aug 10, 2015 at 3:23 AM, Heikki Linnakangas wrote: > > I've marked this as rejected in the commitfest, because others are > > working on a more general solution with parallel workers. That's still > > work-in-progress, and it's not certain if

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_dump to dump shell types.

On 8/9/15 6:23 PM, Tom Lane wrote: > It looks to me like the reason for this is that pg_dump forces the > "typacl" of a type to be '{=U}' when reading the schema data for a > pre-9.2 type, rather than reading it as NULL (ie default permissions) > which would result in not printing any grant/revoke

Re: [HACKERS] WIP: SCRAM authentication

* Robert Haas (robertmh...@gmail.com) wrote: > On Sat, Aug 8, 2015 at 1:23 PM, Heikki Linnakangas wrote: > > On 08/08/2015 04:27 PM, Robert Haas wrote: > >> I don't see that there's any good reason to allow the same password to > >> be stored in the catalog encrypted more than one way, > > > > Sur

Re: [HACKERS] checkpointer continuous flushing

On August 10, 2015 8:24:21 PM GMT+02:00, Fabien COELHO wrote: > >Hello Andres, > >> You can't allocate 4GB with palloc(), it has a builtin limit against >> allocating more than 1GB. > >Argh, too bad, I assumed very naively that palloc was malloc in >disguise. It is, but there's some layering (me

Re: [HACKERS] WIP: SCRAM authentication

On 08/09/2015 07:19 PM, Michael Paquier wrote: >> ... during my exchange with Michael, I was thinking about the bug >> > potential of taking the password field and multiplexing it in some way, >> > which is significant. There is a definite risk of "making this too >> > complicated" and we'll need

Re: [HACKERS] CREATE POLICY and RETURNING

Zhaomo, * Zhaomo Yang (zmp...@gmail.com) wrote: > This thread has a pretty thorough discussion of pros and cons of applying > SELECT policy to other commands. Besides what have been mentioned, I think > there is another potential pro: we can enable references to pseudorelations > OLD and NEW in pr

[HACKERS] fix oversight converting buf_id to Buffer

Attached patch fixes oversights converting buf_id to Buffer in PrintBufferDescs() and InvalidateBuffer(). Especially for the latter, the reason we haven't seen any reports of the issue might be that it needs certain concurrent conditions to be true. Along the line, it also changes all direct maths

Re: [HACKERS] checkpointer continuous flushing

Ok ok, I stop resisting... I'll have a look. Here is a v7 a&b version which uses shared memory instead of palloc. -- Fabien.diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index e900dcc..1cec243 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -2454,6 +

[HACKERS] linux sparc compile issue

Hi, while doing regular builds via buildroot autobuilders a compile problem for sparc 32bit v8 was found. It seems the defines for Linux are other than for Solaris. Following patch fixes it for buildroot: The gcc predefines for Linux are __sparc_v8__/__sparc_v7__ Signed-off-by: Waldemar Brodkor

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, You can't allocate 4GB with palloc(), it has a builtin limit against allocating more than 1GB. Argh, too bad, I assumed very naively that palloc was malloc in disguise. [...] Well, then everytime the checkpointer is restarted. Hm... The point is that it's done at postmast

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 08/10/2015 10:31 AM, Simon Riggs wrote: > Freezing is not a necessary pre-condition for either of those things, I > am happy to say. There is confusion here because for ( 1 ) the shrink > was performed after freezing, but when you have access to the epoch > there is no need for exhaustive freezi

Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao wrote: > On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita > wrote: > > > + { > > + {"pending_list_cleanup_size", PGC_USERSET, > > CLIENT_CONN_STATEMENT, > > + gettext_noop("Sets the maximum size of the > pending

Re: [HACKERS] [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Fri, Jun 19, 2015 at 07:10:40PM +0300, Marti Raudsepp wrote: > Hi list Sorry I am just getting this report. Thanks to the people who "stalled" for me. > One of my databases failed to upgrade successfully and produced this error in > the copying phase: > > error while copying relation "pg_cat

Re: [HACKERS] Commitfest remaining "Needs Review" items

* extends pgbench expressions with functions Robert signed up as reviewer for this a long time ago. Ping, do you still plan to review this? I seem to recall that I nominated Robert when adding the patch, because this is an extension of his expression patch. So the "sign up" is really just a

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 10 August 2015 at 18:02, Josh Berkus wrote: > There's a lesser version of this item which remains relevant unless we > implement (5). That is, currently the same autovacuum_vaccuum_delay > (AVVD) applies to regular autovacuums as does to anti-wraparound > autovacuums. If the user has set AV

Re: [HACKERS] checkpointer continuous flushing

On 2015-08-10 19:07:12 +0200, Fabien COELHO wrote: > I think that there is no issue with the current shared_buffers limit. I > could allocate and use 4 GB on my laptop without problem. I added a cast to > ensure that unsigned int are used for the size computation. You can't allocate 4GB with pallo

Re: [HACKERS] [patch] A \pivot command for psql

Tom Lane wrote: > I'm not sure how pushing it out to psql makes that better. There is > no way to do further processing on something that psql has printed, > so you've punted on solving that issue just as much if not more. It's the same spirit as \x : the only thing it achieves is better

[HACKERS] pg_dump and search_path

I earliest reference I found to this issue is here and refers to the search_path being arbitrarily set in the file created by pg_dump. This is apparently still the case in 9.4. I found this issue b

Re: [HACKERS] [patch] A \pivot command for psql

David Fetter wrote: > I'm working up a proposal to add (UN)PIVOT support to the back-end. I was under the impression that a server-side PIVOT *with dynamic columns* was just unworkable as an SQL query, because it couldn't be prepared if it existed. I am wrong on that? I feel like you guy

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, Thanks for your comments. Some answers and new patches included. + /* + * Array of buffer ids of all buffers to checkpoint. + */ +static int *CheckpointBufferIds = NULL; Should be at the beginning of the file. There's a bunch more cases of that. done. +/* Compare checkpoint

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

Simon, Thank you for this summary! I was losing track, myself. On 08/09/2015 11:03 PM, Simon Riggs wrote: > Freezing is painful for VLDBs and high transaction rate systems. We have > a number of proposals to improve things... > 3. Speed up autovacuums when they are triggered to avoid wraparound

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Masahiko Sawada wrote: > This topic may have been already discussed but, why don't we use just > total scanned pages and total pages? Because those numbers don't extrapolate nicely. If the density of dead tuples is irregular across the table, such absolute numbers might be completely meaningless

Re: [HACKERS] WIP: Rework access method interface

Alvaro Herrera writes: > Tom Lane wrote: >> I think that's likely for the best anyway; there are too many catalogs >> that think a pg_am OID identifies an index AM. Better to create other >> catalogs for other types of AMs. > That means we won't be able to reuse pg_class.relam as a pointer to th

Re: [HACKERS] Precedence of standard comparison operators

On 10 August 2015 at 16:31, Tom Lane wrote: > Pavel Stehule writes: > >> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote: > >>> So yeah, I do think that getting a syntax error if you don't use > >>> parentheses is the preferable behavior here. > > > If we raise a syntax error, then ther

Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-08-10 9:11 GMT+02:00 Heikki Linnakangas : > On 07/26/2015 08:34 AM, Pavel Stehule wrote: > >> Hi >> >> here is complete patch, that introduce context filtering on client side. >> The core of this patch is trivial and small - almost all of size are >> trivial changes in regress tests - removin

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > Petr Jelinek writes: > > On 2015-08-10 17:47, Tom Lane wrote: > >> I don't see any particularly good reason to remove amsupport and > >> amstrategies from pg_am. Those are closely tied to the other catalog > >> infrastructure for indexes (pg_amproc, pg_amop) which I don't think

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 18:16, Alvaro Herrera wrote: Tom Lane wrote: There are a couple of other pg_am columns, such as amstorage and amcanorderbyop, which similarly bear on what's legal to appear in related catalogs such as pg_opclass. I'd be sort of inclined to leave those in the catalog as well. I d

[HACKERS] How to compare different datums within from a tuple?

Hello, I try to write my first patch. It is too early to tell more about it, but I am just fiddling around with some prototypes. Can someone tell me, how I can compare two datum fields, when I do not know the data type in advance inside an executor function? For example, "x less than y" wher

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 18:08, Tom Lane wrote: Alexander Korotkov writes: On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane wrote: There are a couple of other pg_am columns, such as amstorage and amcanorderbyop, which similarly bear on what's legal to appear in related catalogs such as pg_opclass. I'd be sort

Re: [HACKERS] cache invalidation skip logic

On Sun, Aug 9, 2015 at 8:24 AM, Robert Haas wrote: > > In step 1, AcceptInvalidationMessages() should process all pending > invalidation messages. So if step 2 did AcceptInvalidationMessages() > again it would be a no-op, because no messages should remain at that > point. > That's what I think a

Re: [HACKERS] WIP: Rework access method interface

Tom Lane wrote: > There are a couple of other pg_am columns, such as amstorage and > amcanorderbyop, which similarly bear on what's legal to appear in > related catalogs such as pg_opclass. I'd be sort of inclined to > leave those in the catalog as well. I do not see that exposing > a SQL functi

Re: [HACKERS] GIN pageinspect functions

On Fri, Nov 21, 2014 at 2:04 AM, Heikki Linnakangas wrote: > On 11/20/2014 05:52 AM, Michael Paquier wrote: > >> On Wed, Nov 19, 2014 at 7:01 AM, Peter Geoghegan wrote: >> >>> On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila >>> wrote: >>> 1. Documentation seems to be missing, other API's exposed >>

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-08-10 17:47, Tom Lane wrote: >> I don't see any particularly good reason to remove amsupport and >> amstrategies from pg_am. Those are closely tied to the other catalog >> infrastructure for indexes (pg_amproc, pg_amop) which I don't think are >> candidates for gett

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane wrote: >> There are a couple of other pg_am columns, such as amstorage and >> amcanorderbyop, which similarly bear on what's legal to appear in >> related catalogs such as pg_opclass. I'd be sort of inclined to >> leave those

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 17:47, Tom Lane wrote: Petr Jelinek writes: On 2015-08-10 16:58, Alexander Korotkov wrote: That should work, thanks! Also we can have SQL-visible functions to get amsupport and amstrategies and use them in the regression tests. SQL-visible functions would be preferable to stor

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Tue, Aug 11, 2015 at 12:20 AM, Simon Riggs wrote: > On 10 August 2015 at 15:59, Syed, Rahila wrote: >> >> Hello, >> >> >When we're in Phase2 or 3, don't we need to report the number of total >> > page scanned or percentage of how many table pages scanned, as well? >> The total heap pages scann

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:47 PM, Tom Lane wrote: > Petr Jelinek writes: > > On 2015-08-10 16:58, Alexander Korotkov wrote: > >> That should work, thanks! Also we can have SQL-visible functions to get > >> amsupport and amstrategies and use them in the regression tests. > > > SQL-visible function

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-08-10 16:58, Alexander Korotkov wrote: >> That should work, thanks! Also we can have SQL-visible functions to get >> amsupport and amstrategies and use them in the regression tests. > SQL-visible functions would be preferable to storing it in pg_am as > keeping the

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 6:36 PM, Petr Jelinek wrote: > On 2015-08-10 16:58, Alexander Korotkov wrote: > >> That should work, thanks! Also we can have SQL-visible functions to get >> amsupport and amstrategies and use them in the regression tests. >> >> > SQL-visible functions would be preferable

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-10 16:58, Alexander Korotkov wrote: On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Alexander Korotkov mailto:a.korot...@postgrespro.ru>> writes: > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: >> I don't un

Re: [HACKERS] Precedence of standard comparison operators

Pavel Stehule writes: >> On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote: >>> So yeah, I do think that getting a syntax error if you don't use >>> parentheses is the preferable behavior here. > If we raise a syntax error, then there should be very informative message, Yeah, it would sur

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 10 August 2015 at 15:59, Syed, Rahila wrote: > Hello, > > >When we're in Phase2 or 3, don't we need to report the number of total > page scanned or percentage of how many table pages scanned, as well? > The total heap pages scanned need to be reported with phase 2 or 3. > Complete progress rep

Re: [HACKERS] checkpointer continuous flushing

Hi, On 2015-08-08 20:49:03 +0300, Heikki Linnakangas wrote: > I ripped out the "flushing" part, keeping only the sorting. I refactored the > logic in BufferSync() a bit. There's now a separate function, > nextCheckpointBuffer(), that returns the next buffer ID from the sorted > list. The tablespac

Re: [HACKERS] Asynchronous execution on FDW

On Mon, Aug 10, 2015 at 3:23 AM, Heikki Linnakangas wrote: > I've marked this as rejected in the commitfest, because others are > working on a more general solution with parallel workers. That's still > work-in-progress, and it's not certain if it's going to make it into > 9.6, but if it does it w

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, >When we're in Phase2 or 3, don't we need to report the number of total page >scanned or percentage of how many table pages scanned, as well? The total heap pages scanned need to be reported with phase 2 or 3. Complete progress report need to have numbers from each phase when applicable.

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 5:48 PM, Tom Lane wrote: > Alexander Korotkov writes: > > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek > wrote: > >> I don't understand this, there is already AmRoutine in RelationData, why > >> the need for additional field for just amsupport? > > > We need amsupport i

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

David Rowley writes: > On 10 August 2015 at 07:50, Tom Lane wrote: >> I've started to work on path-ification of the upper planner (finally), > I was digging around the grouping_planner() last week with the intentions > of making some changes there to allow GROUP BY before join, but in the end >

Re: [HACKERS] WIP: Rework access method interface

Alexander Korotkov writes: > On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek wrote: >> I don't understand this, there is already AmRoutine in RelationData, why >> the need for additional field for just amsupport? > We need amsupport in load_relcache_init_file() which reads > "pg_internal.init". I'

Re: [HACKERS] tap tests remove working directories

On 08/10/2015 09:55 AM, Tom Lane wrote: Andrew Dunstan writes: On 08/09/2015 08:58 PM, Michael Paquier wrote: Sure. Attached is what I have in mind. Contrary to your version we keep around temp paths should a run succeed after one that has failed when running make check multiple times in a r

Re: [HACKERS] replication slot restart_lsn initialization

On 2015-07-07 09:42:54 -0700, Gurjeet Singh wrote: > --- a/src/backend/replication/slot.c > +++ b/src/backend/replication/slot.c > @@ -40,10 +40,10 @@ > #include > > #include "access/transam.h" > +#include "access/xlog_internal.h" > #include "common/string.h" > #include "miscadmin.h" > #inc

Re: [HACKERS] tap tests remove working directories

Andrew Dunstan writes: > On 08/09/2015 08:58 PM, Michael Paquier wrote: >> Sure. Attached is what I have in mind. Contrary to your version we >> keep around temp paths should a run succeed after one that has failed >> when running make check multiple times in a row. Perhaps it does not >> matter m

Re: [HACKERS] tap tests remove working directories

On 08/09/2015 08:58 PM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 11:19 PM, Andrew Dunstan wrote: On 08/09/2015 08:41 AM, Michael Paquier wrote: On Sun, Aug 9, 2015 at 1:40 AM, Andrew Dunstan wrote: On 08/08/2015 09:31 AM, Robert Haas wrote: On Fri, Aug 7, 2015 at 7:17 PM, Andrew Dun

Re: [HACKERS] Test code is worth the space

On 10 August 2015 at 13:55, Robert Haas wrote: > On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs > wrote: > > On another review I suggested we add a function to core to allow it to be > > used in regression tests. A long debate ensued, deciding that we must be > > consistent and put diagnostic func

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Mon, Aug 10, 2015 at 1:36 PM, Rahila Syed wrote: > Hello, > >>Say, 6 bigint counters, 6 float8 >>counters, and 3 strings up to 80 characters each. So we have a >>fixed-size chunk of shared memory per backend, and each backend that >>wants to expose progress information can fill in those fields

Re: [HACKERS] Test code is worth the space

On Mon, Aug 10, 2015 at 2:02 AM, Simon Riggs wrote: > Almost every patch I review has either zero or insufficient tests. > > If we care about robustness, then we must discuss tests. Here are my two > recent experiences: > > I agree we could do with x10 as many tests, but that doesn't mean all test

Re: [HACKERS] statement_timeout affects query results fetching?

On Mon, Aug 10, 2015 at 5:25 AM, Shay Rojansky wrote: > Thanks for the explanation Robert, that makes total sense. However, it seems > like the utility of PG's statement_timeout is much more limited than I > thought. > > In case you're interested, I dug a little further and it seems that > Microso

Re: [HACKERS] WIP: Rework access method interface

On Mon, Aug 10, 2015 at 1:12 PM, Petr Jelinek wrote: > On 2015-08-09 23:56, Alexander Korotkov wrote: > >> Hacker, >> >> some time before I proposed patches implementing CREATE ACCESS METHOD. >> >> http://www.postgresql.org/message-id/capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 2015-08-10 11:25:37 +0300, Heikki Linnakangas wrote: > On 08/10/2015 11:17 AM, Andres Freund wrote: > >On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: > >>So there is no conflict, but options 2) and 3) are completely redundant if > >>we go for 5). After investigation, I now think 5) is achievab

Re: [HACKERS] expose confirmed_flush for replication slots

On 8/10/15 1:29 PM, Andres Freund wrote: On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote: + if (confirmed_flush_lsn != InvalidTransactionId) + values[i++] = LSNGetDatum(confirmed_flush_lsn); + else + nulls[i++] = true; +

Re: [HACKERS] Don'st start streaming after creating a slot in pg_receivexlog

On 2015-07-30 17:14:16 +0900, Michael Paquier wrote: >So, perhaps the attached is more convincing then? It just changes >--create-slot to leave immediately after creation to address the >complain of this thread. -- Michael Pushed that. Thanks! Andres -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] expose confirmed_flush for replication slots

On 2015-07-08 15:01:15 +0300, Marko Tiikkaja wrote: > + if (confirmed_flush_lsn != InvalidTransactionId) > + values[i++] = LSNGetDatum(confirmed_flush_lsn); > + else > + nulls[i++] = true; > + Hm. That comparison is using the wrong da

[HACKERS] Using contrib modules in check (Re: pgsql: Fix BRIN to use SnapshotAny during summarization)

Re: Tom Lane 2015-08-07 <928.1438900...@sss.pgh.pa.us> > Alvaro Herrera writes: > > Fix BRIN to use SnapshotAny during summarization > > This patch added an isolation test that fails unless contrib/pageinspect > has been built and installed. I do not find that acceptable. It causes > "make chec

Re: [HACKERS] Commitfest remaining "Needs Review" items

On 2015/08/10 17:10, Ashutosh Bapat wrote: On Mon, Aug 10, 2015 at 1:04 PM, Heikki Linnakangas mailto:hlinn...@iki.fi>> wrote: * Join pushdown support for foreign tables Ashutosh, KaiGai, Etsuro: You signed up as reviewers in spring, but there hasn't been any activity during th

Re: [HACKERS] WIP: Rework access method interface

On 2015-08-09 23:56, Alexander Korotkov wrote: Hacker, some time before I proposed patches implementing CREATE ACCESS METHOD. http://www.postgresql.org/message-id/capphfdsxwzmojm6dx+tjnpyk27kt4o7ri6x_4oswcbyu1rm...@mail.gmail.com As I get from comments to my patches and also from Tom's comment a

Re: [HACKERS] Moving SS_finalize_plan processing to the end of planning

On 10 August 2015 at 07:50, Tom Lane wrote: > I've started to work on path-ification of the upper planner (finally), > and since that's going to be a large patch in any case, I've been looking > for pieces that could be bitten off and done separately. One such piece > is the fact that SS_finaliz

Re: [HACKERS] statement_timeout affects query results fetching?

Thanks for the explanation Robert, that makes total sense. However, it seems like the utility of PG's statement_timeout is much more limited than I thought. In case you're interested, I dug a little further and it seems that Microsoft's client for SQL Server implements the following timeout (sourc

Re: [HACKERS] CREATE POLICY and RETURNING

In case you missed the link to the previous discussion at the bottom, http://www.postgresql.org/message-id/CAHGQGwEqWD=ynqe+zojbpoxywt3xlk52-v_q9s+xofckjd5...@mail.gmail.com

Re: [HACKERS] CREATE POLICY and RETURNING

Hi, This thread has a pretty thorough discussion of pros and cons of applying SELECT policy to other commands. Besides what have been mentioned, I think there is another potential pro: we can enable references to pseudorelations OLD and NEW in predicates. Now, for UPDATE, the references to the tar

Re: [HACKERS] checkpointer continuous flushing

On 2015-08-08 20:49:03 +0300, Heikki Linnakangas wrote: > * I think we should drop the "flush" part of this for now. It's not as > clearly beneficial as the sorting part, and adds a great deal more code > complexity. And it's orthogonal to the sorting patch, so we can deal with it > separately. I

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 08/10/2015 11:17 AM, Andres Freund wrote: On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: On 10 August 2015 at 07:14, Peter Geoghegan wrote: On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs wrote: If 5) fails to bring a workable solution by the Jan 2016 CF then we commit 2) instead. Is

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On 2015-08-10 07:26:29 +0100, Simon Riggs wrote: > On 10 August 2015 at 07:14, Peter Geoghegan wrote: > > > On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs > > wrote: > > > If 5) fails to bring a workable solution by the Jan 2016 CF then we > > commit > > > 2) instead. > > > > Is there actually a c

Re: [HACKERS] Precedence of standard comparison operators

2015-08-10 5:37 GMT+02:00 Noah Misch : > On Sun, Aug 09, 2015 at 08:06:11PM -0400, Tom Lane wrote: > > Noah Misch writes: > > > In SQL:2008 and SQL:2011 at least, "=", "<" and "BETWEEN" are all in > the same > > > boat. They have no precedence relationships to each other; SQL > sidesteps the > >

Re: [HACKERS] Commitfest remaining "Needs Review" items

On Mon, Aug 10, 2015 at 1:04 PM, Heikki Linnakangas wrote: > Hello Hackers, > > There are a few "Needs Review" items remaining in the July commitfest. > Reviewers, please take action - you are holding up the commitfest. > > In addition to these items, there are a bunch of items in "Ready for > Co

Re: [HACKERS] Commitfest remaining "Needs Review" items

On 08/10/2015 10:46 AM, Atri Sharma wrote: * Unique Joins Still needs to be reviewed. Any volunteers? Can take this one up, if its within my limits. Thanks! I've added you as reviewer to that. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

  1   2   >