Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Fri, Mar 17, 2017 at 1:47 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > BTW, does the developer of each feature have to mo

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > The attached patch udpates the docs per your suggestion and has been rebased > on master at d69fae2. I made this ready for committer. The patch applied except for catversion.h, the

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

From: David Steele [mailto:da...@pgmasters.net] > Any idea when you'll have a chance to review? I'll do it by early next week. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Defaulting psql to ON_ERROR_ROLLBACK=interactive

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter van > Hardenberg > I suggest we update the default of ON_ERROR_ROLLBACK to interactive for > 10.0. +1 Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PATCH: Configurable file mode mask

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > > But it might be worth thinking about whether we want to encourage > > people to do manual chmod's at all; that's fairly easy to get wrong, > > particularly given the difference in X

Re: [HACKERS] PATCH: Configurable file mode mask

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > Sure, but having the private key may allow them to get new data from the > server as well as the data from the backup. You are right. My rough intent was that the data is stolen

Re: [HACKERS] PATCH: Configurable file mode mask

From: David Steele [mailto:da...@pgmasters.net] > >> 3.The default location of the SSL key file is $PGDATA, so the permission > of the key file is likely to become 0640. But the current postgres requires > it to be 0600. See src/backend/libpq/be-secure-openssl.c. > > > > Yes, that needs to be

Re: [HACKERS] PATCH: Configurable file mode mask

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > PostgreSQL currently requires the file mode mask (umask) to be 0077. > However, this precludes the possibility of a user in the postgres group > performing a backup (or whatever).

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Sharma > To start with, I ran the regression test-suite and didn't find any failures. > But, then I am not sure if huge_pages are getting used or not. However, > upon checking the settings

[HACKERS] [bug fix] dblink leaks unnamed connections

Hello, dblink fails to close the unnamed connection as follows when a new unnamed connection is requested. The attached patch fixes this. postgres=# select count(*) from pg_stat_activity; count --- 1 (1 row) postgres=# select dblink_connect('dbname=postgres'); dblink_connect

Re: [HACKERS] some dblink refactoring

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Takayuki > How about applying the attached small patch for another refactoring? This > merely changes makeStringInfo() to initStringInfo() at two sites just other > pla

Re: [HACKERS] some dblink refactoring

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > Here is a patch to refactor some macro hell in dblink. > > This patch was discussed in the background sessions thread as a prerequisite > for some work there, but I figure I'll

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > >> Can you provide some references on how other systems provide this feature? > > > > Oracle doesn't. > > Really? Sorry, my sentence was misleading. I meant by "Oracle/MySQL doesn't"

Re: [HACKERS] Statement-level rollback

From: David Steele [mailto:da...@pgmasters.net] > Whatever the merits of this patch, it's a pretty major behavioral change > with a large potential impact. Even if what is enumerated here is the full > list (which I doubt), it's pretty big. > > Given that this landed on March 28 with no

Re: [HACKERS] Statement-level rollback

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > 1. The argument for this is mostly, if not entirely, "application > compatibility". But it won't succeed at providing that if every BEGIN has > to be spelled differently than it would be on other DBMSes. > Therefore there is going to be enormous

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > On 2/28/17 02:39, Tsunakawa, Takayuki wrote: > > I'd like to propose statement-level rollback feature. To repeat myself, > this is requested for users to migrate f

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > "Tsunakawa, Takayuki" <tsunakawa.ta...@jp.fujitsu.com> writes: > > As I stated here and at the PGConf.ASIA developer meeting last year, > > I'd like t

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

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

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

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 "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: 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

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

Hello, Amit, Magnus, I'm sorry for my late reply. Yesterday was a national holiday in Japan. From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > PGSharedMemoryReAttach is called after the startup of new process whereas >

Re: [HACKERS] Supporting huge pages on Windows

From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] > In the Microsoft documentation I've seen, the privilege's name is always > written as "Lock Pages in Memory" (note: "Pages" plural, and with initial > capital letters). It's quite hard to parse the sentence otherwise! How > about this?

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

