[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

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

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

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

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] 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

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

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

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

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

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

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

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

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,

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

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.

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

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

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

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

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

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

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

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

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.

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

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

Re: [HACKERS] Odd behavior with PG_TRY

Jim Nasby writes: > I do think it's interesting that the data appeared to be completely fine > until I actually ran whatever the first assembly instruction of the for > loop is, so presumably it was fine after the sigsetjmp() call (which I'm > assuming is what causes

Re: [HACKERS] Replication slot xmin is not reset if HS feedback is turned off while standby is shut down

On 2 January 2017 at 22:24, Craig Ringer wrote: > > > On 2 Jan. 2017 20:20, "Simon Riggs" wrote: > > On 21 December 2016 at 13:23, Simon Riggs wrote: > >> Fix it up and I'll commit. Thanks for the report. > > I was hoping for

Re: [HACKERS] proposal: session server side variables

On 01/04/2017 04:36 PM, Craig Ringer wrote: > On 5 January 2017 at 08:35, Craig Ringer wrote: >> On 5 January 2017 at 01:49, Fabien COELHO wrote: >>> Good. So we seem to agree that GUCS are transactional? >> >> No. We don't agree. They aren't. > >

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

On Tue, Nov 29, 2016 at 8:36 PM, Haribabu Kommi wrote: > > > On Sat, Nov 26, 2016 at 4:48 PM, Tom Lane wrote: > >> Haribabu Kommi writes: >> > Currently the casting is supported from macaddr to macaddr8, but not the >> >

Re: [HACKERS] Replication/backup defaults

On 01/03/2017 11:56 PM, Tomas Vondra wrote: Hi, ... I'll push results for larger ones once those tests complete (possibly tomorrow). I just pushed additional results (from the additional scales) to the git repositories. On the larger (16/32-cores) machine with 2x e5-2620, the results

Re: [HACKERS] increasing the default WAL segment size

On Thu, Jan 5, 2017 at 12:33 AM, Robert Haas wrote: > 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

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

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Thursday, January 05, 2017 5:29 AM > To: Kohei KaiGai > Cc: Kaigai Kouhei(海外 浩平) ; Jeevan Chalke >

Re: [HACKERS] postgres_fdw bug in 9.6

On 2016/12/27 16:41, Etsuro Fujita wrote: On 2016/12/22 1:04, Ashutosh Bapat wrote: 2. We should try to look for other not-so-cheap paths if the cheapest one is paramterized. You might want to use get_cheapest_path_for_pathkeys() to find a suitable unparameterized path by passing NULL for

Re: [HACKERS] Logical decoding on standby

On 4 January 2017 at 16:19, Craig Ringer wrote: > 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. Simon committed 1, 2, 3 and 5: *

Re: [HACKERS] postgres_fdw bug in 9.6

On 2016/12/27 22:03, Ashutosh Bapat wrote: You wrote: 3. Talking about saving some CPU cycles - if a clauseless full join can be implemented only using merge join, probably that's the only path available in the list of paths for the given relation. Instead of building the same path anew, should

[HACKERS] Questionable tag usage

In: https://www.postgresql.org/docs/devel/static/runtime-config-file-locations.html --- ident_file (string) Specifies the configuration file for Section 20.2, “User Name Maps” user name mapping (customarily called pg_ident.conf). This

Re: [HACKERS] proposal: session server side variables

On 5 January 2017 at 08:35, Craig Ringer wrote: > On 5 January 2017 at 01:49, Fabien COELHO wrote: >> >>> ok understand >> >> >> Good. So we seem to agree that GUCS are transactional? > > No. We don't agree. They aren't. Uh. I take that back. craig=>

Re: [HACKERS] identity columns

Hello, Peter, I apologize for a silence since the last CF. I've tested your last patch and have several nitpickings: 1. The fact COPY ignores GENERATED ALWAYS constraint (treats as GENERATED BY DEFAULT) should be mentioned as well as rules. 2. Usually error message for identical columns (with

Re: [HACKERS] proposal: session server side variables

