[HACKERS] [tiny doc fix] statistics are not retained across immediate shutdown

Hi, In the following page, statistics are kept across server restarts: http://www.postgresql.org/docs/current/static/monitoring-stats.html When the server shuts down, a permanent copy of the statistics data is stored in the global subdirectory, so that statistics can be retained across server

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: pgsql-hackers-ow...@postgresql.org > Sorry I fail to understand what you mean with "legal"? Are you wondering > about license restrictions? There are none. Sorry, I just meant "correct" or "valid". > As for compatibility, that's what major version numbers are for. This is > not a

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: Michael Meskes [mailto:mes...@postgresql.org] > > Yes, but Windows users probably don't understand or know it. So, I > > suggested explicitly describing the application binary compatibility > > policy in the PostgreSQL manual. What do you think about it? > > Couldn't you point your

Re: [HACKERS] Question and suggestion about application binary compatibility policy

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer While that's probably OK, it's not especially desirable. The typical Windows deployment model involves the application bundling all its direct dependencies except when those are

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Marco Atzeri > on cygwin the postgresql binary package already include the library > versions: > >/usr/bin/cygecpg-6.dll >/usr/bin/cygecpg_compat-3.dll >/usr/bin/cygpgtypes-3.dll >

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: Michael Meskes [mailto:mes...@postgresql.org] > e.g. a random hit from google:=C2=A0https://www.bottomupcs.com/libra > ries_and_the_linker.xhtml > > There even is a wikipedia page about > it:=C2=A0https://en.wikipedia.org/wiki/ > Soname Thank you for good pointers. The former is

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer I'll follow this mood. Yeha. BTW, I've publushed the HTML-ified SGML docs to http://2ndquadrant.github.io/postgres/libpq-batch-mode.html as a preview. Sorry for my late reply.

[HACKERS] Question and suggestion about application binary compatibility policy

Hello, I'd like to ask you about the policy of application binary compatibility. And have a suggestion as well. QUESTION == My customer asked me if the following usage is correct. - Build an embedded SQL C application with PostgreSQL 9.2. -

Re: [HACKERS] Question and suggestion about application binary compatibility policy

> From: Bruce Momjian [mailto:br...@momjian.us] > We have this text in src/tools/RELEASE_CHANGES: > ... > This is saying running against a mismatched minor version should be fine > for a binary. Thanks for a good rationale. > I know this thread is old but it bounced around a lot of ideas. I

Re: [HACKERS] Feature suggestions: "dead letter"-savepoint.

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer Now, what I do think we need is to give the client the ability to determine whether one of its xacts actually committed or not when it lost the session after dispatching COMMIT but

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Sent: Friday, June 24, 2016 11:37 AM > On Fri, Jun 24, 2016 at 11:33 AM, Craig Ringer > wrote: > It might be worth testing that out and adding an initdb

Re: [HACKERS] Parser extensions (maybe for 10?)

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Arcadiy Ivanov Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc. There is, however, an

Re: [HACKERS] How can we expand PostgreSQL ecosystem?

Hello, Josh, > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh berkus> > Crossing this over to pgsql-advocacy list where it really belongs. > That's what that list is *for*. > > Especially since the discussion on -hackers has focused on

Re: [HACKERS] How can we expand PostgreSQL ecosystem?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mark Kirkwood > For cloud - in particular Openstack (which I am working with ATM), the > biggest thing would be: > > - multi-master replication > > or failing that: > > - self managing single

Re: [HACKERS] foreign table batch inserts

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer Well, there's FE/BE level batching/pipelining already. Just no access to it from libpq. Oh, really. The Bind ('B') appears to take one set of parameter values, not multiple sets

Re: [HACKERS] Is the unfair lwlock behavior intended?

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alexander Korotkov I've already observed such behavior, see [1]. I think that now there is no consensus on how to fix that. For instance, Andres express opinion that this shouldn't be fixed from

Re: [HACKERS] foreign table batch inserts

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer On 19 May 2016 at 01:39, Michael Paquier wrote: On Wed, May 18, 2016 at 12:27 PM, Craig Ringer wrote: > On 18 May 2016 at 06:08,

[HACKERS] Is the unfair lwlock behavior intended?

Hello, I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. That appears to apply to 9.6, too, as far as I examine the code. Could you tell me if the behavior is intended or needs fix? Simply put, the unfair behavior is that waiters for exclusive mode are overtaken by

Re: [HACKERS] Wait events monitoring future development

