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
> 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
> 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
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
> 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
>
> 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
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.
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.
-
> 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
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
> 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
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
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
> 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
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
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
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,
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
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
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.
> 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
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
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
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:
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
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
> 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
> 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
> 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
> 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
>
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".
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.
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
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
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
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
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
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)
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
>
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
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,
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
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
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
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
> 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
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
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
> 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
> 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
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
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
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,
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
> 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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
> 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.
>
> 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
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
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,
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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;).
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
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 - 100 of 256 matches
Mail list logo