On 5 January 2017 at 01:49, Fabien COELHO wrote: > >> ok understand > > > Good. So we seem to agree that GUCS are transactional? No. We don't agree. They aren't. The effects of SET LOCAL are reverted whether you commit or rollback. The effects of SET SESSION are never

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

Ashutosh Bapat writes: > Right. But I think it's better to use attribute id, in case the code > raising this error changes for any reason in future. I agree. The parent's "tdhasoid" flag is definitely based on the existence of an ObjectIdAttributeNumber system

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > For the pg_ctl changes, we're going from removing all privilieges from the > token, to removing none. Are there any other privileges that we should be > worried about? I think you

Re: [HACKERS] postgres_fdw bug in 9.6

On 2016/12/28 17:34, Ashutosh Bapat wrote: On Wed, Dec 28, 2016 at 1:29 PM, Etsuro Fujita wrote: On 2016/12/28 15:54, Ashutosh Bapat wrote: On Wed, Dec 28, 2016 at 9:20 AM, Etsuro Fujita wrote: On 2016/12/27 22:03, Ashutosh Bapat

Re: [HACKERS] postgres_fdw bug in 9.6

> >> Hmm. If I understand the patch correctly, it does not return any path >> when merge join is allowed and there are merge clauses but no hash >> clauses. In this case we will not create a foreign join path, loosing >> some optimization. If we remove GetExistingLocalJoinPath, which >> returns a

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Wed, Jan 04, 2017 at 09:58:26PM -0800, David Fetter wrote: > On Sun, Jan 01, 2017 at 07:57:33PM +0900, Michael Paquier wrote: > > On Sun, Jan 1, 2017 at 12:34 PM, David Fetter wrote: > > > I've rolled your patches into this next one and clarified the commit > > > message, as

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Sun, Jan 01, 2017 at 07:57:33PM +0900, Michael Paquier wrote: > On Sun, Jan 1, 2017 at 12:34 PM, David Fetter wrote: > > I've rolled your patches into this next one and clarified the commit > > message, as there appears to have been some confusion about the scope. > > Is

Re: [HACKERS] increasing the default WAL segment size

On 4 January 2017 at 01:16, Michael Paquier wrote: > On Tue, Jan 3, 2017 at 6:23 AM, Jim Nasby wrote: >> + /* Check if wal_segment_size is in the power of 2 */ >> + for (i = 0;; i++, pow2 = pow(2, i)) >> +

Re: [HACKERS]

On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat wrote: >> >> >>> Hmm. If I understand the patch correctly, it does not return any path >>> when merge join is allowed and there are merge clauses but no hash >>> clauses. In this case we will not create a foreign join

Re: [HACKERS] postgres_fdw bug in 9.6

On Thu, Jan 5, 2017 at 8:20 AM, Etsuro Fujita wrote: > On 2016/12/27 16:41, Etsuro Fujita wrote: >> >> On 2016/12/22 1:04, Ashutosh Bapat wrote: >>> >>> 2. We should try to look for other not-so-cheap paths if the cheapest >>> one is >>> paramterized. You might want

Re: [HACKERS] Reporting planning time with EXPLAIN

On Wed, Jan 4, 2017 at 8:24 PM, Stephen Frost wrote: > Ashutosh, > > I realize you were replying to yourself, but you probably didn't need to > include the entire thread below or to top-post. Sorry, that was unintentional. > > * Ashutosh Bapat

Re: [HACKERS] pg_hba_file_settings view patch

On Thu, Jan 5, 2017 at 5:10 AM, Simon Riggs wrote: > 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

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

On 2017/01/05 8:05, Tom Lane wrote: > Ashutosh Bapat writes: >> Right. But I think it's better to use attribute id, in case the code >> raising this error changes for any reason in future. > > I agree. The parent's "tdhasoid" flag is definitely based on the >

Re: [HACKERS] Logical decoding on standby

On Thu, Jan 5, 2017 at 10:21 AM, Craig Ringer wrote: > On 5 January 2017 at 09:19, Craig Ringer wrote: > >> so here's a rebased series on top of master. No other changes. > > Now with actual patches. Looking at the PostgresNode code in 0001... +=pod

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/05 13:19, Ashutosh Bapat wrote: Hmm. If I understand the patch correctly, it does not return any path when merge join is allowed and there are merge clauses but no hash clauses. In this case we will not create a foreign join path, loosing some optimization. If we remove

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