From: pgsql-hackers-ow...@postgresql.org > Lets put this in perspective: there's tons of companies that spend thousands > of dollars per month extra by running un-tuned systems in cloud environments. > I almost called that "waste" but in reality it should be a simple business > question: is it

[HACKERS] [RFC] Change the default of update_process_title to off

Hello, I'd like to propose changing the default value of update_process_title to off, at least on Windows. I'll submit a patch if we see no big problem. PROBLEM Our customer is trying to certify PostgreSQL with their packaged software product.

Re: [HACKERS] [RFC] Change the default of update_process_title to off

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Yeah, I think I agree. It would be bad to disable it by default on Unix, > because ps(1) is a very standard tool there, but the same argument doesn't > hold for Windows. It seems that we could reach a consensus. The patch is attached. I'll add

Re: [HACKERS] Wait events monitoring future development

From: pgsql-hackers-ow...@postgresql.org > I used to think of that this kind of features should be enabled by default, > because when I was working at the previous company, I had only few features > to understand what is happening inside PostgreSQL by observing production > databases. I needed

Re: [HACKERS] Wait events monitoring future development

From: pgsql-hackers-ow...@postgresql.org > If you want to know why people are against enabling this monitoring by > default, above is the reason. What percentage of people do you think would > be willing to take a 10% performance penalty for monitoring like this? I > would bet very few, but the

Re: [HACKERS] Wait events monitoring future development

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ilya Kosmodemiansky I've summarized Wait events monitoring discussion at Developer unconference in Ottawa this year on wiki:

Re: [HACKERS] [RFC] Change the default of update_process_title to off

From: David Rowley [mailto:david.row...@2ndquadrant.com] > But perhaps it's better written like: > > + This value defaults to "off" on Windows platforms due to the > platform's significant overhead for updating the process title. Thank you, I copied this. But I changed "off" to off because

[HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

Hello, While I was thinking of application binary compatibility between PostgreSQL releases, some questions arose about C language user-defined functions (UDFs) and extensions that depend on them. [Q1] Can the same UDF binary be used with different PostgreSQL minor releases? If it is, is it

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > [Q1] > > Can the same UDF binary be used w

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > So perhaps the best answer, is not 1 nor 2. Just saying that the routines > are carefully maintained with a best effort, though sometimes you may need > to rebuild depending on

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > I'd like to document the policy clearly in the upgrade

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> writes: > > Option 2: > > Rebuild UDFs with the target PostgreSQL distribution. > > You do not have to rebuild UDFs when you upgrade or downgrade the >

Re: [HACKERS] Is a UDF binary portable across different minor releases and PostgreSQL distributions?

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer There's no formal extension API. So there's no boundary between "internal stuff we might have to change to fix a problem" and "things extensions can rely on not changing under them".

Re: [HACKERS] [GENERAL] C++ port of Postgres

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Geoghegan > I think that the best thing about C++ is the ability to encapsulate and > simplify some aspects of resource management quite well, which necessitates > reimplementing PG_TRY/CATCH.

[HACKERS] [RFC] Should "SHOW huge_pages" display the effective value "off" when the huge page is unavailable?

Hello, all Could you give me your opinions on whether the SHOW command should display the effective value or the specified value for huge_pages? During the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3, Magnus gave me a comment that the huge_page

Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > TBH, I think you are worried about the wrong thing here. You could drop > both of those errdetail calls altogether and be little worse off. In the > places where we have errdetail calls like "failed system call was xxx", > the main point is to show

[HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

Hello, all Could you give me your opinions on the message style? Recently, I got different comments from Magnus and Alvaro during the review of "Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3. To be more specific, I'm modifying src/backend/port/win32_shmem.c

Re: [HACKERS] [RFC] Should I embed or parameterize syscall/Win32 function names from error messages?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > I find it hard to have an opinion on the matter as a non-translator. > Why not asking translators directly on pgsql-translators? > I didn't think of pgsql-translators. I'll ask

Re: [HACKERS] Commit fest 2017-01 will begin soon!

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > - Cascading standby cannot catch up and get stuck emitting the same message > repeatedly, a 9.3-only bug fix. Thank you for your hard work as a CFM. For a trivial note, this is

Re: [HACKERS] Checksums by default?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > Is it time to enable checksums by default, and give initdb a switch to turn > it off instead? > > I keep running into situations where people haven't enabled it, because > (a)

Re: [HACKERS] Supporting huge pages on Windows

From: Amit Kapila [mailto:amit.kapil...@gmail.com] > Hmm. It doesn't work even on a command prompt with administrative > privileges. It gives below error: > > waiting for server to start2017-01-17 11:20:13.780 IST [4788] FATAL: > could not create shared memory segment: error code 1450 >

Re: [HACKERS] [doc fix] Really trivial fix for BRIN documentation

From: Simon Riggs [mailto:si...@2ndquadrant.com] > Pushed, but using "heap" rather than "table", for clarity. Thanks for the > patch. Thank you for responding so quickly. I'm comfortable with "heap." On the other hand, src/backend/access/brin/README uses "table" as follows. Second, I thought

Re: [HACKERS] Adding new output parameter of pg_stat_statements to identify operation of the query.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of > husttrip...@vip.sina.com > When using pg_stat_statements to collect running SQL of PG, we > find it is hard for our program to get exact operation type of the SQL, > such as SELECT,

[HACKERS] [doc fix] Really trivial fix for BRIN documentation

Hello, This is just a correction from "index" to "table". I was a bit confused when I first read this part. Regards Takayuki Tsunakawa brin_trivial_doc_fix.patch Description: brin_trivial_doc_fix.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Supporting huge pages on Windows

From: Amit Kapila [mailto:amit.kapil...@gmail.com] > > Hmm, the large-page requires contiguous memory for each page, so this > error could occur on a long-running system where the memory is heavily > fragmented. For example, please see the following page and check the memory > with RAMMap program

[HACKERS] Statement-level rollback

Hello, As I stated here and at the PGConf.ASIA developer meeting last year, I'd like to propose statement-level rollback feature. To repeat myself, this is requested for users to migrate from other DBMSs to PostgreSQL. They expect that a failure of one SQL statement should not abort the

Re: [HACKERS] pg_stat_lwlock wait time view

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi > calculations may cause performance problem. Is there any need of writing > this stats information to file? As this just provides the wait time > information. Yes, saving the

Re: [HACKERS] increasing the default WAL segment size

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Considering those three factors, I think we should consider pushing the > default value up somewhat higher for v10. Reverting to the 64MB size that > we had prior to

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki > But one thing that would help a little, would be to optimize the UTF-8 > -> SJIS conversion. It uses a very generic routine, with a binary search > over a large array of mappings. I bet you

Re: [HACKERS] Supporting SJIS as a database encoding

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> writes: > > Before digging into the problem, could you share your impression on > > whether PostgreSQL can support SJIS? Would it be hopeless? > > I think i

Re: [HACKERS] Supporting SJIS as a database encoding

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > HORIGUCHI Implementing radix tree code, then redefining the format of mapping table > to suppot radix tree, then modifying mapping generator script are needed. > > If no one oppse to

Re: [HACKERS] Supporting SJIS as a database encoding

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > > But what I'm wondering is why PostgreSQL doesn't support SJIS. Was there > any technical difficulty? Is there anything you are worried about if adding > SJIS? > > Yes, there's

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > HORIGUCHI > > $ time psql postgres -c 'select t.a from t, generate_series(0, )' > > /dev/null > > real 0m22.696s > user 0m16.991s > sys 0m0.182s> > > Using binsearch the result

[HACKERS] Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Our customer hit a problem of cascading replication, and we found the cause. > They are using the latest PostgreSQL 9.2.18. The bug seems to have been > fixed in 9.4 and higher during

[HACKERS] Supporting SJIS as a database encoding

Hello, I'd like to propose adding SJIS as a database encoding. You may wonder why SJIS is still necessary in the world of Unicode. The purpose is to achieve comparable performance when migrating legacy database systems from other DBMSs without little modification of applications. Recently,

Re: [HACKERS] autonomous transactions

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > Of course, if we could decrease the startup cost of a bgworker For this use in autonomous tx's we could probably pool workers. Or at least lazily terminate them so that the loop

Re: [HACKERS] [RFC] Change the default of update_process_title to off

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Thomas Munro > Another database vendor recommends granting SeLockMemoryPrivilege so that > it can use large pages on Windows when using several GB of buffer pool. > I wonder if that might help

[HACKERS] Supporting huge pages on Windows

Hello, The attached patch implements huge_pages on Windows. I'll add this to the CommitFest. The performance improvement was about 2% with the following select-only pgbench. The scaling factor is 200, where the database size is roughly 3GB. I ran the benchmark on my Windows 10 PC with 6

Re: [HACKERS] Is the last 9.1 release planned?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > On Oct 5, 2016 5:42 AM, "Tsunakawa, Takayuki" > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > Thanks for clarification. Then, I understood that

Re: [HACKERS] Switch to unnamed POSIX semaphores as our preferred sema code?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > I've gotten a bit tired of seeing "could not create semaphores: No space > left on device" failures in the buildfarm, so I looked into whether we should > consider preferring unnamed

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: Robert Haas [mailto:robertmh...@gmail.com] > I have no opinion on this patch, because I haven't reviewed it, but note > recent commit 3b90e38c5d592ea8ec8236287dd5c749fc041728, which appears to > be semi-related. Thank you for interesting information. Maybe Tom-san experienced some trouble

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane FWIW, I'm pretty much -1 on messing with the timing of the socket close > actions. I broke that once within recent memory, so maybe I'm gun-shy, > but I think that the odds of unpleasant

Re: [HACKERS] Is the last 9.1 release planned?

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > 9.1.24 will be the last in the 9.1 series as far as I know. And it is still > to come at the beginning of November: > https://www.postgresql.org/developer/roadmap/ But the release note for 9.1.23 says: "The PostgreSQL community will stop

Re: [HACKERS] Is the last 9.1 release planned?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jaime Casanova > Well, no. We normally don't give special treatment to any minor release > not even if it is going to die. > What normally happens is that all minor releases are released the same

[HACKERS] Is the last 9.1 release planned?

Hello, (Please point me to the appropriate ML if this is not the right one.) According to the following mail, I thought one more release for 9.1 (9.1.24) was scheduled in September. Is there any release plan for the 9.1 last release? If there's, I want to wait for it, and apply 9.1.23

[HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

Hello, > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > On Wed, Aug 24, 2016 at 4:35 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > As a similar topic, I wonder whether the follo

[HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

Hello, Please let me ask you about possible causes of a certain problem, slow shutdown of postmaster when a backend crashes, and whether to fix PostgreSQL. Our customer is using 64-bit PostgreSQL 9.2.8 on RHEL 6.4. Yes, the PostgreSQL version is rather old but there's no relevant bug fix in

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Tue, Sep 20, 2016 at 2:20 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > There's no apparent evidence to indicate the cause, but

Re: [HACKERS] Supporting SJIS as a database encoding

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro > Thanks, by the way, there's another issue related to SJIS conversion. MS932 > has several characters that have multiple code points. By converting texts > in this encoding to and from

Re: [HACKERS] [RFC] Change the default of update_process_title to off

From: Magnus Hagander [mailto:mag...@hagander.net] Applied and backpatched to 9.6. Thank you very much. I didn’t expect 9.6 to be patched, so I’m very happy. Regards Takayuki Tsunakawa

Re: [HACKERS] [RFC] Change the default of update_process_title to off

From: Peter Geoghegan [mailto:p...@heroku.com] > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: > >> [Windows] > >> #clients onoff > >> 12 29793 38169 > >> 24 31587 87237 > >> 48 32588 83335 > >> 96 34261 67668 > > > > This ranges from a 28% to a

[HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

Hello, Our customer hit a problem of cascading replication, and we found the cause. They are using the latest PostgreSQL 9.2.18. The bug seems to have been fixed in 9.4 and higher during the big modification of xlog.c, but it's not reflected in older releases. The attached patch is for

Re: [HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > 9.3 has addressed that by allowing streaming standbys to perform timeline > jumps via the replication protocol. Doesn't this problem enter in this area? IIUC, that new feature

Re: [HACKERS] Supporting huge pages on Windows

From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] > > huge_pages=off: 70412 tps > > huge_pages=on : 72100 tps > > Hmm. I guess it could be noise or random code rearrangement effects. I'm not the difference was a random noise, because running multiple set of three runs of pgbench

Re: [HACKERS] Supporting huge pages on Windows

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > Credit: This patch is based on Thomas Munro's one. >

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane, > though. Try to make sure it doesn't leave partly-written stats files > behind. The attached patch based

Re: [HACKERS] Supporting huge pages on Windows

From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] > Your ~2.4% number is similar to what was reported for Linux with 4GB > shared_buffers: > > https://www.postgresql.org/message-id/20130913234125.GC13697%40roobarb > .crazydogs.org I'm relieved to know that a similar figure was gained on

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat > In pgstat_quickdie(), I think a call to sigaddset(, SIGQUIT) is > missing before PG_SETMASK(). Although there are some SIGQUIT handlers which > do not have that call. But I guess,

[HACKERS] [bug fix] Stats collector is not restarted on the standby

Hello, If the stats collector is forcibly terminated on the standby in streaming replication configuration, it won't be restarted until the standby is promoted to the primary. The attached patch restarts the stats collector on the standby. FYI, when the stats collector is down, SELECTs

Re: [HACKERS] Proposal : For Auto-Prewarm.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > # pg_autoprewarm. > > This a PostgreSQL contrib module which automatically dump all of the > blocknums present in buffer pool at the time of server shutdown(smart and > fast mode only,

Re: [HACKERS] [bug fix] Stats collector is not restarted on the standby

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > The delay is intentional. Per pgstat_start(): It's kind of you to tell the reason. > Committed and back-patched all the way. Thanks again! Regards Takayuki Tsunakawa -- Sent

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] > Ok. In that case, I think we shouldn't even call PG_SETMASK() similar to > pgarch_exit(). Attached patch removes PG_SETMASK(). Let me know if it looks > good. It looks good. Thanks. Regards Takayuki Tsunakawa -- Sent via

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat > I am not sure if following condition is a good idea in ServerLoop() > 1650 if (pmState == PM_WAIT_DEAD_END || ClosedSockets) > > There are no sockets to listen on, so

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: amul sul [mailto:sula...@gmail.com] > IMHO, I think we could remove third paragraph completely and generalised > starting of second paragraph, somewhat looks likes as > follow: > > > -If you have a dedicated database server with 1GB or more of RAM, > a > -reasonable

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Sun, Nov 6, 2016 at 6:30 PM, MauMau wrote: > > Sorry, I may have had to send this to pgsql-hackers. I just replied > > to all, which did not include

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > Among the remaining things I have worked on failover to new master idea. > Below patch implement that idea. This is taken from Victors patch but > rewritten by me to do some cleanup. As

Re: [HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > OK. I agree that's a problem. However, your patch adds zero new comment > text while removing some existing comments, so I can't easily tell how it > solves that problem or whether

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Things are this way since b15f9b08 that introduced pgwin32_is_service(). > Still, by considering what you say, you definitely have a point that if > postgres is started by another

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > I just looked more deeply at your refactoring patch, and I didn't know about > CheckTokenMembership()... The whole logic of your patch depends on it. > That's quite a cleanup that you have here. It looks that the former > implementation

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms684190(v=vs > > .85).aspx > > That's what I looked at as well :) And this part is what caught my attention, > meaning

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Hm... See here: > http://stackoverflow.com/questions/6084547/how-to-check-whether-a-proc > ess-is-running-as-a-windows-service > And particularly this quote: > "No, that is not

Re: [HACKERS] Re: BUG #13755: pgwin32_is_service not checking if SECURITY_SERVICE_SID is disabled

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Meh. Local System accounts are used only by services (see comments of > pgwin32_is_service), so I'd expect pgwin32_is_service() to return true in > this case, contrary to what your

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > Yes this patch will only address failover to new master, values "master" > and "any" appeared sufficient for that case. Do you mean that unlike pgJDBC "standby" and "prefer_standby" are

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Great, committed. There's still potentially more work to be done here, > because my patch omits some features that were present in Victor's original > submission, like setting the

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander Okay and I think partially it might be because we don't have > writeback > optimization (done in 9.6) for Windows. However, still the broader > question stands

Re: [HACKERS] [RFC] Transaction management overhaul is necessary?

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > >> This was because psqlODBC starts and ends a subtransaction for each > >> SQL statement by default to implement statement-level rollback. And > >> PostgreSQL creates one CurTransactionContext memory context, which is > >> 8KB, for each

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > Okay, not a problem. However, I am not sure the results in this thread > are sufficient proof as for read-only tests, there is no noticeable win > by increasing shared buffers and

Re: [HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Let me try to be more clear. I will not commit this patch if it is not > properly commented. I doubt that anyone else will, either. > > The fact that those code changes already

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > Thanks, my concern is suppose you have 3 server in cluster A(new version), > B(new version), C(old version). If we implement as above only new servers > will send ParameterStatus message

Re: [HACKERS] [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > It looks like the code in 9.3 or later version uses the recptr as the target > segment location > (targetSegmentPtr) whereas 9.2 uses recptr as beginning of segment (readOff > = 0;).

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > If you are suggesting me to change in protocol messages, I think that would > not be backward compatible to older version servers. I also think such level > of protocol changes will not

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Robert Haas writes: > > I agree. However, in many cases, the major cost of a fast shutdown is > > getting the dirty data already in the operating system buffers

  1   2   3   >