Re: [HACKERS] Declarative partitioning - another take

On 2017/01/04 16:31, 高增琦 wrote: > Server crash(failed assertion) when two "insert" in one SQL: > > Step to reproduce: > create table t(a int, b int) partition by range(a); > create table t_p1 partition of t for values from (1) to (100); > create table t_p2 partition of t for values from (100) to (

Re: [HACKERS] increasing the default WAL segment size

On 3 January 2017 at 21:33, Robert Haas wrote: > On Tue, Jan 3, 2017 at 3:38 PM, Simon Riggs wrote: >> On 3 January 2017 at 16:24, Robert Haas wrote: >>> On Jan 3, 2017 at 11:16 AM, Simon Riggs wrote: On 3 January 2017 at 15:44, Robert Haas wrote: > Yeah. I don't think there's any wa

Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017

On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote: > Yeah, I was doing parallel pulls of different branches in git via shell > script, and it seems the size of this commit showed me that doesn't > work. Sorry. Shouldn't you check the results of something like this before pushing? Sorry for piling

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Hi, On 2017-01-03 10:37:08 -0500, Stephen Frost wrote: > * Vladimir Rusinov (vrusi...@google.com) wrote: > > I think I +1 on this. > > I've did a github search on these function names and there is a lot of code > > that use them. E.g. there is 8.5k hits for pg_last_xlog_location > >

Re: [HACKERS] safer node casting

Hi, On 2017-01-03 11:00:47 +0530, Ashutosh Bapat wrote: > On Mon, Jan 2, 2017 at 2:10 PM, Andres Freund wrote: > > Hi, > > > > > > On 2016-12-31 12:08:22 -0500, Peter Eisentraut wrote: > >> There is a common coding pattern that goes like this: > >> > >> RestrictInfo *rinfo = (RestrictInfo *)

Re: [HACKERS] [PATCH] PostgresNode.pm enhancements, pg_lsn helper, and some more recovery tests

On 4 January 2017 at 12:39, Craig Ringer wrote: > To keep things together, I've followed up on the logical decoding on > standby thread that now incorporates all these patches. Attached are the two patches discussed upthread, in their proposed-for-commit form, as requested by Simon. These corre

Re: [HACKERS] Logical decoding on standby

On 4 January 2017 at 12:15, Craig Ringer wrote: > That's particularly relevant to you Simon as you expressed a wish to > commit the new streaming rep tests. Patches 0001 and 0005 in this series also posted as https://www.postgresql.org/message-id/CAMsr+YHxTMrY1woH_m4bEF3f5+kxX_T=sduyxf4d2-+e-56.

[HACKERS] GUC for cleanup indexes threshold.

Hi and happy new year. The lazy vacuum calls lazy_cleanup_index to update statistics of indexes on a table such as relpages, reltuples at the end of the lazy_scan_heap. In all type of indexes the lazy_cleanup_index scans all index pages. It happens even if table has not been updated at all since p

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 4 January 2017 at 07:32, Andres Freund wrote: > I think we've been far to cavalier lately about unnecessarily breaking > admin and monitoring tools. > Just renaming well known functions for a minor bit of > cleanliness seems not to survive a cost/benefit analysis. +1 This thread is at best

Re: [HACKERS] proposal: session server side variables

With respect, I don't share your opinion - it is not enough for usage like package variables - there usually should not to use any dependency on transactions. I'm not sure I understand your point. If Oracle provides unsafe package variables that can fool auditors, it is not a sufficient reas

Re: [HACKERS] background sessions

2017-01-04 10:23 GMT+05:00 amul sul : > One more query, can we modify > BackgroundSessionStart()/BackgroundSession struct to get background > worker PID as well? I think since session always has a PID it's absoultley reasonable to return PID. > I can understand this requirement could be sound usel

Re: [HACKERS] proposal: session server side variables

2017-01-04 9:56 GMT+01:00 Fabien COELHO : > > With respect, I don't share your opinion - it is not enough for usage like >> package variables - there usually should not to use any dependency on >> transactions. >> > > I'm not sure I understand your point. If Oracle provides unsafe package > varia

Re: [HACKERS] Make pg_basebackup -x stream the default

On Sun, Jan 1, 2017 at 12:47 AM, Michael Paquier wrote: > On Sat, Dec 31, 2016 at 9:24 PM, Magnus Hagander > wrote: > > On Tue, Dec 20, 2016 at 11:53 PM, Michael Paquier > > wrote: > >> Recovery tests are broken by this patch, the backup() method in > >> PostgresNode.pm uses pg_basebackup -x: >

Re: [HACKERS] proposal: session server side variables

On 4 January 2017 at 17:31, Pavel Stehule wrote: >> I have also updated and simplified the "simple session variable" >> description, because now I'm convinced that they must be transactional, and >> that a distinct declaration statement is a pain. > > I respect your opinion and don't agree with i

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Jan 3, 2017 at 12:05 PM, Mithun Cy wrote: As part performance/space analysis of hash index on varchar data type with this patch, I have run some tests for same with modified pgbench. Modification includes: 1. Changed aid column of pg_accounts table from int to varchar(x) 2. To generate u

Re: [HACKERS] proposal: session server side variables

Hello, I'm not sure I understand your point. If Oracle provides unsafe package variables that can fool auditors, it is not a sufficient reason for Pg to provide the same doubtful feature. And if they have sub-transactions then their feature may not necessarily be unsafe, at least if the coding

Re: [HACKERS] Reporting planning time with EXPLAIN

Here are patches for follwing 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as: SUMMARY when ON prints planning time. With ANALYZE ON, it also prints execution time. When user explicitly uses SUMMARY OFF, it does not print planning and execution time (even when ANALYZE is ON). By def

Re: [HACKERS] Measuring replay lag

On Wed, Jan 4, 2017 at 8:58 PM, Simon Riggs wrote: > On 3 January 2017 at 23:22, Thomas Munro > wrote: > >>> I don't see why that would be unacceptable. If we do it for >>> remote_apply, why not also do it for other modes? Whatever the >>> reasoning was for remote_apply should work for other mod

Re: [HACKERS] proposal: session server side variables

I respect your opinion and don't agree with it. Yeah. I'm pretty overwhelmingly unconvinced too. I'm lost. The security-related use-case you have presented stores the status of the verification in a variable. If the variable is untransactional, then it has been shown that the variable sta

Re: [HACKERS] UNDO and in-place update

On Tue, Dec 6, 2016 at 9:35 PM, Robert Haas wrote: > On Mon, Dec 5, 2016 at 4:49 AM, Amit Kapila wrote: >> I can very well understand the reason for not doing so (IIUC, it is >> about complexity and time to get it right when we are already trying >> to solve one big and complex problem of the sys

Re: [HACKERS] [PATCH] Generic type subscription

2016-12-27 14:42 GMT+05:00 Dmitry Dolgov <9erthali...@gmail.com>: >> On 27 December 2016 at 16:09, Aleksander Alekseev >> wrote: >> until it breaks existing extensions. > > Hm...I already answered, that I managed to avoid compilation problems for > this particular extension > using the `genparser`

Re: [HACKERS] Measuring replay lag

On Thu, Jan 5, 2017 at 12:03 AM, Thomas Munro wrote: > So perhaps I should get rid of that replication_lag_sample_interval > GUC and send back apply timestamps frequently, as you were saying. It > would add up to a third more replies. Oops, of course I meant to say up to 50% more replies... --

Re: [HACKERS] Microvacuum support for Hash Index

Hi, > This can be rebased on the WAL v7 patch [1]. In addition to the previous > comments you need to take commit 7819ba into account. > Attached is the v3 patch rebased on postgreSQL HEAD and WAL v7 patch. It also takes care of all the previous comments from Jesper - [1]. Also, I have changed t

Re: [HACKERS] Logical Replication WIP

On 03/01/17 22:51, Peter Eisentraut wrote: > On 1/3/17 2:39 PM, Peter Eisentraut wrote: >> In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz, > > Attached are a couple of small fixes for this. Feel free to ignore the > removal of the header files if they are needed by later patches. > Thank

Re: [HACKERS] Cache Hash Index meta page.

On Wed, Jan 4, 2017 at 4:19 PM, Mithun Cy wrote: > As part performance/space analysis of hash index on varchar data typevarchar > data type > with this patch, I have run some tests for same with modified pgbench.with > this patch, I have run some tests for same with modified pgbench. I forgot to

Re: [HACKERS] proposal: session server side variables

An alternative is to implement sub (nested) transactions, like Oracle and MS SQL Server... but that would be quite some work. As a complement, a search showed that IBM DB2, cited as a reference by Pavel, has AUTONOMOUS transactions, which looks pretty much the same thing as nested transactio

Re: [HACKERS] pg_recvlogical --endpos

> Moved to next CF with "needs review" state. Here's an updated series. It's on top of the entry https://commitfest.postgresql.org/12/883/ for PostgresNode TAP test enhancements. It corresponds exactly to patches [2,3,4] in the logical decoding on standby post at https://www.postgresql.org/messag

Re: [HACKERS] pageinspect: Hash index support

Hi Ashutosh, On 12/20/2016 05:55 AM, Ashutosh Sharma wrote: 1) It introduces two new functions hash_page_type() and hash_bitmap_info(). hash_page_type basically displays the type of hash page whereas hash_bitmap_info() shows the status of a bit for a particular overflow page in bitmap page of ha

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote: > >> Before we leave this area, though, there is a loose end that requires > >> more thought. That is, what about passphrase-protected server keys? > >> ... > >> 2. Add

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Magnus Hagander (mag...@hagander.net) wrote: > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote: > > > Magnus Hagander writes: > > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane wrote: > > >> Before we leave this area, though, there is a loose end that requires > > >> more thought. That is, what a

Re: [HACKERS] proposal: session server side variables

On 4 Jan. 2017 19:03, "Fabien COELHO" wrote: >>> I respect your opinion and don't agree with it. >> >> >> Yeah. I'm pretty overwhelmingly unconvinced too. > > I'm lost. > > The security-related use-case you have presented stores the status of the > verification in a variable. If the variable is

Re: [HACKERS] pg_sequence catalog

On 1/3/17 1:17 PM, Andreas Karlsson wrote: > Hm, doesn't this change the intent of the test case? As I read the test > it seems to make sure that we are allowed to do a read from a sequence > relation on the slave. If so I think it should be changed to something > like the below. > > select is_

Re: [HACKERS] increasing the default WAL segment size

On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs wrote: > Strange response. Nothing has been assumed. I asked for tests and you > provided measurements. Sure, of zero-filling a file with dd. But I also pointed out that in a real PostgreSQL cluster, the change could actually *reduce* latency. > I sug

Re: [HACKERS] proposal: session server side variables

2017-01-04 14:33 GMT+01:00 Fabien COELHO : > > An alternative is to implement sub (nested) transactions, like Oracle and >> MS SQL Server... but that would be quite some work. >> > > As a complement, a search showed that IBM DB2, cited as a reference by > Pavel, has AUTONOMOUS transactions, which

Re: [HACKERS] multivariate statistics (v19)

On Wed, Jan 4, 2017 at 8:05 AM, Tomas Vondra wrote: > Attached is v22 of the patch series, rebased to current master and fixing > the reported bug. I haven't made any other changes - the issues reported by > Petr are mostly minor, so I've decided to wait a bit more for (hopefully) > other reviews.

Re: [HACKERS] pg_basebackups and slots

This patch looks reasonable to me. Attached is a top-up patch with a few small fixups. I suggest to wait for the resolution of the "Replication/backup defaults" thread. I would not want to be in a situation where users who have not been trained to use replication slots now have yet another resta

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote: > > * Vladimir Rusinov (vrusi...@google.com) wrote: > > > I think I +1 on this. > > > I've did a github search on these function names and there is a lot of > > > code > > > that use them. E.g

Re: [HACKERS] Replication/backup defaults

On Wed, Jan 4, 2017 at 3:43 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 12/31/16 10:00 AM, Magnus Hagander wrote: > > max_wal_senders=10 > > max_replication_slots=20 > > How about we default max_replication_slots to -1, which means to use the > same value as max_wal_sender

Re: [HACKERS] increasing the default WAL segment size

On 4 January 2017 at 13:57, Robert Haas wrote: > On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs wrote: >> Strange response. Nothing has been assumed. I asked for tests and you >> provided measurements. > > Sure, of zero-filling a file with dd. But I also pointed out that in > a real PostgreSQL clus

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Magnus Hagander writes: > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote: >> I think probably the right thing for now is to install a do-nothing >> callback, so that at least we don't have the issue of the postmaster >> freezing at SIGHUP. If someone feels like trying to revive support >> of pas

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote: > >> I think probably the right thing for now is to install a do-nothing > >> callback, so that at least we don't have the issue of the postmaster > >> freezing at SIGHU

Re: [HACKERS] Replication/backup defaults

On 12/31/16 10:00 AM, Magnus Hagander wrote: > max_wal_senders=10 > max_replication_slots=20 How about we default max_replication_slots to -1, which means to use the same value as max_wal_senders? I think this would address the needs of 99% of users. If we do like you suggest, there are going to

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Stephen Frost writes: > As I said in what you did quote above- I won't complain if someone wants > the aliases and we include them in the documentation, but I don't agree > with the other suggestions of having undocumented aliases or not making > the change. FWIW, that position makes sense to me

Re: [HACKERS] Reporting planning time with EXPLAIN

Ashutosh, I realize you were replying to yourself, but you probably didn't need to include the entire thread below or to top-post. * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote: > 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as: > SUMMARY when ON prints planning time. W

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Magnus Hagander (mag...@hagander.net) wrote: > On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane wrote: > > Magnus Hagander writes: > > > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane wrote: > > >> I think probably the right thing for now is to install a do-nothing > > >> callback, so that at least we don't

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 01/04/2017 03:48 PM, Magnus Hagander wrote: On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane That means storing the pass phrase in the memory of the postmaster, which does not sound like a terribly good idea to me, but I have never used keys with pass phrases for daemons so it might be a common so

Re: [HACKERS] UNDO and in-place update

On Wed, Jan 4, 2017 at 4:35 PM, Amit Kapila wrote: > In this new system, I > think we can't remove undo entries of heap page till we clear > corresponding index entries. I think we need to somehow collect the > old values from undo corresponding to index and then scan the index > remove the index

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Andreas Karlsson (andr...@proxel.se) wrote: > On 01/04/2017 03:48 PM, Magnus Hagander wrote: > >On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane >It does not; what would be the point, if the key would be lost at > >SIGHUP? > > > >If we lost it, yes. But we could keep the old key around if it has

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 01/04/2017 04:14 PM, Stephen Frost wrote: * Andreas Karlsson (andr...@proxel.se) wrote: A possible solution might be to only add the error throwing hook when loading certificates during SIGHUP (and at Windows) and to work as before on startup. Would that be an acceptable solution? I could wri

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Andreas Karlsson (andr...@proxel.se) wrote: > On 01/04/2017 04:14 PM, Stephen Frost wrote: > >* Andreas Karlsson (andr...@proxel.se) wrote: > >>A possible solution might be to only add the error throwing hook > >>when loading certificates during SIGHUP (and at Windows) and to work > >>as before o

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

So I'm looking at this patch in the commit fest. I have only a general understanding of temporal query processing. What this patch does is to add two new clauses for FROM-list items, NORMALIZE and ALIGN, which reshuffle a set of ranges into a new list that can then be aggregated more easily. Fro

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Stephen Frost writes: > Indeed, this is important functionality that people are using. Who exactly are these people, and why haven't they complained about how crappy the support is now? I'm *completely* unconvinced by the argument that the way it has worked in the past is an important feature th

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Andreas Karlsson writes: > Sorry, I was very unclear. I meant refusing the reload the SSL context > if there is a pass phrase, but that the rest of the config will be > reloaded just fine. This will lead to some log spam on every SIGHUP for > people with a pass phrase but should otherwise work

Re: [HACKERS] increasing the default WAL segment size

On Wed, Jan 4, 2017 at 9:47 AM, Simon Riggs wrote: > On 4 January 2017 at 13:57, Robert Haas wrote: >> On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs wrote: >>> Strange response. Nothing has been assumed. I asked for tests and you >>> provided measurements. >> >> Sure, of zero-filling a file with d

Re: [HACKERS] emergency outage requiring database restart

On Tue, Jan 3, 2017 at 1:05 PM, Peter Eisentraut wrote: > On 11/7/16 5:31 PM, Merlin Moncure wrote: >> Regardless, it seems like you might be on to something, and I'm >> inclined to patch your change, test it, and roll it out to production. >> If it helps or at least narrows the problem down, we o

Re: [HACKERS] merging some features from plpgsql2 project

On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule wrote: > > > 2017-01-03 20:54 GMT+01:00 Merlin Moncure : >> >> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule >> wrote: >> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure : >> >> *) Would also like to have a FINALLY block >> > >> > What you can do there? >

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 1/4/17 10:26 AM, Tom Lane wrote: > Andreas Karlsson writes: >> Sorry, I was very unclear. I meant refusing the reload the SSL context >> if there is a pass phrase, but that the rest of the config will be >> reloaded just fine. This will lead to some log spam on every SIGHUP for >> people wit

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Peter Eisentraut writes: > On 1/4/17 10:26 AM, Tom Lane wrote: >> How will you know whether there's a pass phrase? > One could register a password callback that remembers whether it was called. Hmm ... actually, we don't even need to work that hard. If we simply use the callback that's there no