From: David Fetter [mailto:da...@fetter.org] > > How about putting a descriptive comment at the location where each > > hook variable is defined, using some convention (e.g. like > > Javadoc-style)? A separate document such as README and wiki can fail > > to be updated. OTOH, if someone wants to

Re: [HACKERS] Hooks

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Jim Nasby > AFAIK there's no way to get a list of hooks today, short of something like > `git grep hook`. I think a simple list of what hooks we have, when they > fire and where to find them in code

Re: [HACKERS] Questions regarding signal handler of postmaster

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > In postmaster.c signal handler pmdie() calls ereport() and > errmsg_internal(), which could call palloc() then malloc() if necessary. > Because it is possible that pmdie() gets called

[HACKERS] [bug fix] Trivial ecpg bug which can cause memory overrun

Hello, While investigating some other issue, we found a trivial bug of ecpg. The attached is a fix for that. If you specify an input file which ends with "." (e.g. run "ecpg file."), ecpg writes one byte past the end of the allocated memory. In addition, the following statement is

Re: [HACKERS] Declarative partitioning - another take

From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > On 2016/12/09 10:09, Tsunakawa, Takayuki wrote: > > Another requirement was subpartitioning. Will this be possible with the > current infrastructure, or does this need drastic change? > > It does support sub-part

Re: [HACKERS] Declarative partitioning - another take

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alexander > Korotkov > Yes. Getting at least some of this features committed to v10 would be great > and improve partitioning usability a lot. I'm sorry for not contributing to the real

Re: [HACKERS] UNDO and in-place update

From: Robert Haas [mailto:robertmh...@gmail.com] > On Thu, Nov 24, 2016 at 2:32 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > IMHO, overall, there should be pros and cons of the current approach and > the new UNDo one (like Oracle?), depending on

Re: [HACKERS] Broken SSL tests in master

From: pgsql-hackers-ow...@postgresql.org > sense to add support for multiple hostaddrs. For consitency's sake if > nothing else. Yes, consistency and performance. The purpose of hostaddr is to speed up connection by eliminating DNS lookup, isn't it? Then, some users should want to specify

Re: [HACKERS] Broken SSL tests in master

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andreas Karlsson > On 11/24/2016 10:38 PM, Andreas Karlsson wrote: > > To me it feels like the proper fix would be to make PQHost() return > > the value of the host parameter rather than the

Re: [HACKERS] UNDO and in-place update

IMHO, overall, there should be pros and cons of the current approach and the new UNDo one (like Oracle?), depending on the workload. Under update-heavy workload, the UNDO method may be better. OTOH, under the mostly-INSERT workload (like data warehouse?), the current method will be better

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 > Maybe a workable compromise would be to leave the file present, and have > the stats collector re-write it every (say) five minutes. Then I'd be okay > with having an immediate shutdown

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

