Re: [HACKERS] Planning counters in pg_stat_statements

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Thomas Munro > I have often wanted $SUBJECT and was happy to find that Fujii-san had posted > a patch five years ago[1]. The reception then seemed positive. > So here is a refurbished and

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Simon Riggs > A backend-based solution is required for PL procedures and functions. > > We could put this as an option into PL/pgSQL, but it seems like it is > a function of the transaction manager

Re: [HACKERS] Statement-level rollback

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Vladimir > Sitnikov > Tsunakawa> PgJDBC has supported the feature with autosave parameter only > Tsunakawa> recently > > PgJDBC has the implementation for more than a year (REL9.4.1210, 2016-09-07,

Re: [HACKERS] Statement-level rollback

From: Craig Ringer [mailto:cr...@2ndquadrant.com] > The example often cited is some variant of > > BEGIN; > CREATTE TABLE t2 AS SELECT * FROM t1; > DROP TABLE t1; > ALTER TABLE t2 RENAME TO t1; > COMMIT; > > Right now, we do the right thing here. With default statement level rollback, > you just

Re: [HACKERS] Statement-level rollback

From: Peter Eisentraut [mailto:peter.eisentr...@2ndquadrant.com] > The difference is how error recovery works. So this will necessarily be > tied to how the client code or other surrounding code is structured or what > the driver or framework is doing in the background to manage transactions. >

Re: [HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > When CurrentMemoryContext is NULL, the message is logged with > ReportEventA(). This is similar to write_con

Re: [HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > So you are basically ready to lose any message that could be pushed > here if there is no memory context? That does not sound like a good > trade-off to me. A static buffer does

Re: [HACKERS] proposal: schema variables

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pavel Stehule > I propose a new database object - a variable. The variable is persistent > object, that holds unshared session based not transactional in memory value > of any type. Like variables

[HACKERS] Re: [bug fix] postgres.exe crashes with access violation on Windows while starting up

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Takayuki > The reason is for not outputing the crash dump is a) the crash occurred > before installing the Windows exception handler > (pgwin32_install_crashdump_handle

[HACKERS] [bug fix] postgres.exe crashes with access violation on Windows while starting up

Hello, We encountered a rare and hard-to-investigate problem on Windows, which one of our customers reported. Please find the attached patch to fix that. I'll add this to the next CF. PROBLEM == PostgreSQL sometimes crashes with the following messages. This is

Re: [HACKERS] Remove secondary checkpoint

From: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org] > Tsunakawa, Takayuki wrote: > > > (Although unrelated to this, I've also been wondering why PostgreSQL > > flushes WAL to disk when writing a page in the shared buffer, because > > PostgreSQL doesn't use WAL fo

Re: [HACKERS] [bug fix] ECPG: fails to recognize embedded parameters

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Meskes > Thanks for spotting and fixing. I just committed your patch to master and > backported to 9.4, 9.5, 9.6 and 10. It doesn't apply cleanly to 9.3. But > then it might not be important

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Simon Riggs > This > * reduces disk space requirements on master > * removes a minor bug in fast failover > * simplifies code I welcome this patch. I was wondering why PostgreSQL retains the

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Tue, Oct 24, 2017 at 5:58 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > If the latest checkpoint record is unreadable (the WAL &

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Doesn't it also make crash recovery less robust? The whole point > of that mechanism is to be able to cope if the latest checkpoint > record is unreadable. If the latest checkpoint

[HACKERS] [bug fix] ECPG: fails to recognize embedded parameters

Hello, This is an actual problem that our customer hit. In ECPG, opening a cursor fails which is declared as follows: EXEC SQL DECLARE cur CURSOR FOR SELECT oid, datname FROM pg_database WHERE datname LIKE 'post%' ESCAPE '\' AND

Re: [HACKERS] list of credits for release notes

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > At the PGCon Developer Meeting it was agreed[0] to add a list of credits > to the release notes, including everyone who was mentioned in a commit > message. I have now completed

Re: [HACKERS] PG 10 release notes

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > TBH, I think that's another reason for not release-noting it. There's no > concrete change to point to, and so it's hard to figure out what to say. > I'm not even very sure that we

Re: [HACKERS] sync process names between ps and pg_stat_activity

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > > Personally, I prefer "wal writer", "wal sender" and "wal receiver" > > that separate words as other process names. But I don't mind leaving > > them as they are now. > > If we

Re: [HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello Tom, Michael, Robert, Noah From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Thu, Sep 14, 2017 at 3:23 AM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > Sorry again, but how can we h

Re: [HACKERS] Process startup infrastructure is a mess

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andres Freund > I think we should seriously consider doing a larger refactoring of this > soon. I've some ideas about what to do, but I'd welcome some thoughts on > whether others consider this a

[HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello, Robert, Noah From: Robert Haas [mailto:robertmh...@gmail.com] > On Fri, Jul 28, 2017 at 1:30 AM, Noah Misch wrote: > > We've reached that period. If anyone is going to push for a change > > here, now is the time. Absent such arguments, the behavior won't change. > >

Re: [HACKERS] PG 10 release notes

It's embarrassing to ask about such a trivial thing, but I noticed the following line was missing in the latest release note, which was originally in Bruce's website: Remove documented restriction about using large shared buffers on Windows (Takayuki Tsunakawa) Is this intended? Regards

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Sharma > I have once again tested the latest patch (v14 patch) on Windows and the > results looked fine to me. Basically I have repeated the test cases which > I had done earlier on v8

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > The originally reported bug is fixed. Not making any claims about other > bugs ... I'm sorry I couldn't reply to you. I've recently been in a situation where I can't use my time for

Re: [HACKERS] Supporting huge pages on Windows

Hi Thomas, Magnus From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Thomas Munro > Since it only conflicts with c7b8998e because of pgindent whitespace > movement, I applied it with "patch -p1 --ignore-whitespace" and created > a new patch. See

Re: [HACKERS] How can I find a specific collation in pg_collation when using ICU?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > There are no case-insensitive collations in PostgreSQL (yet). That's sad news, as I expected ICU to bring its various collation features to PostgreSQL. I hope it will be easy

[HACKERS] Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Robert Haas [mailto:robertmh...@gmail.com] > Well, I started out believing that the current behavior was for the best, > and then completely reversed my position and favored the OP's proposal. > Nothing has really happened since then to change my mind, so I guess I'm > still in that camp.

Re: [HACKERS] Huge pages support on Windows

Hello, Andrea From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Andrea caldarone > Anyone can point me in the right direction? Thank you for your interest. 1. Download the PostgreSQL 10 source code (which is still in development), which is the

Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?

Dear Meskes, From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Meskes > Done. Thanks, I confirmed the commit messages. > My standard workflow is to wait a couple days to see if everything works > nicely before backporting. Obviously

Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Meskes > I'm pretty sure it is indeed thread-aware, although I didn't provide the > code for this feature myself. > > > So the doc seems to need fix. The patch is attached. > > Thanks,

Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Takayuki > The following page says: > > https://www.postgresql.org/docs/devel/static/ecpg-connect.html#ecpg-se

[HACKERS] Is ECPG's SET CONNECTION really not thread-aware?

Hello, The following page says: https://www.postgresql.org/docs/devel/static/ecpg-connect.html#ecpg-set-connection -- EXEC SQL AT connection-name SELECT ...; If your application uses multiple threads of execution, they cannot share a connection

Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > Yes, I also share this opinion, the shm attach failures are due to > randomization behavior, so sleep won't help much. So, I will change the > patch to use 100 retries unless people

Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Noah Misch > Ten feels low to me. The value should be be low enough so users don't give > up and assume a permanent hang, but there's little advantage to making it > lower. > I'd set it such that

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > I didn't look at exactly how you tried to do that, but GUCs whose values > depend on other GUCs generally don't work well at all. transaction_read_only and transaction_isolation depends

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

From: Robert Haas [mailto:robertmh...@gmail.com] > I've already stated my position on this, which is that: > > * target_session_attrs=read-only is a perfectly good new feature, but we're > past feature freeze, so it's material for v11. > > * I'm not opposed to adding a GUC_REPORT GUC of some

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > On 13 April 2017 at 14:59, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > > 2. Make transaction_read_only GUC_REPORT This is to avoid

Re: [HACKERS] Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Committed. I also added a slight tweak to the wording of the documentation. Thank you, the doc looks clearer. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > > One thing I'm worried is that people here might become more conservative > against change once the final version is released. > > Any redesign after release would finish by

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote: > > Because why? > > Because it is critical to let the user know as well *why* an error happened. >

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut > The problem is that if we decide to change the behavior mid-beta, then we'll > only have the rest of beta to find out whether people will like the other > behavior. > > I would

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Takayuki > Done. I'll examine whether we can use SQLSTATE. I tried conceivable errors during connection. Those SQLSTATEs are as follows: [transient error (after which you

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Does JDBC use something like that to make a difference between a failure > and a move-on-to-next-one? No, it just tries the next host. See the first while loop in org/postgresql/jdbc/core/v3/ConnectionFactoryImpl.java. > From

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sure, but part of the point of beta testing is to get user feedback. Yes, and I'm also proposing this in the user's point of view, which I believe holds true for people here. I'm worried from my support experience that strict customers would

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

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > On Fri, Mar 31, 2017 at 9:58 PM, Ashutosh Bapat > wrote: > > Then the question is why not to allow savepoints as well? For that we > > have to fix transaction block state machine. > > I agree with this

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello Robert, Tom, Thank you for being kind enough to explain. I think I could understand your concern. From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Who is right is a judgement call, but I don't think it's self-evident that >

Re: [HACKERS] Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > pqWait is internal to libpq, so we are free to set up what we want here. > Still I think that we should be consistent with what pqSocketCheck returns: Please let this what it is

Re: [HACKERS] Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

Hello Robert, Tom, Michael, Thanks a lot for checking my patch. Sorry, let me check Michael's review comments and reply tomorrow. Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote: > > I would not really expect that reconnection would retry after > > arbitrary failure cases. Should it retry for "wrong database name", for > instance? > > It's not

[HACKERS] Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,> Takayuki > Instead, I think we should fix the program to match the documented behavior. > Otherwise, if the first database machine is down, libpq might wait for abo

[HACKERS] Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa, > Takayuki > I found a wrong sentence here in the doc. I'm sorry, this is what I asked > you to add... > > https://www.postgresql.org/docs/devel/static/libpq-

Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > It seems to me that the feature is behaving as wanted. Or in short attempt > to connect to the next host only if a connection cannot be established. > If there is a failure once the exchange with the server has begun, just > consider it as

[HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur

Hello, I found a problem with libpq connection failover. When libpq cannot connect to earlier hosts in the host list, it doesn't try to connect to other hosts. For example, when you specify a wrong port that some non-postgres program is using, or some non-postgres program is using PG's port

[HACKERS] [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

Hello, Robert I found a wrong sentence here in the doc. I'm sorry, this is what I asked you to add... https://www.postgresql.org/docs/devel/static/libpq-connect.html#libpq-paramkeywords connect_timeout Maximum wait for connection, in seconds (write as a decimal integer string). Zero or not

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > On 13 April 2017 at 14:59, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > > 2. Make transaction_read_only GUC_REPORT This is to avoid

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

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

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

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

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

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

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

[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

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

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

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

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

  1   2   3   >