Re: [HACKERS] Proposal : Parallel Merge Join

On Wed, Jan 4, 2017 at 12:02 PM, Amit Kapila wrote: > Review comments: > 1. > + bool is_partial); > + > > Seems additional new line is not required. Fixed > > 2. > + * try_partial_mergejoin_path > + * Consider a partial merge join path; if it appears useful, > push it into > + * the joinrel's pa

Re: [HACKERS] merging some features from plpgsql2 project

2017-01-04 16:49 GMT+01:00 Merlin Moncure : > On Tue, Jan 3, 2017 at 2:15 PM, Pavel Stehule > wrote: > > > > > > 2017-01-03 20:54 GMT+01:00 Merlin Moncure : > >> > >> On Tue, Jan 3, 2017 at 9:58 AM, Pavel Stehule > >> wrote: > >> > 2017-01-03 16:23 GMT+01:00 Merlin Moncure : > >> >> *) Would als

Re: [HACKERS] merging some features from plpgsql2 project

>> > SELECT UNCACHED t.a, t.b FROM INTO a,b; >> >> Yeah -- this is pretty ugly admittedly. Maybe control directive is >> ok, as long as you can set it mid function? >> > > ADA uses for this purpose PRAGMA keyword - it is used for everything in > ADA - cycle iteration optimization, ...the scope can