Re: [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 Amit Kapila > Thanks for the clarification, I could reproduce the issue and confirms that > patch has fixed it. Find logs of cascading standby at PG9.2 Head and Patch > attached (I have truncated

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 > I am very strict about regressing the performance of things that we already > have, but I try not to make a policy that a new feature must be as fast > as it could ever be. That could

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

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > The point I was trying to make is that I think the forced-removal behavior > is not desirable, and therefore committing a patch that makes it be graven > in stone is not desirable either. I totally agree that we should pursue the direction for escaping

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

From: Robert Haas [mailto:robertmh...@gmail.com] > So there are two questions here: > > 1. Should we try to avoid having the stats collector write a stats file > during an immediate shutdown? The file will be removed anyway during crash > recovery, so writing it is pointless. I think you are

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

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > You meant CheckTokenMembership(). Yes, my typo in the mail. > The proposed patch does need to be checked with: I understood you meant by "refuse to run" that postgres.exe fails to start below. Yes, I checked it on Win10. I don't have access

Re: [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 Amit Kapila > I have tried using attached script multiple times on latest 9.2 code, but > couldn't reproduce the issue. Please find the log attached with this mail. > Apart from log file, below

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

patch series is an > >>> attempt to solve something we already fixed, better, in 9.4. > > > >> ... by the same patch submitter. > > > > [ confused ] The commit log credits 82233ce7e to MauMau and yourself. > > IIUC, MauMau = Tsunakawa Takayuki. Yes, it's

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 > > shared_buffers tps > > 256MB 990 > > 512MB 813 > > 1GB 1189 > > 2GB 2258 > > 4GB 5003 > > 8GB 5062 > > > > "512MB is the largest effective size" seems to be a superstition,

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 > On Thu, Nov 17, 2016 at 10:08 PM, Craig Ringer > wrote: > > We can and probably should have both. > > > > If the server tells us on connect whether it's a

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

From: Mithun Cy [mailto:mithun...@enterprisedb.com] > > + {"target_server_type", "PGTARGETSERVERTYPE", > DefaultTargetServerType, NULL, > > + "Target-Server-Type", "", 6, > > Thanks fixed. + {"target_server_type", "PGTARGETSERVERTYPE", NULL, NULL, The default value

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

From: Tsunakawa, Takayuki/綱川 貴之 > Thank you, I'll try the read-write test with these settings on the weekend, > when my PC is available. I understood that your intention is to avoid being > affected by checkpointing and WAL segment creation. The result looks nice as follows. I took

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

Hello, Craig, I'm sorry to be late to review your patch. I've just been able to read the HTML doc first. Can I get the latest .patch file for reading and running the code? Here are some comments and questions. I tried to avoid the same point as other reviewers, but there may be an overlap.

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 > I am adding next version of the patch it have following fixes. > Tsunakawa's comments > > 1. PGconn->target_server_type is now freed in freePGconn() 2. Added > PGTARGETSERVERTYPE. >

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 > I think it beginning of segment (aka the first page of the segment), even > the comment indicates the same. > > /* > * Whenever switching to a new WAL segment, we read the first page

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 > > I think the reason why increasing shared_buffers didn't give better > performance for read-only tests than you expect is that the relation files > are cached in the filesystem cache.

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 > Hmm, let's go back to the JDBC method, then. "show transaction_read_only" > will return true on a standby, but presumably also on any other non-writable > node. You could even force

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > In my understanding pg_is_in_recovery() returns true if it's a standby node. > However, even if it returns other than true, the server is not necessarily > a primary. Even it's not

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 > On Mon, Nov 14, 2016 at 8:09 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > From: pgsql-hackers-ow...@postgresql.org > >

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] [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] 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] 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] 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] Patch: Implement failover on libpq connect level.

Hi, Mithun Before going deeper into the patch, let me give you some findings. (1) PGconn->target_server_type is not freed in freePGconn(). (2) Could you add PGTARGETSERVERTYPE environment variable? Like other variables, it will ease testing, since users can change the behavior without

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] [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 have changed some comments around this block. See attached patch. > Let me know if that looks good. Thanks, it looks good. Regards Takayuki Tsunakawa -- Sent via

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] 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] 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] 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: 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 > 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: 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 > 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 > 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] 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] [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] 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] ECPG BUlk insert support using arrays

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi > I didn't find any relevant thread about the discussion of Bulk insert support > in ECPG using arrays. Oracle supports the same and details are available > in [1]. > > > I see some

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

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

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > It would be a good idea to add that to next CF if nobody pops into the thread > so as we don't forget about it. Thanks for the notice, done. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list

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 Michael Paquier > Oops. This could be a problem for some applications... As far as I can see > and after playing with it, your patch looks correct. Thank you for checking the patch. I'm relieved.

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

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

Hello, >From our experience in handling customers' problems, I feel it's necessary to >evolve PostgreSQL's transaction management. The concrete problems are: 1. PostgreSQL cannot end and begin transactions in PL/pgSQL and PL/Java stored functions. This is often the reason people could not

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

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

[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

<    1   2   3   >