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

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

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

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] 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] 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] 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: 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] 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] 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] Do we create a new roadmap page for development?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Tue, Mar 21, 2017 at 2:36 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > Should I create a page for PostgreSQL 11 likewise? Or, do you

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Moved to CF 2017-03. Both patches still apply. Sorry to be late for reviewing this, but done now. The patch applied, make check passed, and the code looks almost good. I could

Re: [HACKERS] Allow interrupts on waiting standby

Hi Michael, Simon, From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > > Oh, I see. But how does the startup process respond quickly? It seems > that you need to call HandleStartupProcInterrupts() instead of >

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele > It's not clear to me what state this patch should be in. Is there more > review that needs to be done or is it ready for a committer? I would most appreciate it if Magnus could

Re: [HACKERS] Allow interrupts on waiting standby

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > > By the way, doesn't this wait event belong to IPC wait event type, because > the process is waiting for other conflicting processes to terminate the > conflict conditions? Did

Re: [HACKERS] Allow interrupts on waiting standby

Hi, Michael, From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > What do you think about the updated version attached? I reviewed this patch. Here are some comments and questions: (1) monitoring.sgml The new row needs to be

Re: [HACKERS] Allow interrupts on waiting standby

(4) standby.c > The latch is not reset when the wait timed out. The next WaitLatch() would > return immediately. Sorry, let me withdraw this. This is my misunderstanding. OTOH, when is the latch reset before the wait? Is there an assumption that MyLatch has been in reset state since it was

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

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: > > All other places in twophase.c and most places in other files put ereport() > and errms

Re: [HACKERS] Potential data loss of 2PC files

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > Do you think that this qualifies as a bug fix for a backpatch? I would think > so, but I would not mind waiting for some dust to be on it before considering > applying that on

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kang Yuzhe > 1. Prepare Hands-on with PG internals > > > For example, a complete Hands-on with SELECT/INSERT SQL Standard PG > internals. The point is the experts can pick one fairly complex

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > While I agree with that in general, we are taking about 2PC files that are > on disk in patch 0001, so I would think that in this case > ERRCODE_DATA_CORRUPTED is the most adapted

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

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Okay. I got the message, and I agree with what you say here. You are right > by the way, the error messages just use "two-phase file" and not "two-phase > STATE file", missed that previously. > -- Thanks, marked as ready for committer, as

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

From: David Steele [mailto:da...@pgmasters.net] > Well, that's embarrassing. When I recreated the function to add defaults > I messed up the AS clause and did not pay attention to the results of the > regression tests, apparently. > > Attached is a new version rebased on 88e66d1. Catalog

[HACKERS] Do we create a new roadmap page for development?

Hello, I'd like to share our roadmap for PostgreSQL development, as other companies and individuals do in the following page. But this page is for PostgreSQL 10. PostgreSQL10 Roadmap https://wiki.postgresql.org/wiki/PostgreSQL10_Roadmap Should I create a page for PostgreSQL 11 likewise? Or,

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 Tsunakawa, > Takayuki > I made this ready for committer. The patch applied except for catversion.h, > the patch content looks good, and the target test passed as follows: Sorry

Re: [HACKERS] Potential data loss of 2PC files

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat > The scope of this work has expanded, since last time I reviewed and marked > it as RFC. Right now I am busy with partition-wise joins and do not have > sufficient time to take a

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] 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] 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 > 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: 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] 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] wait event documentation

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Instead of continuing to repair this every time it gets broken, I propose > that we break this into one table that lists all the wait_event_type values > -- LWLock, Lock, BufferPin,

Re: [HACKERS] Statement timeout behavior in extended queries

From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] > It's too late. Someone has already moved the patch to the next CF (for > PostgreSQL 11). Yes, but this patch will be necessary by the final release of PG 10 if the libpq batch/pipelining is committed in PG 10. I marked this as ready for committer

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > No. Parse, bind and Execute message indivually stops and starts the > statement_timeout timer with the patch. Unless there's a lock conflict, > parse and bind will take very short

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > Actually the statement timer is replaced with new statement timer value > in enable_statement_timeout(). The patch doesn't seem to behave like that. The Parse message calls

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > I don't think the errdetail is quite right - OpenProcessToken isn't really > a syscall, is it? But then it's a common pattern already in wind32_shmem.c... Yes, "Win32 API function"

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > Hmm. IMO, that could happen even with the current statement timeout > implementation as well. > > Or we could start/stop the timeout in exec_execute_message() only. This > could

Re: [HACKERS] Supporting huge pages on Windows

From: Craig Ringer [mailto:craig.rin...@2ndquadrant.com] > TBH, anyone who cares about security and runs Win7 or Win2k8 or newer should > be using virtual service accounts and managed service accounts. > > https://technet.microsoft.com/en-us/library/dd548356 > > > Those are more like Unix

Re: [HACKERS] Statement timeout behavior in extended queries

From: Andres Freund [mailto:and...@anarazel.de] > Looks to me like npgsql doesn't do that either. None of libpq, pgjdbs and > npgsql doing it seems like some evidence that it's ok. And psqlODBC now uses always libpq. Now time for final decision? Regards Takayuki Tsunakawa -- Sent via