Re: [HACKERS] proposal: session server side variables

Hello, The security-related use-case you have presented stores the status of the verification in a variable. If the variable is untransactional, then it has been shown that the variable status > may say ok while the verification has really really failed. That's only a concern if the setting

Re: [HACKERS] proposal: session server side variables

Now we can this feature emulate with dblink, and there are patches in commitfest based on background workers, and emulation will be cheaper. I had not noticed that "background session" proposal. That's definitely an interesting feature to have for some use cases. Dblink implies a new connec

Re: [HACKERS] proposal: session server side variables

> >> Um, what? No, not at all. >> >> GUCs are scoped, but not transactional, [...] >> > > The documentation is very scarse, so I have tested it. > > All tests I have done with commit & rollback on session variables (SET > SESSION) have shown a clean transactional behavior, with the value reverted >

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 1/4/17 10:57 AM, Tom Lane wrote: > I still maintain that the existing solution for passphrases is useless, > but in the interest of removing objections to the current patch, I'll > go make that happen. Sounds good. Looking around briefly (e.g., Apache, nginx), the standard approach appears to

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/4/17 10:57 AM, Tom Lane wrote: > > I still maintain that the existing solution for passphrases is useless, > > but in the interest of removing objections to the current patch, I'll > > go make that happen. > > Sounds good. Agreed

