Hi,
On 2018-01-25 17:34:15 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
>
> > > I think we could solve this by putting in the same parallel group only
> > > slow tests that mostly sleeps, ie. nothing that would monopolize CPU for
> > > long enough to cause a
Hi
> I think it is related to https://commitfest.postgresql.org/16/1373/
> but I don't know how to link it with.
You can just add new entry in open commitfest and then attach previous thread.
This is usual way for pick up old patches. For example, as i did here:
On Wed, Feb 13, 2019 at 12:42 PM Michael Paquier
wrote:
> On Tue, Feb 12, 2019 at 06:03:37PM +1100, Haribabu Kommi wrote:
> > During the testing allow group access permissions on the standby database
> > directory, one of my colleague found the issue, that pg_basebackup
> > doesn't verify
On 2019/02/13 16:33, Michael Paquier wrote:
> On Wed, Feb 13, 2019 at 01:57:09PM +0900, Amit Langote wrote:
>> total_table_pages is computed by make_one_rel as of the aforementioned
>> commit. Attached fixes this.
>
> Thanks, fixed.
Thank you.
Regards,
Amit
On Wed, Feb 13, 2019 at 01:57:09PM +0900, Amit Langote wrote:
> total_table_pages is computed by make_one_rel as of the aforementioned
> commit. Attached fixes this.
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 11, 2019 at 10:20 AM David Rowley
wrote:
> Reviewing pg_dump-rows-per-insert-option-v14.
>
Also, maybe one for Fabien (because he seems keen on keeping the
> --rows-per-insert validation code)
>
> strtol() returns a long. dump_inserts is an int, so on machines where
> sizeof(long) ==
At Tue, 12 Feb 2019 20:36:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190212.203628.118792892.horiguchi.kyot...@lab.ntt.co.jp>
> > (4)
> > + hash_size = cp->cc_nbuckets * sizeof(dlist_head);
> > + tupsize = sizeof(CatCTup) + MAXIMUM_ALIGNOF + dtp->t_len;
> > +
On February 6, 2019, 8:57 AM +, Andres Freund wrote:
> Maybe I'm missing something here, but why is it actually necessary to
> have the sizes in shared memory, if we're just talking about caching
> sizes? It's pretty darn cheap to determine the filesize of a file that
> has been recently
On Wed, Feb 13, 2019 at 3:58 PM Shawn Debnath wrote:
> On Wed, Jan 30, 2019 at 09:59:38PM -0800, Shawn Debnath wrote:
> > I wonder if it might be better to introduce two different functions
> > catering to the two different use cases for forcing an immediate sync:
> >
> > - sync a relation
> >
Hi all,
When lacking connection slots, the backend returns a simple "sorry,
too many clients", which is something that has been tweaked by recent
commit ea92368 for WAL senders. However, the same message would show
up for autovacuum workers and bgworkers. Based on the way autovacuum
workers are
On 2019/02/13 4:16, Alvaro Herrera wrote:
I added metrics for the validate_index phases; patch attached. This is
still a bit raw, but it looks much better now. Here's a sample
concurrent index build on a 100M tuple table. There are no concurrent
Great!
+ s.pid AS pid, S.datid
Hi,
I think the following commit:
commit c6e4133fae1fde93769197379ffcc2b379845113
Author: Tom Lane
Date: Wed Nov 7 12:12:56 2018 -0500
Postpone calculating total_table_pages until after pruning/exclusion.
...
obsoleted a sentence in the comment above index_pages_fetched(), which says:
Hi Alvaro,
On 2019/02/12 12:18, Alvaro Herrera wrote:
> I ended up defining phases for the index_build phase in the AM itself;
> the code reports a phase number using the regular API, and then the
> pgstat_progress view obtains the name of each phase using a support
> method.
diff --git
On 2019/02/13 11:59, Simon Riggs wrote:
> On Wed, 13 Feb 2019 at 00:46, Alvaro Herrera
> wrote:
>
>> Here's a sample
>> concurrent index build on a 100M tuple table.
>
>
> Cool
+1
Looking at the "([phase] x of x)" in the sample output, I thought
pg_stat_progress_vacuum's output should've had
Yes sure. Thanks Tom.
On Fri, Feb 1, 2019 at 1:04 AM Tom Lane wrote:
> Since we've reached the end of the January commitfest, and it's pretty
> clear that this patch isn't going to get committed in anything like
> its current form, I'm going to close the CF entry as returned with
> feedback.
On 2/13/19 4:13 AM, Chapman Flack wrote:
> On 02/12/19 22:00, Jonathan S. Katz wrote:
>> Attached is a draft of the press release for the upcoming 2019-02-14
>> release. Feedback & suggestions are welcome.
>
>
> Users on PostgreSQL 9.4 should plan to upgrade to a supported version of
>
On 02/12/19 22:00, Jonathan S. Katz wrote:
> Attached is a draft of the press release for the upcoming 2019-02-14
> release. Feedback & suggestions are welcome.
Users on PostgreSQL 9.4 should plan to upgrade to a supported version of
PostgreSQL as the community will stop releasing fixes for
On 2/12/19 5:45 PM, Jonathan S. Katz wrote:
>
>> On Feb 12, 2019, at 5:12 PM, Tom Lane wrote:
>>
>> The part about having a unified release-note archive somewhere else is
>> still WIP. The ball is in the web team's court on that, I think.
>
> Yes - we are going to try one thing with the
Hi,
Attached is a draft of the press release for the upcoming 2019-02-14
release. Feedback & suggestions are welcome.
Thanks!
Jonathan
2019-02-14 Cumulative Update Release
The PostgreSQL Global Development Group has released an update to all supported
On Wed, 13 Feb 2019 at 00:46, Alvaro Herrera
wrote:
> Here's a sample
> concurrent index build on a 100M tuple table.
Cool
> There are no concurrent
> transactions, so phases that wait for lockers don't appear.
Would prefer to see them, so we know they are zero.
--
Simon Riggs
From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
> > I didin't consider planning that happen within a function. If
> > 5min is the default for catalog_cache_prune_min_age, 10% of it
> > (30s) seems enough and gettieofday() with such intervals wouldn't
> > affect forground jobs. I'd choose
From: Andrew Gierth [mailto:and...@tao11.riddles.org.uk]
> Tsunakawa> SELECT pg_stat_get_backend_pid(backendid);
>
> Doesn't work - that function's idea of "backend id" doesn't match the
> real one, since it's looking at a local copy of the stats from which
> unused slots have been removed.
On Wed, Feb 13, 2019 at 12:38:51AM +, Andrew Gierth wrote:
> Doesn't work - that function's idea of "backend id" doesn't match the
> real one, since it's looking at a local copy of the stats from which
> unused slots have been removed.
The temporary namespace OID is added to PGPROC since v11,
On Tue, Feb 12, 2019 at 07:13:45PM -0300, Alvaro Herrera wrote:
> It was reasonable to close this patch as returned-with-feedback in
> January commitfest, but what you did here was first move it to the March
> commitfest and then close it as returned-with-feedback in the March
> commitfest, which
On Mon, Feb 11, 2019 at 10:33 AM Tom Lane wrote:
> Thomas Munro writes:
> > So I'll wait until after the release, and we'll have
> > to live with the bug for another 3 months.
>
> Check. Please hold off committing until you see the release tags
> appear, probably late Tuesday my time /
> "Tsunakawa" == Tsunakawa, Takayuki
> writes:
>> From the temp table namespace I can get the backend ID using a regex
>> - but I have no idea how I can map that to a PID - any thoughts?
Tsunakawa> SELECT pg_stat_get_backend_pid(backendid);
Doesn't work - that function's idea of
From: James Sewell [mailto:james.sew...@jirotech.com]
> From the temp table namespace I can get the backend ID using a regex - but
> I have no idea how I can map that to a PID - any thoughts?
>
SELECT pg_stat_get_backend_pid(backendid);
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> I'm at a loss how call syscache for users. I think it is "catalog
> cache". The most basic component is called catcache, which is
> covered by the syscache layer, both of then are not revealed to
> users, and it is shown to user as
Hi all,
I hit an issue yesterday where I was quickly nearing XID wraparound on a
database due to a temp table being created in a session which was then left
IDLE out of transaction for 6 days.
I solved the issue by tracing the owner of the temp table back to a session
and terminating it - in my
On 2019-Feb-04, Michael Paquier wrote:
> On Thu, Jan 31, 2019 at 04:38:27AM -0800, Andres Freund wrote:
> > Is this still in development? Or should we mark this as returned with
> > feedback?
>
> Marked as returned with feedback, as it has already been two months.
> If you have an updated patch
On 2019-Feb-12, Arseny Sher wrote:
>
> Alvaro Herrera writes:
>
> >> I thought the blanket removal of the assert() was excessive, and we can
> >> relax it instead; what do you think of the attached?
> >
> > More precisely, my question was: with this change, does the code still
> > work
Hi Sergei,
Thank you for this review !
>Did you register patch in CF app? I did not found entry.
I think it is related to https://commitfest.postgresql.org/16/1373/
but I don't know how to link it with.
Yes, there are many things to improve, but before to go deeper,
I would like to know if
Stephen Frost writes:
> * Robbie Harwood (rharw...@redhat.com) wrote:
>> Stephen Frost writes:
>>> * Robbie Harwood (rharw...@redhat.com) wrote:
Stephen Frost writes:
> * Robbie Harwood (rharw...@redhat.com) wrote:
>
>> Attached please find version 20 of the GSSAPI encryption
Greetings,
* Robbie Harwood (rharw...@redhat.com) wrote:
> Stephen Frost writes:
> > * Robbie Harwood (rharw...@redhat.com) wrote:
> >> Stephen Frost writes:
> >>> * Robbie Harwood (rharw...@redhat.com) wrote:
> >>>
> Attached please find version 20 of the GSSAPI encryption support.
>
Stephen Frost writes:
> * Robbie Harwood (rharw...@redhat.com) wrote:
>> Stephen Frost writes:
>>> * Robbie Harwood (rharw...@redhat.com) wrote:
>>>
Attached please find version 20 of the GSSAPI encryption support.
This has been rebased onto master (thanks Stephen for calling out
On 11.02.2019 21:25, Arthur Zakirov wrote:
Hello hackers,
Grigory noticed that one of our utilities has very slow performance when
xlogreader reads zlib archives. We found out that xlogreader sometimes
reads a WAL file block twice.
zlib has slow performance when you read an archive not
On 2/12/19 12:35 PM, Kyotaro HORIGUCHI wrote:
> Thank you for testing and the commits, Tomas.
>
> At Sat, 9 Feb 2019 19:09:59 +0100, Tomas Vondra
> wrote in
> <74386116-0bc5-84f2-e614-0cff19aca...@2ndquadrant.com>
>> On 2/7/19 1:18 PM, Kyotaro HORIGUCHI wrote:
>>> At Thu, 07 Feb 2019
Tom Lane schrieb am 12.02.2019 um 17:12:
Yeah, see 527b5ed1a et al.
The part about having a unified release-note archive somewhere else is
still WIP. The ball is in the web team's court on that, I think.
The Bucardo team has already done that:
https://bucardo.org/postgres_all_versions.html
> On Feb 12, 2019, at 5:12 PM, Tom Lane wrote:
>
> The part about having a unified release-note archive somewhere else is
> still WIP. The ball is in the web team's court on that, I think.
Yes - we are going to try one thing with the existing way we load docs to try
to avoid
additional
> On 12 Feb 2019, at 16:00, Greg Stark wrote:
>
> I was just perusing our PDF docs for the first time in ages and
> realized that of the 3,400+ pages of docs there's about 1,000 pages of
> release notes in it That seems like a bit overkill.
>
> I love having the old release notes online
On Tue, 12 Feb 2019 at 08:54, Ramanarayana wrote:
> Hi Michael,
> The issue was that the python script was working in python 2 but not in
> python 3 in Windows. This is because the python script writes the final
> output to stdout and stdout encoding is set to utf-8 only for python 2 but
> not
On 2/12/19, Alvaro Herrera wrote:
> Pushed, thanks.
Thank you.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andres Freund writes:
> On 2019-02-12 11:00:51 -0500, Greg Stark wrote:
>> I love having the old release notes online but perhaps they can be
>> somewhere other than the main docs? We could limit the current docs to
>> including the release notes for just the supported versions -- after
>> all
Alvaro Herrera writes:
>> I thought the blanket removal of the assert() was excessive, and we can
>> relax it instead; what do you think of the attached?
>
> More precisely, my question was: with this change, does the code still
> work correctly in your non-toy case?
Yes, it works. I thought
Hi,
On 2019-02-12 11:00:51 -0500, Greg Stark wrote:
> I was just perusing our PDF docs for the first time in ages and
> realized that of the 3,400+ pages of docs there's about 1,000 pages of
> release notes in it That seems like a bit overkill.
>
> I love having the old release notes online
I was just perusing our PDF docs for the first time in ages and
realized that of the 3,400+ pages of docs there's about 1,000 pages of
release notes in it That seems like a bit overkill.
I love having the old release notes online but perhaps they can be
somewhere other than the main docs? We
On 2019-Feb-12, Alvaro Herrera wrote:
> On 2019-Feb-08, John Naylor wrote:
>
> > On Thu, Feb 7, 2019 at 6:53 PM David Fetter wrote:
> > > [some style suggestions]
> >
> > I've included these in v2, and also some additional tweaks for consistency.
>
> I noticed that because we have this line
On 2019-Feb-08, John Naylor wrote:
> On Thu, Feb 7, 2019 at 6:53 PM David Fetter wrote:
> > [some style suggestions]
>
> I've included these in v2, and also some additional tweaks for consistency.
I noticed that because we have this line in the scripts,
BEGIN { use lib
Matsumura-san,
> I try to explain as follows. I would like to receive your comment.
> ...
I'm afraid I don't really understand your explanation. Why is handling
a bytea so different from handling a varchar? I can see some
differences due to its binary nature, but I do not understand why it
needs
On 2/11/19 5:28 PM, Peter Eisentraut wrote:
One mitigation is to not write code like that, that is, don't put secret
parameters and user-supplied content into the same to-be-compressed
chunk, or at least don't let the end user run that code at will in a
tight loop.
The difference in CRIME is
Hi Michael,
The issue was that the python script was working in python 2 but not in
python 3 in Windows. This is because the python script writes the final
output to stdout and stdout encoding is set to utf-8 only for python 2 but
not python 3.If no encoding is set for stdout it takes the encoding
On 2019-Feb-11, Alvaro Herrera wrote:
> On 2019-Feb-07, Arseny Sher wrote:
>
> > Alvaro Herrera writes:
>
> > > Ah, okay. Does the test still fail when run without the code fix?
> >
> > Yes. The problem here is overriding cmax of catalog (pg_attribute in the
> > test) tuples, so it fails
Hello
Thank you for picking this up! Did you register patch in CF app? I did not
found entry.
Currently we have pg_stat_statements 1.7 version and this patch does not
apply... My fast and small view:
> - errmsg("could not read file \"%s\": %m",
> +
> On 12. Feb 2019, at 05:12, Michael Paquier wrote:
>
> On Mon, Feb 11, 2019 at 08:57:41PM -0700, Kevin Hale Boyes wrote:
>> I think there's a small problem with the commit.
>> The position of xlrec.max_wal_senders (line 117) should be below
>> max_worker_processes.
>
> Fixed, thanks!
Hi Dmitry,
On 11.02.2019 17:39, Dmitry Vasiliev wrote:
What is the scope of logical replication if I cannot make recovery
from pg_basebackup?
No, you can, but there are some things to keep in mind:
1) I could be wrong, but usage of pgbench in such a test seems to be a
bad idea, since it
Etsuro Fujita wrote:
> (2019/02/08 21:35), Etsuro Fujita wrote:
> > (2019/02/08 2:04), Antonin Houska wrote:
> >> * add_foreign_ordered_paths()
> >>
> >> Exprssion root->upper_targets[UPPERREL_FINAL] is used to access the
> >> target.
> >>
> >> I think create_ordered_paths() should actually set
At Tue, 12 Feb 2019 01:02:39 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FB972A6@G01JPEXMBYT05>
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> > Recuded frequency of dlist_move_tail by taking 1ms interval between two
> > succesive updates on the
Thank you for testing and the commits, Tomas.
At Sat, 9 Feb 2019 19:09:59 +0100, Tomas Vondra
wrote in <74386116-0bc5-84f2-e614-0cff19aca...@2ndquadrant.com>
> On 2/7/19 1:18 PM, Kyotaro HORIGUCHI wrote:
> > At Thu, 07 Feb 2019 15:24:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> > wrote
Meskes-san
Thank you for your review.
> There is one thing that I don't understand right now. YOu
> change ecpg_store_input() to handle the bytea data type, yet you also
> change ECPGset_desc() to not use ecpg_store_input() in case of an
> bytea. This looks odd to me. Can you please explain that
Hi
> I think this is tentatively confirmed..I ran 20 loops for over 90 minutes with
> no crash when parallel_leader_participation=off.
>
> On enabling parallel_leader_participation, crash within 10min.
>
> Sergei, could you confirm ?
I still have error with parallel_leader_participation = off.
At Fri, 8 Feb 2019 09:42:20 +, "Ideriha, Takeshi"
wrote in
<4E72940DA2BF16479384A86D54D0988A6F41EDD1@G01JPEXMBKW04>
> >From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> >I made a rerun of benchmark using "-S -T 30" on the server build with no
> >assertion and
> >-O2. The
Etsuro Fujita wrote:
> (2019/02/08 2:04), Antonin Houska wrote:
>
> > First, I wonder if the information on LIMIT needs to be passed to the
> > FDW. Cannot the FDW routines use root->tuple_fraction?
>
> I think it's OK for the FDW to use the tuple_fraction, but I'm not sure the
>
On 12.02.2019 07:23, Michael Paquier wrote:
On 02/11/2019 07:25 PM, Arthur Zakirov wrote:
Grigory noticed that one of our utilities has very slow performance when
xlogreader reads zlib archives. We found out that xlogreader sometimes
reads a WAL file block twice.
What do you think?
I think
Hi
út 12. 2. 2019 v 2:00 odesílatel Chapman Flack
napsal:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
64 matches
Mail list logo
