On Fri, Dec 07, 2018 at 03:45:59PM +0900, myungkyu.lim wrote:
> Thank you for your attention!
And committed. There was one thing that the patch was doing wrong:
there is no point to convert the timestamp to a string if no log message
is generated, so I have added a check on log_min_messages to
On Sat, Dec 08, 2018 at 06:24:35PM -0800, Noah Misch wrote:
> pg_recvlogical_upto() has the ability to make timeout non-fatal, by calling it
> in an array context. No in-tree test uses that. Out-of-tree code using that
> feature would likely benefit from the ability to set timeout duration.
On Sun, Dec 09, 2018 at 11:14:12AM +0900, Michael Paquier wrote:
> On Sat, Dec 08, 2018 at 04:16:01PM -0800, Noah Misch wrote:
> > @@ -72,7 +72,7 @@ my $endpos = $node_master->safe_psql('postgres',
> > print "waiting to replay $endpos\n";
> >
> > my $stdout_recv =
On Sat, Dec 08, 2018 at 04:16:01PM -0800, Noah Misch wrote:
> The 180s timeout in poll_query_until has been trouble-free since 2a0f89c
> introduced it two years ago. I plan to raise the timeouts in question to
> 180s, as attached.
That's annoying, thanks for tracking those down.
> @@ -72,7
Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
is that the toast declarations require hard-coded oids, even though
only shared catalogs actually need stable oids. Now that we can assign
oids on the fly, it makes sense to do so for toast tables as well, as
in the attached.
The docs say:
https://www.postgresql.org/docs/current/runtime-config-query.html
|min_parallel_table_scan_size Sets the minimum amount of table data that must
be scanned in order for a parallel scan to be considered. [...]
I'd like to set parallel_min_table_size=32MB, but it looks like that won't
On Sat, Dec 8, 2018 at 1:21 PM Jeremy Finzel wrote:
> That doesn't indicate an error. You need to provide more details what
>> made you consider things wedged...
>>
>> Andres
>>
>
> Thank you very much for the reply. We typically see no visible
> replication delay over 5 minutes ever. Today
We've had more buildfarm failures due to hard-coded, short timeouts:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk=2018-10-13%2021%3A06%3A58
10s timeout while running pg_recvlogical
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet=2018-12-03%2005%3A52%3A12
30s
On Sun, Dec 09, 2018 at 08:15:07AM +0900, Michael Paquier wrote:
> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
>> We should really have a more clearly defined policy around this, but my
>> recollection is that we often prefer to return NULL rather than throwing
>> an error for
On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> We should really have a more clearly defined policy around this, but my
> recollection is that we often prefer to return NULL rather than throwing
> an error for the convenience of people doing things like querying
> pg_class using
On 2018-Dec-08, Andres Freund wrote:
> On 2018-12-08 17:10:27 -0300, Alvaro Herrera wrote:
> > This is what patch 0001 does -- it's only allowed in the connection
> > string, or on ALTER USER / ALTER DATABASE. Setting it in
> > postgresql.conf is forbidden, as well as changing from transaction
Hi,
On 2018-12-08 17:10:27 -0300, Alvaro Herrera wrote:
> On 2018-Dec-07, Andres Freund wrote:
>
> > I think it could partially be addressed by not allowing to set it on the
> > commandline, server config, etc. So the user would have to set it on a
> > per-connection basis, potentially via the
On 2018-Dec-07, Andres Freund wrote:
> I think it could partially be addressed by not allowing to set it on the
> commandline, server config, etc. So the user would have to set it on a
> per-connection basis, potentially via the connection string.
This is what patch 0001 does -- it's only
Hi,
the possibility to use polymorphic types is a specific interesting
PostgreSQL feature. The polymorphic types allows to use almost all types,
but when some type is selected, then this type is required strictly without
possibility to use some implicit casting.
So if I have a fx(anyelement,
>
> That doesn't indicate an error. You need to provide more details what
> made you consider things wedged...
>
> Andres
>
Thank you very much for the reply. We typically see no visible replication
delay over 5 minutes ever. Today we saw a delay of over 3 hours, and no
obvious increase in
On December 8, 2018 9:08:09 AM PST, Jeremy Finzel wrote:
>I don't know if this applies only to pglogical or logical decoding in
>general. This is on a 9.6.10 provider running pglogical 2.2.0.
>Subscriber
>has same versions. We had a replication delay situation this morning,
>which I think
I don't know if this applies only to pglogical or logical decoding in
general. This is on a 9.6.10 provider running pglogical 2.2.0. Subscriber
has same versions. We had a replication delay situation this morning,
which I think may have been due to a really long transaction but I've yet
to
John Naylor writes:
> In confg.sgml, in the section about max_stack_depth, there's this sentence:
> "The safety margin is needed because the stack depth is not checked in
> every routine in the server, but only in key potentially-recursive
> routines such as expression evaluation."
> Since the
Matsumura-san,
> > I do think, though, we should change the debug output for
> > ecpg_free_params().
>
> I try to change about it. Next patch will print binary in hex-format.
Thank you.
> > > > The patch does not support ECPG.bytea in sqltype of "struct
> > > > sqlvar_struct"
> > > > because
On 12/8/18, Amit Kapila wrote:
> On Fri, Dec 7, 2018 at 7:25 PM John Naylor wrote:
> I couldn't resist the temptation to figure out what's going on here.
> The newly added tests have deletes followed by vacuum and then you
> check whether the vacuum has removed the data by checking heap and or
>
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Dec 07, 2018 at 11:33:32PM -0500, Tom Lane wrote:
> > How about cases where the relation OID exists but it's the wrong
> > kind of relation?
>
> Such cases already return an error:
> =# create sequence popo;
> CREATE SEQUENCE
>
On Sat, 8 Dec 2018 at 08:18, Tatsuo Ishii wrote:
> >> > Curious what client is this that is violating the protocol.
> >>
> >> I heard it was a Java program.
> >>
> >
> > This is not surprising there are a proliferation of non-blocking
> > implementations,
> > probably approaching 10 different
On 12/6/18 4:52 PM, Robert Haas wrote:
> On Wed, Nov 28, 2018 at 6:17 PM Tomas Vondra
> wrote:
>>> Comparing with overhead of setting snapshot before evaluating every row
>>> and considering this
>>>
>>> kind of usage is not frequent it seems to me the behavior is acceptable
>>
>> I'm not
>> > Curious what client is this that is violating the protocol.
>>
>> I heard it was a Java program.
>>
>
> This is not surprising there are a proliferation of non-blocking
> implementations,
> probably approaching 10 different implementations now.
Do you think some of the implementations may
On Fri, Dec 7, 2018 at 7:25 PM John Naylor wrote:
>
> On 12/6/18, Amit Kapila wrote:
> > On Thu, Dec 6, 2018 at 10:53 PM John Naylor wrote:
> >>
> >> I've added an additional regression test for finding the right block
> >> and removed a test I thought was redundant. I've kept the test file in
On Sat, 8 Dec 2018 at 07:50, Tatsuo Ishii wrote:
> > Curious what client is this that is violating the protocol.
>
> I heard it was a Java program.
>
This is not surprising there are a proliferation of non-blocking
implementations,
probably approaching 10 different implementations now.
Dave
> Curious what client is this that is violating the protocol.
I heard it was a Java program.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
In confg.sgml, in the section about max_stack_depth, there's this sentence:
"The safety margin is needed because the stack depth is not checked in
every routine in the server, but only in key potentially-recursive
routines such as expression evaluation."
Since the change in expression evaluation
>Curious what client is this that is violating the protocol.
I stand corrected: that is not a violation, however client might get
unexpected failure of query(begin) in a rare case of close(s1) or close(s2)
fail.
Vladimir
On Sat, 8 Dec 2018 at 05:16, Tatsuo Ishii wrote:
> > Tatsuo>responses of a simple query do not include CloseComplete
> >
> > Tatsuo, where do you get the logs from?
>
> As I said, pgproto.
>
> https://github.com/tatsuo-ishii/pgproto
>
> > I guess you are just confused by the PRINTED order of the
On Tue, Dec 4, 2018 at 3:00 PM Dilip Kumar wrote:
>
> On Sat, Dec 1, 2018 at 12:58 PM Amit Kapila wrote:
> >
> >
> > 13.
> > PrepareUndoInsert()
> > {
> > ..
> > if (!UndoRecPtrIsValid(prepared_urec_ptr))
> > + urecptr = UndoRecordAllocate(urec, 1, upersistence, txid);
> > + else
> > + urecptr =
> Tatsuo>responses of a simple query do not include CloseComplete
>
> Tatsuo, where do you get the logs from?
As I said, pgproto.
https://github.com/tatsuo-ishii/pgproto
> I guess you are just confused by the PRINTED order of the messages in the
> log.
> Note: wire order do not have to be
Hi!
Thanks, Alexander!
> 8 дек. 2018 г., в 6:54, Alexander Korotkov написал(а):
>
> Yep, please find attached draft patch.
Patch seems good to me, I'll check it in more detail.
The patch gets posting item at FirstOffsetNumber instead of
btree->getLeftMostChild(). This seem OK, since
Tatsuo>responses of a simple query do not include CloseComplete
Tatsuo, where do you get the logs from?
I guess you are just confused by the PRINTED order of the messages in the
log.
Note: wire order do not have to be exactly the same as the order in the log
since messages are buffered, then
> Tatsuo Ishii writes:
>> While looking into an issue of Pgpool-II, I found an interesting
>> behavior of a PostgreSQL client.
>> Below is a trace from pgproto to reproduce the client's behavior.
>
>> It starts a transacton.
>
>> FE=> Parse(stmt="S1", query="BEGIN")
>> FE=> Bind(stmt="S1",
35 matches
Mail list logo