On 4 January 2017 at 21:20, Simon Riggs wrote: > 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

Re: [HACKERS] ALTER TABLE parent SET WITHOUT OIDS and the oid column

> >> The code updating attinhcount and then updating the catalogs is same >> for user defined attributes and OID. Should we separate it out into a >> function and use that function instead of duplicating the code? > > Didn't really seem worth the trouble ... maybe if it gets any longer > it'd be

[HACKERS]

> > >> Hmm. If I understand the patch correctly, it does not return any path >> when merge join is allowed and there are merge clauses but no hash >> clauses. In this case we will not create a foreign join path, loosing >> some optimization. If we remove GetExistingLocalJoinPath, which >> returns

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

On Thu, Jan 5, 2017 at 1:58 AM, Simon Riggs wrote: > On 4 January 2017 at 08:16, Craig Ringer wrote: >> When committed I will update the decoding on standby series to omit >> these pre-requisite patches. > > Committed, thanks. I was planning a round

Re: [HACKERS] Questionable tag usage

Tatsuo Ishii writes: > In: > https://www.postgresql.org/docs/devel/static/runtime-config-file-locations.html > "Specifies the configuration file for Section 20.2, $B!H(BUser Name > Maps$B!I(B > user name mapping" looks pretty strange to me because a raw section > name

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

On Thu, Jan 5, 2017 at 8:58 AM, Kouhei Kaigai wrote: > Unfortunately, it was not possible. Probably, administrator privilege will be > needed for this operation. Adding a patch to a CF in progress indeed requires administrator privileges, > May I add it to the CF:2017-03?

Re: [HACKERS] background sessions

On Wed, Jan 4, 2017 at 2:57 PM, Andrew Borodin wrote: > 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

Re: [HACKERS] WAL consistency check facility

On Wed, Dec 21, 2016 at 10:53 PM, Robert Haas wrote: > On a first read-through of this patch -- I have not studied it in > detail yet -- this looks pretty good to me. One concern is that this > patch adds a bit of code to XLogInsert(), which is a very hot piece of > code.

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

On 5 January 2017 at 04:50, Michael Paquier wrote: > The perldoc documentation is broken for the new routines. ... > Attached is a patch to fix all those small issues. Thanks, looks good, will apply. > It may be a good idea to run perltidy on top of that to be

Re: [HACKERS] HASH_CHUNK_SIZE vs malloc rounding

On Tue, Nov 29, 2016 at 6:27 AM, Tom Lane wrote: > Thomas Munro writes: >> I bet other allocators also do badly with "32KB plus a smidgen". To >> minimise overhead we'd probably need to try to arrange for exactly >> 32KB (or some other power of

Re: [HACKERS] Cache Hash Index meta page.

On Wed, Jan 4, 2017 at 5:21 PM, Mithun Cy wrote: I have re-based the patch to fix one compilation warning @_hash_doinsert where variable bucket was only used for Asserting but was not declared about its purpose. -- Thanks and Regards Mithun C Y EnterpriseDB:

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.

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

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] 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

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

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

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

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

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

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

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

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

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

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

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

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] 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

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

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

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.

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

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:

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] [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

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

Re: [HACKERS] Odd behavior with PG_TRY

On 1/3/17 9:20 PM, Amit Kapila wrote: On Wed, Jan 4, 2017 at 3:47 AM, Jim Nasby wrote: On 1/2/17 9:47 PM, Tom Lane wrote: Correct coding would be volatile TupleDesc desc = slot->tts_tupleDescriptor; CallbackState * volatile myState = (CallbackState *) self;

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

Robert Haas [mailto:robertmh...@gmail.com] wrote: >> Where you get into trouble there is that you might run CREATE EXTENSION >> from that session Yes. I can see this problem. And, while I can imagine resolving it with context belonging to the extension, separate from the current session's

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

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

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

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

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

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

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

  1   2   >