From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> > Hmm, the large-page requires contiguous memory for each page, so this
> error could occur on a long-running system where the memory is heavily
> fragmented. For example, please see the following page and check the memory
> with RAMMap program
Hello,
As I stated here and at the PGConf.ASIA developer meeting last year, I'd like
to propose statement-level rollback feature. To repeat myself, this is
requested for users to migrate from other DBMSs to PostgreSQL. They expect
that a failure of one SQL statement should not abort the entir
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> "Tsunakawa, Takayuki" writes:
> > As I stated here and at the PGConf.ASIA developer meeting last year,
> > I'd like to propose 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 migr
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 pressur
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 discussio
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"
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 ma
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
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
-
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 f
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). Now
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 add
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 anyw
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
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 (pgsql-hackers@postg
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:
http://www.postgresql.org/mailpr
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
> 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
> wrote:
> > BTW, does the developer of each feature have to modify the catalog version
> in catv
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 look
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, I reve
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 version
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, d
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
> wrote:
> > Should I create a page for PostgreSQL 11 likewise? Or, do you want a
> more stable page named &
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 s
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 back-
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> "Tsunakawa, Takayuki" writes:
> > All other places in twophase.c and most places in other files put ereport()
> and errmsg() on separate lines. I think it woul
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 fea
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 (
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 t
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 revie
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 pla
(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 i
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 yo
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
> CHECK_FOR_INTERRUPTS
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
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 s
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 the
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 C99.
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 this
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
> src/port/snpri
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 ru
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, Act
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 time
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
start_xa
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" w
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
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 ti
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 pgsql
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 avoid
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 servic
From: Craig Ringer [mailto:craig.rin...@2ndquadrant.com]
> On 5 April 2017 at 10:37, Tsunakawa, Takayuki
> wrote:
>
> OTOH, I tried again to leave the DISABLE_MAX_PRIVILEGE as is and add Lock
> Pages in Memory, using the attached pg_ctl.c. Please see
> EnableLockPagesPrivil
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 tha
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 pg_s
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 que
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,
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 then
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: pgsql-hackers-ow...@postgresql.
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. Bu
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 to
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)
"
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 (mithun.c
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 prep
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,
> >
> > https://c
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 stabilizatio
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
> wrote:
>
> > 2. Make transaction_read_only GUC_REPORT This is to avoid the added
> > round-trip by SHOW co
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 sp
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 u
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
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/l
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
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 hard to imagine that
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:
http://www.postgresql.org/m
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 no
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
>
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 argument. I have been looking at the
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 complain
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 maintena
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 whic
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 ai
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.
> Imagine that this feature
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 bein
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 (pg
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
> wrote:
>
> > 2. Make transaction_read_only GUC_REPORT This is to avoid the added
> > round-trip by SHOW co
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 kind
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 o
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 we
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 ha
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 c
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
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, app
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 this
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 f
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 at
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 de
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 patch
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
Takay
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.
>
> Well, I started out
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 se
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
> wrote:
> > Sorry again, but how can we handle this? A non-PG-developer, Tels
101 - 200 of 256 matches
Mail list logo
