On Sun, May 10, 2020 at 06:58:50PM +0500, godjan • wrote:
> synchronous_standby_names=ANY 1(host1, host2)
> synchronous_commit=on
Thanks for the details. I was not sure based on your previous
messages.
> So to understand which standby wrote last data to disk I should know
> receive_lsn or write
Hi Bruce,
On 2020/05/05 12:16, Bruce Momjian wrote:
I have committed the first draft of the PG 13 release notes. You can
see them here:
https://momjian.us/pgsql_docs/release-13.html
It still needs markup, word wrap, and indenting. The community doc
build should happen in a few hours.
On Fri, May 08, 2020 at 02:25:45AM -0500, Justin Pryzby wrote:
> Seems to me it should, at least conditionally. At least if there's a function
> scan or a relation or ..
>
> I mentioned a bit about our use-case here:
> https://www.postgresql.org/message-id/20200219173742.GA30939%40telsasoft.com
>
po 11. 5. 2020 v 7:25 odesílatel Pavel Stehule
napsal:
> Hi
>
> ne 10. 5. 2020 v 22:20 odesílatel Pavel Stehule
> napsal:
>
>> Hi
>>
>> I try to use procedures in Orafce package, and I did some easy
>> performance tests. I found some hard problems:
>>
>> 1. test case
>>
>> create or replace proc
On Sun, May 10, 2020 at 10:20:53PM +0200, Pavel Stehule wrote:
> When I rewrite same to functions then
>
> create or replace function p1func2(inout r int, inout v int) as $$
> begin v := random() * r; end
> $$ language plpgsql;
>
> Then execution is about 1 sec, and memory requirements are +/- zero
Hi
ne 10. 5. 2020 v 22:20 odesílatel Pavel Stehule
napsal:
> Hi
>
> I try to use procedures in Orafce package, and I did some easy performance
> tests. I found some hard problems:
>
> 1. test case
>
> create or replace procedure p1(inout r int, inout v int) as $$
> begin v := random() * r; end
>
On Sat, May 9, 2020 at 11:16 AM Amit Kapila wrote:
>
> On Tue, May 5, 2020 at 8:46 AM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 13 release notes. You can
> > see them here:
> >
> > https://momjian.us/pgsql_docs/release-13.html
> >
>
> Thanks for the work. I
On Mon, May 11, 2020 at 10:16:19AM +0900, Kyotaro Horiguchi wrote:
> The comment is mentioning "replay position" and the callers are
> actually using GetXLogReplayRecPtr to check TLI and target LSN. The
> comment was written in that way when the function is introduced by
> 1148e22a82. The attached
Alvaro Herrera writes:
> On 2020-May-10, Alexander Lakhin wrote:
>> 3. Explicitly call __gcov_flush in SIGQUIT handler (quickdie)?
> I tried your idea 3 a long time ago and my experiments didn't show an
> increase in coverage [1]. But I like this idea the best, and maybe I
> did something wrong.
Alvaro Herrera writes:
> On 2020-May-06, Alvaro Herrera wrote:
>> This doesn't allow whitespace between "fall" and "through", which means
>> we generate 217 such warnings currently. Or we can just use
>> -Wimplicit-fallthrough=3, which does allow whitespace (among other
>> detritus).
> If we're
At Sun, 10 May 2020 22:08:46 -0400, "Jonathan S. Katz"
wrote in
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)
Thank you. I found a typo in it.
> * Ensure that a detatched partition has triggers that come fr
At Sat, 9 May 2020 23:40:15 +0900, Fujii Masao
wrote in
>
>
> On 2020/05/08 12:10, Kyotaro Horiguchi wrote:
> > At Fri, 8 May 2020 11:31:42 +0900, Fujii Masao
> > wrote in
> You mean that pg_lsn_pli() and pg_lsn_mii() should emit an error like
> "the number of bytes to add/subtract
On 2020-May-06, Alvaro Herrera wrote:
> This doesn't allow whitespace between "fall" and "through", which means
> we generate 217 such warnings currently. Or we can just use
> -Wimplicit-fallthrough=3, which does allow whitespace (among other
> detritus).
If we're OK with patching all those plac
On 2020-May-09, Tom Lane wrote:
> If we do want to push this sort of thing now, the nearby changes
> to enable fallthrough warnings should go in too.
I'll get that sorted out tomorrow.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
(Strangely, I was just thinking about these branches of mine as I
closed my week last Friday...)
On 2020-May-10, Alexander Lakhin wrote:
> So if we want to make the coverage reports more precise, I see the three
> ways:
> 1. Change the stop mode in teardown_node to fast (probably only when
> conf
On Mon, May 11, 2020 at 9:48 AM Andy Fan wrote:
> Hi:
>
>
> 2020-05-11 09:37:40.778 CST [69541] sub_viaroot WARNING: terminating
> connection because of crash of another server process
>
> Looks this doesn't mean a crash. If the test case(subscription/t/
013_partition.pl)
failed, test framewo
Hi,
Attached is a draft of the press release for the 2020-05-14 cumulative
update. Please let me know your feedback by 2020-05-13 :)
Thanks,
Jonathan
2020-05-14 Cumulative Update Release
The PostgreSQL Global Development Group has released an update to all s
Hi:
When I run make -C subscription check, then I see the following logs
in ./tmp_check/log/013_partition_publisher.log
2020-05-11 09:37:40.778 CST [69541] sub_viaroot WARNING: terminating
connection because of crash of another server process
2020-05-11 09:37:40.778 CST [69541] sub_viaroot DET
Hello.
I happened to notice a wrong function name in the comment of
XLogReadDetermineTimeline.
* The caller must also make sure it doesn't read past the current replay
* position (using GetWalRcvWriteRecPtr) if executing in recovery, so it
The comment is mentioning "replay position" and the ca
On 2020/05/11 4:07, Tom Lane wrote:
Fujii Masao writes:
The empty paragraph needs to be removed.
Ah, thanks for catching that.
I'd like to add the note about the following commit that I pushed recently.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=683e0ef5530f449f0f
On Mon, 20 Apr 2020 at 10:25, Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Thu, 16 Apr 2020 at 17:48, Dilip Kumar wrote:
>
> I could reproduce this issue by the steps you shared. For the bug fix
> patch, I basically agree to remove that assertion from
> build_replindex_scan_key(
Hi,
While looking at an old wal2json issue, I stumbled on a scenario that a
table
with a deferred primary key is not updatable in logical replication. AFAICS
it
has been like that since the beginning of logical decoding and seems to be
an
oversight while designing logical decoding. I don't envisio
Hi
I try to use procedures in Orafce package, and I did some easy performance
tests. I found some hard problems:
1. test case
create or replace procedure p1(inout r int, inout v int) as $$
begin v := random() * r; end
$$ language plpgsql;
This command requires
do $$
declare r int default 100;
> In ltree, when using adjacent asterisks with braces, e.g. "*{2}.*{3}",
> properly interpret that as "*{5}" (Nikita Glukhov)
I think that should say ".*" not "*", as in:
> In ltree, when using adjacent asterisks with braces, e.g. ".*{2}.*{3}",
> properly interpret that as "*{5}" (Nikita Glukho
Fujii Masao writes:
> The empty paragraph needs to be removed.
Ah, thanks for catching that.
> I'd like to add the note about the following commit that I pushed recently.
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=683e0ef5530f449f0f913de579b4f7bcd31c91fd
I revised this
On 5/10/20 12:27 PM, Tom Lane wrote:
> Just FTR, here's a complete patch for this.
Cool. I'll play around with it tonight once I clear out release work.
Per upthread reference, I believe you've become a CSS maven yourself.
> I successfully regenerated
> the column names, types, and ordering from
> On Sat, Apr 11, 2020 at 03:17:25PM +0530, Dilip Kumar wrote:
>
> Some more comments...
Thanks for reviewing. Since this patch took much longer than I expected,
it's useful to have someone to look at it with a "fresh eyes".
> + so->skipScanKey->nextkey = ScanDirectionIsForward(dir);
> + _bt_upda
Sorry for late reply.
> On Tue, Apr 14, 2020 at 09:19:22PM +1200, David Rowley wrote:
>
> I've not yet looked at the latest patch, but I did put some thoughts
> into an email on the other thread that's been discussing UniqueKeys
> [1].
>
> I'm keen to hear thoughts on the plan I mentioned over the
Just FTR, here's a complete patch for this. I successfully regenerated
the column names, types, and ordering from the system catalogs, and
plugged the descriptions back into that by dint of parsing them out of
the XML. The "references" data was based on findoidjoins' results plus
hand additions t
Hello hackers,
I've found that gcov coverage data miss some information when a postgres
node stopped in 'immediate' mode.
For example, on the master branch:
make coverage-clean; time make check -C src/test/recovery/; make
coverage-html
generates a coverage report with 106193 lines/6318 functions f
On Fri, May 08, 2020 at 02:25:45AM -0500, Justin Pryzby wrote:
> Seems to me it should, at least conditionally. At least if there's a function
> scan or a relation or ..
>
> I mentioned a bit about our use-case here:
> https://www.postgresql.org/message-id/20200219173742.GA30939%40telsasoft.com
>
Great, thanks very much Andrew!
On Sun, May 10, 2020 at 7:08 PM Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
> On 5/10/20 8:21 AM, otar shavadze wrote:
> > When I want t to convert json array into postgres array, I do:
> >
> > with t(j) as(
> > select '{"my_arr":[3,1,2]}'
On 5/10/20 8:21 AM, otar shavadze wrote:
> When I want t to convert json array into postgres array, I do:
>
> with t(j) as(
> select '{"my_arr":[3,1,2]}'::json
> )
> SELECT ARRAY(SELECT json_array_elements_text(j->'my_arr')) from t
>
>
> It works like a charm and I never notic
synchronous_standby_names=ANY 1(host1, host2)
synchronous_commit=on
So to understand which standby wrote last data to disk I should know
receive_lsn or write_lsn.
Sent from my iPhone
> On 9 May 2020, at 13:48, Michael Paquier wrote:
>
> On Fri, May 08, 2020 at 03:02:26PM +0500, godjan • wrot
On 4/18/20 9:15 AM, Andrew Dunstan wrote:
> I was just trying to revive lousyjack, my valgrind buildfarm animal
> which has been offline for 12 days, after having upgraded the machine
> (fedora 31, gcc 9.3.1, valgrind 3.15) and noticed lots of errors like this:
>
>
> 2020-04-17 19:26:03.483 EDT [
On Sat, May 09, 2020 at 06:48:02PM -0700, Peter Geoghegan wrote:
On Sat, May 9, 2020 at 3:19 PM Tomas Vondra
wrote:
I'm generally OK with most of this - I'd probably keep the single-line
format, but I don't feel very strongly about that and if others think
using two lines is better ...
Barring
When I want t to convert json array into postgres array, I do:
with t(j) as(
> select '{"my_arr":[3,1,2]}'::json
> )
> SELECT ARRAY(SELECT json_array_elements_text(j->'my_arr')) from t
It works like a charm and I never noticed any problem, but I'm asking here
just to make sure, order of ele
37 matches
Mail list logo