Re: [HACKERS] Supporting huge pages on Windows

From: Craig Ringer [mailto:craig.rin...@2ndquadrant.com] > On 5 April 2017 at 10:37, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > OTOH, I tried again to leave the DISABLE_MAX_PRIVILEGE as is and add Lock > Pages in Memory, using the attached

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > I have done tests using pgproto. One thing I noticed a strange behavior. > Below is an output of pgproto. The test first set the timeout to 3 seconds, > and parse/bind for "SELECT

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > As I asked before, why can't we delete all privs and add the explicitly > needed once back (using AdjustTokenPrivileges)? I tried it with pg_ctl.c attached to an earlier mail today,

Re: [HACKERS] Statement timeout behavior in extended queries

From: Andres Freund [mailto:and...@anarazel.de] Given the concern raised in > http://archives.postgresql.org/message-id/12207.1491228316%40sss.pgh.p > a.us > I don't see this being ready for committer. If what Tatsuo-san said to Tom is correct (i.e. each Parse/Bind/Execute starts and stops the

Re: [HACKERS] Statement timeout behavior in extended queries

Hello, I've reviewed the patch. My understanding is as follows. Please correct me if I'm wrong. * The difference is that the Execute message stops the statement_timeout timer, so that the execution of one statement doesn't shorten the timeout period of subsequent statements when they are

[HACKERS] [bug fix] Savepoint-related statements terminates connection

Hello, I found a trivial bug that terminates the connection. The attached patch fixes this. PROBLEM Savepoint-related statements in a multi-command query terminates the connection unexpectedly, as follows. $ psql -d postgres -c "SELECT 1; SAVEPOINT

Re: [HACKERS] Supporting huge pages on Windows

From: Amit Kapila [mailto:amit.kapil...@gmail.com] > The latest patch looks good to me apart from one Debug message, so I have > marked it as Ready For Committer. Thank you so much! > + ereport(DEBUG1, > + (errmsg("disabling huge pages"))); > > I think this should be similar to what we display

Re: [HACKERS] Allow interrupts on waiting standby

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Oops, sorry for that, I quite mess up with this patch. The WaitLatch() call > should still have WL_POSTMASTER_DEATH so as it can leave earlier, but yes > I agree with your analysis that HandleStartupProcInterrupts() as this is > part of

Re: [HACKERS] Supporting huge pages on Windows

Hello, Magnus cc: Andres From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander > I think what you'd need to do is enumerate what privileges the user has > *before* calling CreateRestrictedToken(), using GetTokenInformation(). > And

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

Hello, I didn't realize that my target_session_attrs naming proposal was committed. I didn't think half way it would be adopted, because the name is less intuitive than the original target_server_type, and is different from the PgJDBC's targetServerType. From:

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

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

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

[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] Supporting huge pages on Windows

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Amit is right, you had better use %zu as we do in all the other places of > the code dealing with Size variables that are printed. When compiling with > Visual Studio, Postgres falls back to the implementation of sprintf in >

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > You should use %zu instead of %llu to print Size type of variable. I did so at first, but it didn't work with Visual Studio 2010 at hand. It doesn't support %z which is added in

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alvaro Herrera > Ashutosh Bapat wrote: > > Please add this to the next commitfest. > > If this cannot be reproduced in 9.6, then it must be added to the Open Items > wiki page instead. I added

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of 'Andres Freund' > Attached. I did not like that the previous patch had the timeout handling > duplicated in the individual functions, I instead centralized it into > start_xact_command(). Given

Re: [HACKERS] Statement timeout behavior in extended queries

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > Since pgproto is a dumb protocol machine, it does not start a transaction > automatically (user needs to explicitly send a start transaction command > via either simple or extended

Re: [HACKERS] PG 10 release notes

Hello, Bruce I forgot to point out one thing. Allow libpq to connect to multiple specified host names (Robert Haas) libpq will connect with the first responsive host name. According to the following CF entry and my memory, https://commitfest.postgresql.org/12/879/ Authors mithun cy

Re: [HACKERS] PG 10 release notes

From: 'Bruce Momjian' [mailto:br...@momjian.us] > > I forgot to point out one thing. > > > > Allow libpq to connect to multiple specified host names (Robert Haas) > > libpq will connect with the first responsive host name. > > > > According to the following CF entry and my memory, > > > >

Re: [HACKERS] Cached plans and statement generalization

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Konstantin > Knizhnik > Well, first of all I want to share results I already get: pgbench with default > parameters, scale 10 and one connection: > > So autoprepare is as efficient as explicit

Re: [HACKERS] [PostgreSQL 10] default of hot_standby should be "on"?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko Sawada > The idea of changing the default value seems good to me but I'm not sure > it's good idea to change the default value now under the circumstances where > we're focus on

Re: [HACKERS] PG 10 release notes

ic code related to the optimizer? (3) Remove documented restriction about using large shared buffers on Windows (Tsunakawa, Takayuki) Please change the name to "Takayuki Tsunakawa". (4) Have to_timestamp() and to_date() check check input values for validity (Artur Zakirov) "check

<    1   2   3   >