Re: [HACKERS] proposal: session server side variables

See attached scripts for instance. Your test shows so SET SESSION has not transactional behaviour - the transactions fails, but the value is not reverted to NULL. There are *two* function calls, the first fails and the second succeeds. Here is the trace with a some comments: [...] ##

Re: [HACKERS] [PATCH] PostgresNode.pm enhancements, pg_lsn helper, and some more recovery tests

On 4 January 2017 at 08:16, Craig Ringer wrote: > On 4 January 2017 at 12:39, Craig Ringer wrote: > >> To keep things together, I've followed up on the logical decoding on >> standby thread that now incorporates all these patches. > > Attached are the two patches discussed upthread, in their > pr

Re: [HACKERS] proposal: session server side variables

2017-01-04 17:30 GMT+01:00 Fabien COELHO : > > > Now we can this feature emulate with dblink, and there are patches in >> commitfest based on background workers, and emulation will be cheaper. >> > > I had not noticed that "background session" proposal. That's definitely an > interesting feature t

Re: [HACKERS] Cluster wide option to control symbol case folding

On Tue, Jan 3, 2017 at 6:45 PM, Lewis, Ian (Microstar Laboratories) wrote: > One idea, which would likely be harder to implement on the server, but > that would have less impact on third party tools and libraries, would be > to configure case folding on a session basis. There would have to be > so

