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 (hopefully
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
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,
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
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.
> It
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> On Tue, Oct 31, 2017 at 6:59 AM, Tsunakawa, Takayuki
> wrote:
> > When CurrentMemoryContext is NULL, the message is logged with
> ReportEventA(). This is similar to write_console().
>
> My point is that as Pos
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 not
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 i
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
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 i
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
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
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 previo
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
> wrote:
> > If the latest checkpoint record is unreadable (the WAL
> segment/block/record is corrupt?),
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 recor
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 datconnlim
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 t
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 should
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
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
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, 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
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
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
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
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 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
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
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
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
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
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
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 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
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 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: 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 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: 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 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 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 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 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: 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: 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]
> 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
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: 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, 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: 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
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: 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: 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
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
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
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: 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: '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 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
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
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,
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.
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
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,
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 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 '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: 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: 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: 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: 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: 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: 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: 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: 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 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 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
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: 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
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: 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: 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
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: 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
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: 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
(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
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
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
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 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: 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 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 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 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 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 &
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: 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
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: 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
1 - 100 of 256 matches
Mail list logo
