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

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

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

[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

[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

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

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

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

[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

<    1   2   3