Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Wed, Nov 15, 2017 at 12:12 PM, Masahiko Sawada wrote: > I think we need to check only sessionBackupState and don't need to > check XLogCtl->Insert.exclusiveBackupState in do_pg_abort_backup(). We > can quickly return if sessionBackupState != >

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Wed, Nov 15, 2017 at 10:05 AM, Michael Paquier wrote: > On Wed, Nov 15, 2017 at 9:06 AM, Masahiko Sawada > wrote: >>> On Nov 15, 2017 2:59 AM, "Fujii Masao" wrote: >>> + /* Quick exit if we have done the backup */ >>>

Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On 2017/11/14 13:00, David Rowley wrote: > On 13 November 2017 at 22:46, Amit Langote wrote: >> On 2017/11/10 12:30, Kyotaro HORIGUCHI wrote: >>> The following uses a bit tricky bitmap operation but >>> is straightforward as a whole. >>> >>> = >>> /* fill the bits upper from

Re: [HACKERS] moving some partitioning code to executor

On 2017/11/15 2:09, Alvaro Herrera wrote: > Amit Langote wrote: > >> Since that 0001 patch was committed [1], here is the rebased patch. Will >> add this to the November commit-fest. > > Please rebase once more -- 1aba8e651ac3 seems to have broken things > in this area pretty thoroughly.

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > On 11/14/17 11:14, Tom Lane wrote: >> ... Do we really want the existence of >> a function foo(int) to mean that you can't create a SQL procedure named >> foo and taking one int argument? > Yes, that is defined that way by the SQL

Re: [HACKERS] Runtime Partition Pruning

On 15 November 2017 at 01:57, David Rowley wrote: > I think to do this you're going to have to store some sort of array > that maps the partition index to the subpath in the Append node so you > can correctly identify the subpath based on what you're getting back >

Re: [HACKERS] SQL procedures

On 11/14/17 11:14, Tom Lane wrote: >> The common functionality between functions and procedures is like 98% >> [citation needed], so they definitely belong there, even more so than >> aggregates, for example. > No, I don't think so. The core reason why not is that in > > SELECT foo(...)

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 15 November 2017 at 04:23, Alvaro Herrera wrote: > David Rowley wrote: >> I'd have thought some sort of: ALTER INDEX name_of_partitioned_index >> REPLACE INDEX FOR partitioned_tablename WITH >> name_of_new_matching_bloat_free_index; >> >> ... or something along those

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hi Jesper, Thanks for reviewing. Jesper Pedersen wrote: > I have been looking at the "CREATE INDEX ... ONLY" syntax, and I think it > could cause some confusion due to the "Note" described in create_index.sgml. > > An alternative, maybe crazy, could be to treat a partitioned index as one; >

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Nov 14, 2017 at 11:02 AM, Simon Riggs wrote: > That's a good place to leave this for now - we're OK to make progress > with the main feature, and we have some questions to be addressed once > we have a cake to decorate. > > Thanks for your input. Thanks for

Re: [HACKERS] Proposal: Local indexes for partitioned table

Hi, On 11/14/2017 12:49 PM, Alvaro Herrera wrote: Thanks, pushed. Here's the remaining bits, rebased. First of all, thanks for working on this. I have been looking at the "CREATE INDEX ... ONLY" syntax, and I think it could cause some confusion due to the "Note" described in

Re: [HACKERS] Transaction control in procedures

On 11/14/17 09:27, Merlin Moncure wrote: > *) Will it be possible to do operations like this in pl/pgsql? > > BEGIN > SELECT INTO r * FROM foo; > > START TRANSACTION; -- perhaps we ought to have a special function > for this instead (BEGIN is reserved, etc). > SET transaction_isololation

Re: [HACKERS] Proposal: Local indexes for partitioned table

Alvaro Herrera wrote: > Simon Riggs wrote: > > On 13 November 2017 at 12:55, Alvaro Herrera > > wrote: > > > Somehow I managed to include an unrelated patch as attachment. Here's > > > another attempt (on which I also lightly touched ddl.sgml with relevant > > >

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-11-11 13:19 GMT+01:00 Robert Haas : > This is really good input. If the feature weren't useful, then it > wouldn't make sense to try to figure out how to integrate it, but if > it is, then we should try. We are happy to hear this and will do the implementation. Any

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

2017-10-06 19:22 GMT+02:00 Paul A Jungwirth : > I just wanted to chime in and say that the work these people have done > is *amazing*. I read two of their papers yesterday [1, 2], and if you > are interested in temporal data, I encourage you to read them too. The >

plpgsql test layout

Something that has been bothering me for a while, while we have neatly organized test files for plperl, plpython, pltcl, the plpgsql tests are all in one giant file in the main test suite, which makes development and testing of plpgsql cumbersome. It is by far the largest test file after

Re: [HACKERS] SQL procedures

Peter Eisentraut writes: > On 11/8/17 09:54, Tom Lane wrote: >> Do procedures of this ilk belong in pg_proc at all? It seems like a large >> fraction of the attributes tracked in pg_proc are senseless for this >> purpose. A new catalog might be a better

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 10:37 AM, Robert Haas wrote: > The problem would happen if the plan for InitPlan $1 in the above > example itself referenced a parameter from an upper query level, and > the value of that parameter changed, and then this section of the plan > tree

Re: [HACKERS] SQL procedures

On 11/8/17 09:54, Tom Lane wrote: > Peter Eisentraut writes: >> On 10/31/17 14:23, Tom Lane wrote: >>> Why not use VOIDOID for the prorettype value? > >> We need a way to distinguish functions that are callable by SELECT and >> procedures that are callable by

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila wrote: > I think this would have been a matter of concern if we use initplans > below Gather/Gather Merge. The patch uses initplans which are between > current query level and root. So, I think we don't need to reevaluate >

Re: [HACKERS] log_destination=file

On Sun, Sep 10, 2017 at 5:29 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > average latency: > > clients patch master > 10 0.321 0.286 > 20 0.669 0.602 > 30 1.016 0.942 > 40 1.358 1.280 > 50 1.727 1.637

Re: [HACKERS] SQL procedures

On 11/8/17 12:15, Merlin Moncure wrote: > On Wed, Nov 8, 2017 at 11:03 AM, Peter Eisentraut > wrote: >> On 11/8/17 11:11, Merlin Moncure wrote: >>> On Wed, Nov 8, 2017 at 9:13 AM, Peter Eisentraut >>> wrote: I have already

Re: [HACKERS] Proposal: Local indexes for partitioned table

Simon Riggs wrote: > On 13 November 2017 at 12:55, Alvaro Herrera wrote: > > Somehow I managed to include an unrelated patch as attachment. Here's > > another attempt (on which I also lightly touched ddl.sgml with relevant > > changes). > > Looks good. Some minor

Re: [HACKERS] Transaction control in procedures

On Wed, Nov 8, 2017 at 5:48 PM, Simon Riggs wrote: > On 31 October 2017 at 15:38, Peter Eisentraut > wrote: >> Here is a patch that implements transaction control in PL/Python >> procedures. (This patch goes on top of "SQL procedures"

Re: [HACKERS] Pluggable storage

On Tue, Nov 14, 2017 at 4:12 PM, Alvaro Herrera wrote: > Hmm. Am I reading it right that this discussion led to moving > essentially all code from tqual.c to heapam? Given the hard time we've > had to get tqual.c right, it seems fundamentally misguided to me to >

Re: [HACKERS] Proposal: Local indexes for partitioned table

David Rowley wrote: > On 15 November 2017 at 01:09, Alvaro Herrera wrote: > > if a > > partition exists which *doesn't* have the index, restoring things this > > way would create the index in that partition too, which is unwanted > > because the end state is different to

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On Mon, Nov 13, 2017 at 3:17 PM, Dean Rasheed wrote: > On 28 October 2017 at 13:46, Pavel Stehule > wrote: > > I though about Alexander proposal, and I am thinking so it can be > probably > > best if we respect psql design. I implemented two

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 15 November 2017 at 01:09, Alvaro Herrera wrote: > if a > partition exists which *doesn't* have the index, restoring things this > way would create the index in that partition too, which is unwanted > because the end state is different to what was in the dumped

Re: [HACKERS] Pluggable storage

Hmm. Am I reading it right that this discussion led to moving essentially all code from tqual.c to heapam? Given the hard time we've had to get tqual.c right, it seems fundamentally misguided to me to require that every single storage AM reimplements all the visibility routines. I think that

Re: [HACKERS] Proposal: Local indexes for partitioned table

On 8 October 2017 at 02:34, Robert Haas wrote: > However, when > you dump-and-restore (including but not limited to the pg_upgrade > case) you've got to preserve those names. If you just generate a new > name that may or may not be the same as the old one, then it may >

RE: [HACKERS][PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state

# I add [hacker] to the mail subject. Dear Andres Freund. Thank you for review! > I'm disinclined to exposing state that way. It's an internal representation > that's not unlikely to change. Sure, > pg_buffercache is more of a debugging / investigatory tool, but I > nevertheless see no reason

Re: [HACKERS] pg_basebackup --progress output for batch execution

On Fri, Nov 10, 2017 at 10:32:23AM -0300, Martín Marqués wrote: > An example where using isatty() might fail is if you run pg_basebackup > from a tty but redirect the output to a file, I believe that in that > case isatty() will return true, but it's very likely that the user > might want batch

Re: [PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state

Hi, On 2017-11-14 17:57:00 +0900, Moon Insung wrote: > So I add a state column to pg_buffercache view so that I could print a value > indicating the state of the buffer. > This is outpu as an unit32 type, and examples are shown below. > - > postgres=# select * from pg_buffercache where

[PATCH]pg_buffercache add a buffer state column, Add fuction to decode buffer state

Dear Hackers. I'm studied PostgreSQL buffers for the development of new patches. In particular, using pg_buffercache, is can easily check the status of actual buffer. Bur there was one inconvenience. Pg_buffercache was also to check only the dirty state of the buffer. State of the buffer

Re: Migration to PGLister - After

Hello, Tom. You wrote: TL> Geoff Winkless writes: >> The removal of the [HACKERS] (etc) header will be frustrating for me: I do >> not sort mailing lists into folders (I simply scan the "Forums" autofilter >> in gmail) and have no wish to do so, and there is no way to make

Re: Migration to PGLister - After

Hello, Geoff. You wrote: GW> The removal of the [HACKERS] (etc) header will be frustrating for GW> me: I do not sort mailing lists into folders (I simply scan the GW> "Forums" autofilter in gmail) and have no wish to do so, and there GW> is no way to make such a machine-readable header visible

Re: [HACKERS] Transform for pl/perl

On Fri, 10 Nov 2017 14:40:21 +0100 Pavel Stehule wrote: > Hi > > 2017-10-24 14:27 GMT+02:00 Anthony Bykov : > > > There are some moments I should mention: > > 1. {"1":1}::jsonb is transformed into HV {"1"=>"1"}, while > > ["1","2"]::jsonb is

Re: [HACKERS] Pluggable storage

On Tue, Nov 7, 2017 at 6:34 PM, Haribabu Kommi wrote: > On Tue, Oct 31, 2017 at 8:59 PM, Haribabu Kommi > wrote: >> Additional changes that are done in the patches compared to earlier >> patches apart from rebase. > > Rebased patches are