Re: [HACKERS] proposal: session server side variables

2017-01-04 17:58 GMT+01:00 Fabien COELHO : > > See attached scripts for instance. >>> >> >> Your test shows so SET SESSION has not transactional behaviour - the >> transactions fails, but the value is not reverted to NULL. >> > > There are *two* function calls, the first fails and the second succ

Re: [HACKERS] Logical Replication WIP

Some small patches for 0002-Add-SUBSCRIPTION-catalog-and-DDL-v16.patch.gz: - Add a get_subscription_name() function - Remove call for ApplyLauncherWakeupAtCommit() (rebasing error?) - Remove some unused include files (same as before) - Rename pg_dump --no-create-subscription-slot to --no-create

Re: [HACKERS] proposal: session server side variables

ok understand Good. So we seem to agree that GUCS are transactional? The logic depends on transactions and on nesting level (nesting doesn't depends on transactions only) Yep, it probably also happens with LOCAL which hides the previous value and restores the initial one when exiting.

Re: [HACKERS] proposal: session server side variables

2017-01-04 18:49 GMT+01:00 Fabien COELHO : > > ok understand >> > > Good. So we seem to agree that GUCS are transactional? > > The logic depends on transactions and on nesting level (nesting doesn't >> depends on transactions only) >> > > Yep, it probably also happens with LOCAL which hides the pr

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Tue, Jan 3, 2017 at 9:33 PM, Robert Haas wrote: > > On Mon, Jan 2, 2017 at 1:36 AM, Amit Kapila wrote: > > Okay, but I think if we know how much is the additional cost in > > average and worst case, then we can take a better call. > > Yeah. We shouldn't just rip out optimizations that are inc

Re: [HACKERS] Declarative partitioning - another take

On Mon, Dec 26, 2016 at 5:46 AM, Amit Langote wrote: > On 2016/12/23 8:08, Robert Haas wrote: >> On Thu, Dec 22, 2016 at 3:35 AM, Amit Langote >> wrote: >>> While working on that, I discovered yet-another-bug having to do with the >>> tuple descriptor that's used as we route a tuple down a partit

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 27, 2016 at 8:41 PM, Amit Langote wrote: > On 2016/12/27 19:07, Amit Langote wrote: >> Attached should fix that. > > Here are the last two patches with additional information like other > patches. Forgot to do that yesterday. 0001 has the disadvantage that get_partition_for_tuple() a

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

Pavan Deolasee wrote: > A transaction then updates the second column in the table. So the > refactored patch will do heap_getattr() on more columns that the master > while checking if HOT update is possible and before giving up. Thanks. > 1-client > Master Refac

Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

On Wed, Jan 4, 2017 at 2:17 AM, Michael Paquier wrote: > On Wed, Jan 4, 2017 at 12:48 AM, Robert Haas wrote: >> On Sun, Jan 1, 2017 at 4:38 AM, Thomas Munro >> wrote: >>> To be able to do this, the patch modifies the isolation tester so that >>> it recognises wait_event SafeSnapshot. >> >> I'm n

Re: [HACKERS] merging some features from plpgsql2 project

> > >> >> >> >> >> >> *) Some user visible mechanic other than forcing SQL through EXECUTE >> >> >> to be able to control plan caching would be useful. >> >> > >> >> > fully agree. >> >> > >> >> > Have you some ideas? >> >> > >> >> > What about plpgsql option (function scope) -- WITHOUT-PLAN-CACHE

Re: [HACKERS] proposal: session server side variables

[...] It is on critical path, so every check increase computer time for transaction end. Hmmm... Everything executed is on the critical path... It is a very good thing that GUCs are transactional, and this should not be changed, it is a useful feature! Much more useful than non transactional

Re: [HACKERS] proposal: session server side variables

2017-01-04 19:56 GMT+01:00 Fabien COELHO : > > [...] It is on critical path, so every check increase computer time for >> transaction end. >> > > Hmmm... Everything executed is on the critical path... > > It is a very good thing that GUCs are transactional, and this should not >>> be changed, it i

Re: [HACKERS] pg_recvlogical --endpos

On 4 January 2017 at 13:37, Craig Ringer wrote: >> Moved to next CF with "needs review" state. > > Here's an updated series. It's on top of the entry > https://commitfest.postgresql.org/12/883/ for PostgresNode TAP test > enhancements. > > It corresponds exactly to patches [2,3,4] in the logical d

Re: [HACKERS] Replication/backup defaults

On 1/4/17 9:46 AM, Magnus Hagander wrote: > How about we default max_replication_slots to -1, which means to use the > same value as max_wal_senders? > But you don't necessarily want to adjust them together, do you? They are > both capped by max_connections, but I don't think they have any

Re: [HACKERS] merging some features from plpgsql2 project

> > so some possible design can be: > > DECLARE > PRAGMA UNCACHED_PLANS; > BEGIN > SELECT ... INTO ; > SELECT ... INTO ; > END; > > This respects Ada and PL/SQL style - probably easy implementation > > Regards > > Pavel > some examples based on Ada doc FUNCTION xxx RETURN int AS PRAGMA yy

Re: [HACKERS] pg_hba_file_settings view patch

On 4 January 2017 at 03:54, Haribabu Kommi wrote: > Latest patch is attached. The "method" column should be called "auth" or "auth_method" or "authentication" I think we should have some tests, but I'll hear your views on that. Perhaps we can include a test/sample pg_hba.conf for use in tests.

[HACKERS] ALTER SYSTEM for pg_hba.conf

My next thought is ALTER SYSTEM support for pg_hba.conf, especially since that would make it easier to do a formal test of Haribabu's pg_hba view patch by adding each of the options one by one and then juggling them. ALTER SYSTEM ENABLE [LOCAL | REMOTE] ACCESS FOR [DATABASE | REPLICATION ] [USER

Re: [HACKERS] Replication/backup defaults

On 3 January 2017 at 12:34, Michael Paquier wrote: > On Mon, Jan 2, 2017 at 10:55 PM, Simon Riggs wrote: >> In the hope of making things better in 10.0, I remove my objection. If >> people want to use wal_level = minimal they can restart their server >> and they can find that out in the release n

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

On Mon, Jan 2, 2017 at 10:07 PM, Kohei KaiGai wrote: > Oops, I oversight this patch was marked as "returned with feedback", > not "moved to the next CF". > > Its status has not been changed since the last update. (Code was > revised according to the last > comment by Jeevan, but CF-Nov was time up

Re: [HACKERS] ALTER SYSTEM for pg_hba.conf

Simon Riggs writes: > My next thought is ALTER SYSTEM support for pg_hba.conf, especially > since that would make it easier to do a formal test of Haribabu's > pg_hba view patch by adding each of the options one by one and then > juggling them. It's quite unclear from this spec what you have in m

Re: [HACKERS] generating fmgr prototypes automatically

2017-01-04 21:09 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 1/3/17 2:16 PM, Pavel Stehule wrote: > > patch 0001 .. trivial cleaning > > patch 0002 .. renaming lo_* to be_lo_* -- the prefix "be" is not what I > > expect - maybe "pg" instead. More because the be-fsstubs.h

Re: [HACKERS] ALTER SYSTEM for pg_hba.conf

On 4 January 2017 at 20:30, Tom Lane wrote: > Simon Riggs writes: >> My next thought is ALTER SYSTEM support for pg_hba.conf, especially >> since that would make it easier to do a formal test of Haribabu's >> pg_hba view patch by adding each of the options one by one and then >> juggling them. >

Re: [HACKERS] Declarative partitioning - another take

On Tue, Dec 27, 2016 at 3:59 AM, Amit Langote wrote: > Patches 0001 to 0006 unchanged. Committed 0001 earlier, as mentioned in a separate email. Committed 0002 and part of 0003. But I'm skeptical that the as-patched-by-0003 logic in generate_partition_qual() makes sense. You do this:

Re: [HACKERS] merging some features from plpgsql2 project

On Wed, Jan 4, 2017 at 1:49 PM, Pavel Stehule wrote: > >> >> so some possible design can be: >> >> DECLARE >> PRAGMA UNCACHED_PLANS; >> BEGIN >> SELECT ... INTO ; >> SELECT ... INTO ; >> END; >> >> This respects Ada and PL/SQL style - probably easy implementation >> >> Regards >> >> Pavel >

Re: [HACKERS] pgbench - allow to store select results into variables

Fabien COELHO writes: > Indeed. Here is the rebased version, which still get through my various > tests. I looked through this again, and I still think that the syntactic design of the new command is seriously misguided, leading to an ugly and unmaintainable implementation that may well block fu

Re: [HACKERS] generating fmgr prototypes automatically

On 1/4/17 3:35 PM, Pavel Stehule wrote: > On 1/3/17 2:16 PM, Pavel Stehule wrote: > > patch 0001 .. trivial cleaning > > patch 0002 .. renaming lo_* to be_lo_* -- the prefix "be" is not what I > > expect - maybe "pg" instead. More because the be-fsstubs.h will be > > holds only

Re: [HACKERS] logical decoding of two-phase transactions

On 31 December 2016 at 08:36, Stas Kelvich wrote: > Here is resubmission of patch to implement logical decoding of two-phase > transactions (instead of treating them > as usual transaction when commit) [1] I’ve slightly polished things and used > test_decoding output plugin as client. Sounds go

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro wrote: > On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro > wrote: >> But I'm starting to think that the best way might be to do BOTH of the >> things I said in my previous message: make dsa.c register on >> create/attach and also unregister before deta

Re: [HACKERS] [PATCH] Fix for documentation of timestamp type

On Tue, Dec 13, 2016 at 10:46 AM, Robert Haas wrote: > On Tue, Dec 13, 2016 at 10:41 AM, Tom Lane wrote: >> Robert Haas writes: >>> I find this a bit unclear, because the revised text kind of jumps back >>> and forth between the floating-point and integer formats. Perhaps >>> something like thi

Re: [HACKERS] Logical Replication WIP

0003-Define-logical-replication-protocol-and-output-plugi-v16.patch.gz looks good now, documentation is clear now. Another fixup patch to remove excessive includes. ;-) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servi

  1   2   >