Hello.
At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin
wrote in
> Hello, hackers!
>
> I`d like to propose a new argument for recovery_target parameter,
> which will stand to recovering until all available WAL segments are
> applied.
>
> Current PostgreSQL recovery default behavior(when no
On Sat, 2 Nov 2019 at 02:10, Robert Haas wrote:
>
> On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih wrote:
> > Sounds like an interesting idea, but does it really help? Because if
> > vacuum was interrupted previously, wouldn't it already know the dead
> > tuples, etc in the next run quite quickly,
On Mon, Nov 4, 2019 at 11:42 PM Andres Freund wrote:
>
>
> > The two approaches to solve this problem being discussed in that
> > thread [1] are as follows:
> > (a) Allow the parallel workers and master backend to have a shared
> > view of vacuum cost related parameters (mainly VacuumCostBalance)
On Sat, Nov 2, 2019 at 4:40 PM Michael Paquier wrote:
>
> On Fri, Nov 01, 2019 at 02:17:03PM +0500, Ibrar Ahmed wrote:
> > Do we really need a regression test cases for such small oversights?
>
> It is possible to get the command tags using an event trigger... But
> that sounds hack-ish.
Yes,
On Mon, Nov 4, 2019 at 5:22 PM Amit Kapila wrote:
>
> On Wed, Oct 30, 2019 at 9:38 AM vignesh C wrote:
> >
> > On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra
> > wrote:
> > >
> > > I think the patch should do the simplest thing possible, i.e. what it
> > > does today. Otherwise we'll never get
On Sun, Nov 3, 2019 at 4:43 AM Tom Lane wrote:
> Amit Langote writes:
> >> This would
> >> probably require refactoring things so that there are separate
> >> entry points to add child equivalences for base rels and join rels.
> >> But that seems cleaner anyway than what you've got here.
>
> >
On Mon, Nov 4, 2019 at 9:09 PM Euler Taveira wrote:
> >
> > But this seems pointless. Should we not hide those? Seems this only
> > happened as an unintended side-effect of fc70a4b0df38. It appears to me
> > that we should redefine that view to restrict backend_type that's
> > 'client backend'
At Mon, 04 Nov 2019 12:53:48 -0500, Tom Lane wrote in
> Yuya Watari writes:
> > I attached the modified patch. In the patch, I placed the macro in
> > "src/include/c.h", but this may not be a good choice because c.h is
> > widely included from a lot of files. Do you have any good ideas about
>
On Sat, Nov 02, 2019 at 09:54:54PM -0400, Jeff Janes wrote:
> While monitoring pg_stat_subscription, I noticed that last_msg_send_time
> was usually NULL, which doesn't make sense. Why would we have a message,
> but not know when it was sent?
So... The timestamp is received and stored in
On Sun, Nov 03, 2019 at 10:53:00PM -0500, Tom Lane wrote:
> That is, TestLib::slurp_file is failing to read a file. Almost
> certainly, "permission denied" doesn't really mean a permissions
> problem, but failure to specify the file-opening flags needed to
> allow concurrent access on Windows.
On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
wrote:
> Here's a rebased version of this patch (it had a trivial conflict).
Hi, FYI partition_prune.sql currently fails (maybe something to do
with commit d52eaa09?):
where s.a = $1 and s.b = $2 and s.c = (select 1);
explain (costs off) execute
On Fri, Nov 1, 2019 at 9:41 PM Peter Eisentraut
wrote:
>
> On 2019-10-21 08:44, Fujii Masao wrote:
> > Probably we can use standby mode + recovery target setting for
> > the almost same purpose. In this configuration, if end-of-WAL is reached
> > before recovery target, the startup process keeps
On Mon, Nov 04, 2019 at 03:31:27PM -0500, Tom Lane wrote:
> I'd rather do something like the attached, which makes it more of an
> explicit goal that we won't fail on bad input. (As written, we'd only
> fail on bad classId, which is a case that really shouldn't happen.)
Okay, that part looks
On Mon, Nov 04, 2019 at 10:54:52AM -0500, Tom Lane wrote:
> It's time to start the next commitfest. I seem to recall somebody
> saying back in September that they'd run the next one, but I forget
> who. Anyway, we need a volunteer to be chief nagger.
That may have been me. I can take this one
Hi!
Thread [1] about support for .datetime() jsonpath method raises a
question about standard-conforming parising for Y, YY, YYY and RR
datetime template patterns.
According to standard YYY, YY and Y should get higher digits from
current year. Our current implementation gets higher digits so
On Sat, Nov 02, 2019 at 05:19:11PM +0900, Michael Paquier wrote:
> Sounds fine. So gathering everything I get the attached. Any
> thoughts from others?
Committed after splitting the changes in two as originally proposed.
--
Michael
signature.asc
Description: PGP signature
> When a zedstore table is queried using *invalid* ctid, the server
> crashes due to assertion failure. See below,
>
> postgres=# select * from t1 where ctid = '(0, 0)';
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing
On 2019/10/28 12:39, Kyotaro Horiguchi wrote:
Hello.
# The patch no longer applies on the current master. Needs a rebasing.
New patch, rebased on master branch.
At Sat, 26 Oct 2019 16:50:48 +0800, Quan Zongliang
wrote in
In fact, the replication property of the table has not been
On Thu, Oct 31, 2019 at 05:55:55PM +0900, Michael Paquier wrote:
> Thanks. I exactly did the same thing on my local branch.
Hearing nothing more, I have done some adjustments to the patch and
committed it. Please note that I have not switched the old interface
to be static to reloptions.c as if
On Sat, Oct 19, 2019 at 11:52 PM Tomas Vondra
wrote:
> I wonder if an extension could do something like that, though. It can
> install a hook after parse analysis, so I guess it could walk the CTEs
> and mark them as materialized.
I wonder if the existing pg_hint_plan extension could be extended
On Mon, Nov 04, 2019 at 03:26:35PM +1300, Thomas Munro wrote:
> On Thu, Aug 1, 2019 at 6:51 PM Noah Misch wrote:
> > vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to
> > unlink
> > vac_truncate_clog() instance 2 starts, considers segment ABCD eligible to
> > unlink
> >
On Sat, Oct 19, 2019 at 02:35:42PM -0400, Isaac Morland wrote:
> On Sat, 19 Oct 2019 at 13:36, Stephen Frost wrote:
>
> Greetings,
>
> * Isaac Morland (isaac.morl...@gmail.com) wrote:
> > That embeds a temporary hack in the application code indefinitely.
>
> ... one could argue
On Mon, Nov 4, 2019 at 11:13 PM Julien Rouhaud wrote:
> When working on the REINDEX FILTER, I totally missed this thread and
I created a new wiki page to try to track the various moving pieces
here. Julien, Peter, Christoph, anyone interested, please feel free
to update it or add more
On Thu, Sep 26, 2019 at 8:05 AM Alvaro Herrera wrote:
> This patch seems to be failing the contrib build. Please fix.
Hi Pierre,
In contrib/pg_stat_statements/pg_stat_statements.c, you need to
declare or define entry_reset_computed() before you use it. I suppose
your compiler must be warning
Hi
po 4. 11. 2019 v 21:55 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 18. 9. 2019 v 12:52 odesílatel Ahsan Hadi
> napsal:
> >> does this patch have any value for psql without pspg?
>
> > The benefit of this patch is just for pspg users today.
>
> TBH, I think we should just
On Sat, Nov 2, 2019 at 6:57 AM Andrew Dunstan
wrote:
> On 11/1/19 11:01 AM, Robert Haas wrote:
> > On Thu, Oct 31, 2019 at 11:37 AM Andrew Dunstan
> > wrote:
> >> This patch provides a hook for a function that can supply an SSL
> >> passphrase. The hook can be filled in by a shared preloadable
Benjie Gillam writes:
>> Your patch has two warnings because you are trying to map a policy
>> info pointer to a trigger info pointer:
> Ah, thank you for the pointer (aha); I've attached an updated patch
> that addresses this copy/paste issue.
LGTM, pushed (with a bit of extra polishing of
On Mon, Nov 4, 2019 at 11:13 PM Julien Rouhaud wrote:
> On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote:
> > * Some have expressed doubt that pg_depend is the right place for
> > this; let's see if any counter-proposals appear.
>
> When working on the REINDEX FILTER, I totally missed this
On Tue, Nov 5, 2019 at 4:18 AM Julien Rouhaud wrote:
> On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote:
> > On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote:
> > > Here are some problems to think about:
> > >
> > > * We'd need to track dependencies on the default collation once we
> > >
Pavel Stehule writes:
> st 18. 9. 2019 v 12:52 odesílatel Ahsan Hadi napsal:
>> does this patch have any value for psql without pspg?
> The benefit of this patch is just for pspg users today.
TBH, I think we should just reject this patch. It makes psql's
table-printing behavior even more
Hi,
On 2019-11-04 14:58:20 -0500, Robert Haas wrote:
> On Mon, Nov 4, 2019 at 2:04 PM Andres Freund wrote:
> > Is that really true? In the case where it started and failed we except
> > the error queue to have been attached to, and there to be either an
> > error 'E' or a 'X' response (cf
On Tue, Nov 5, 2019 at 8:45 AM Tomas Vondra
wrote:
> On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
> >On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
> >> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> >> > And "without causing significant issues elsewhere"
Michael Paquier writes:
> Okay. Attached is what I was thinking about, with extra regression
> tests to cover the ground for toast tables and indexes that are able
> to reproduce the original failure, and more comments for the routines
> as they should be used only for ACL error messages.
I'd
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-11-04 14:33:41 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On 2019-11-04 14:06:19 -0500, Stephen Frost wrote:
> > > > With parallelization across indexes, you could have a situation where
> > >
On Mon, Nov 4, 2019 at 2:04 PM Andres Freund wrote:
> Is that really true? In the case where it started and failed we except
> the error queue to have been attached to, and there to be either an
> error 'E' or a 'X' response (cf HandleParallelMessage()). It doesn't
> strike me as very
On Mon, Nov 04, 2019 at 10:44:53AM -0800, Andres Freund wrote:
Hi,
On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> And "without causing significant issues elsewhere" unfortunately
> includes continuing to allow pg_upgrade to
On 2019-Nov-04, Euler Taveira wrote:
> Em seg., 4 de nov. de 2019 às 16:12, Alvaro Herrera
> escreveu:
> > I'm not sure if we need to call out the incompatibility in the minors'
> > release notes (namely, that people using "-f-" to dump to ./- will need
> > to choose a different file name).
> >
Hi,
On 2019-11-04 14:33:41 -0500, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2019-11-04 14:06:19 -0500, Stephen Frost wrote:
> > > With parallelization across indexes, you could have a situation where
> > > the individual indexes are on different tablespaces with
On 2019-Nov-04, Tom Lane wrote:
> Alvaro Herrera writes:
> > Turns out that this is a simple partial cherry-pick of the original
> > commit.
>
> In the back branches, you should keep the statement that stdout
> is the default output file. Looks sane otherwise (I didn't test it).
I propose
> "Tom" == Tom Lane writes:
>> On 2019-11-04 19:04:52 +, Andrew Gierth wrote:
>>> Uh, it seems obvious to me that it should be backpatched?
>> Fine with me. But I don't think it's just plainly obvious, it's
>> essentailly a change in query plans etc, and we've been getting more
>>
Em seg., 4 de nov. de 2019 às 16:12, Alvaro Herrera
escreveu:
> I'm not sure if we need to call out the incompatibility in the minors'
> release notes (namely, that people using "-f-" to dump to ./- will need
> to choose a different file name).
>
Should we break translations? I'm -0.5 on changing
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-11-04 14:06:19 -0500, Stephen Frost wrote:
> > * Jeff Janes (jeff.ja...@gmail.com) wrote:
> > > On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila
> > > wrote:
> > > > For parallel vacuum [1], we were discussing what is the best way to
>
Alvaro Herrera writes:
> Turns out that this is a simple partial cherry-pick of the original
> commit.
In the back branches, you should keep the statement that stdout
is the default output file. Looks sane otherwise (I didn't test it).
> I'm not sure if we need to call out the incompatibility
Andres Freund writes:
> On 2019-11-04 19:04:52 +, Andrew Gierth wrote:
>> Uh, it seems obvious to me that it should be backpatched?
> Fine with me. But I don't think it's just plainly obvious, it's
> essentailly a change in query plans etc, and we've been getting more
> hesitant with those
On 2019-Nov-04, Stephen Frost wrote:
> > Alvaro Herrera writes:
> > > +1 for this, FWIW. Let's get it done before next week minors. Is
> > > anybody writing a patch? If not, I can do it.
Turns out that this is a simple partial cherry-pick of the original
commit.
I'm not sure if we need to
Hi,
On 2019-11-04 19:04:52 +, Andrew Gierth wrote:
> > "Andres" == Andres Freund writes:
>
> >>> Obviously we _do_ need to be more picky about this; it seems clear
> >>> that using CP_SMALL_TLIST | CP_LABEL_TLIST would be a win in many
> >>> cases. Opinions?
>
> >> Seems reasonable
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-10-09 12:29:18 -0400, Robert Haas wrote:
> > I would say rather that if fork() is failing on your system, you have
> > a not very stable system.
>
> I don't think that's really true, fwiw. It's often a good idea to turn
> on strict
Hi,
On 2019-11-04 14:06:19 -0500, Stephen Frost wrote:
> * Jeff Janes (jeff.ja...@gmail.com) wrote:
> > On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote:
> > > For parallel vacuum [1], we were discussing what is the best way to
> > > divide the cost among parallel workers but we didn't get many
Greetings,
* Jeff Janes (jeff.ja...@gmail.com) wrote:
> On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote:
> > For parallel vacuum [1], we were discussing what is the best way to
> > divide the cost among parallel workers but we didn't get many inputs
> > apart from people who are very actively
Hi,
On 2019-11-04 12:14:53 -0500, Robert Haas wrote:
> If a process trying to register workers finds out that no worker slots
> are available, it discovers this at the time it tries to perform the
> registration. But fork() failure happens later and in a different
> process. The original process
> "Andres" == Andres Freund writes:
>>> Obviously we _do_ need to be more picky about this; it seems clear
>>> that using CP_SMALL_TLIST | CP_LABEL_TLIST would be a win in many
>>> cases. Opinions?
>> Seems reasonable to me, do you want to do the honors?
Andres> I was briefly
"imai.yoshik...@fujitsu.com" writes:
> Moon-san, kuroda.keisuke-san
> On Thu, Aug 29, 2019 at 8:20 AM, Moon, Insung wrote:
>> The patch is very simple.
>> Fix to increase the value of nEntries only when a non-duplicate GIN index
>> leaf added.
> Does nentries show the number of entries in the
Hi,
On 2019-10-09 12:29:18 -0400, Robert Haas wrote:
> I would say rather that if fork() is failing on your system, you have
> a not very stable system.
I don't think that's really true, fwiw. It's often a good idea to turn
on strict memory overcommit accounting, and with that set, it's actually
Hi,
On 2019-11-04 19:39:18 +0100, Tomas Vondra wrote:
> On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
> > And "without causing significant issues elsewhere" unfortunately
> > includes continuing to allow pg_upgrade to work.
> Yeah. I suppose we could have a different AM
On Mon, Nov 04, 2019 at 10:04:09AM -0800, Andres Freund wrote:
Hi,
(I've not read the rest of this thread yet)
On 2019-11-04 16:07:23 +0100, Tomas Vondra wrote:
On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
> And yet, if I try to implement a similar mechanism, if successful,
Hi,
On 2019-11-04 12:59:02 -0500, Jeff Janes wrote:
> On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote:
>
> > For parallel vacuum [1], we were discussing what is the best way to
> > divide the cost among parallel workers but we didn't get many inputs
> > apart from people who are very actively
Hi,
On 2019-11-04 12:24:35 +0530, Amit Kapila wrote:
> For parallel vacuum [1], we were discussing what is the best way to
> divide the cost among parallel workers but we didn't get many inputs
> apart from people who are very actively involved in patch development.
> I feel that we need some
Alvaro Herrera writes:
> On 2019-Nov-04, Robert Haas wrote:
>> On Mon, Nov 4, 2019 at 10:42 AM Alvaro Herrera
>> wrote:
>>> I agree with this point in principle. Everything else (queries,
>>> checkpointing) can fail, but it's critical that postmaster continues to
>>> run [...]
>> Sure, I'm
Hi,
On 2019-11-04 12:18:48 -0500, Tom Lane wrote:
> Andrew Gierth writes:
> > Using 92MB of disk for one integer seems excessive; the reason is clear
> > from the explain:
> > ...
> > so the whole width of the table is being stored in the tuplestore used
> > by the windowagg.
>
> > In
Hi,
(I've not read the rest of this thread yet)
On 2019-11-04 16:07:23 +0100, Tomas Vondra wrote:
> On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
> > And yet, if I try to implement a similar mechanism, if successful, will my
> > revision be considered?
> >
>
> Why
Hi,
On 2019-11-04 11:30:23 +, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>
> > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> >> I just noticed that when contrib/seg was converted to V1 calling
> >> convention (commit 389bb2818f4), the PG_GETARG_SEG_P()
Hi,
(minor note - on PG lists the style is to quote in-line and trip)
On 2019-11-04 10:35:25 +0100, Josef Šimánek wrote:
> Thanks for quick response. As I was testing this feature it shows all
> "possible" triggers to be executed running given query. The benefit of
> having this information in
On Mon, Nov 4, 2019 at 1:54 AM Amit Kapila wrote:
> For parallel vacuum [1], we were discussing what is the best way to
> divide the cost among parallel workers but we didn't get many inputs
> apart from people who are very actively involved in patch development.
> I feel that we need some more
Yuya Watari writes:
> I attached the modified patch. In the patch, I placed the macro in
> "src/include/c.h", but this may not be a good choice because c.h is
> widely included from a lot of files. Do you have any good ideas about
> its placement?
I agree that there's an actual bug here; it can
kerbrose khaled wrote:
> I would like to update unaccent.rules file to support Arabic letters. so
> could someone help me or tell me how could I add such contribution. I
> attached the file including the modifications, only the last 4 lines.
The Arabic letters are found in the Unicode
On 2019-Nov-04, Robert Haas wrote:
> On Mon, Nov 4, 2019 at 10:42 AM Alvaro Herrera
> wrote:
> > > True, it's not a situation you especially want to be in. However,
> > > I've lost count of the number of times that I've heard someone talk
> > > about how their system was overstressed to the
Andrew Gierth writes:
> Using 92MB of disk for one integer seems excessive; the reason is clear
> from the explain:
> ...
> so the whole width of the table is being stored in the tuplestore used
> by the windowagg.
> In create_windowagg_plan, we have:
> /*
> * WindowAgg can project, so
On Mon, Nov 4, 2019 at 10:42 AM Alvaro Herrera wrote:
> > True, it's not a situation you especially want to be in. However,
> > I've lost count of the number of times that I've heard someone talk
> > about how their system was overstressed to the point that everything
> > else was failing, but
[ redirecting to pgsql-hackers ]
I wrote:
> La Cancellera Yoann writes:
>> I am having issues with PAM auth :
>> it works, password are correctly checked, unknown users cannot access,
>> known user can, everything looks good
>> But, it always log an error by default even if auth is succesful:
>>
On 2019-Oct-19, Etsuro Fujita wrote:
> On Fri, Oct 18, 2019 at 6:56 PM Alvaro Herrera
> wrote:
> > Yeah, agreed. Instead of "the null comes from" I would use "the
> > partition that stores nulls".
>
> I think your wording is better than mine. Thank you for reviewing!
Thanks for getting
On 11/4/19 2:08 AM, Tomas Vondra wrote:
>
> Seems fine to me, mostly. I think the docs should explain how
> log_min_duration_statement interacts with log_min_duration_sample.
> Attached is a patch doing that, by adding one para to each GUC, along
> with some minor rewordings. I think the docs are
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > On 2019-Oct-17, Tom Lane wrote:
> >> Stephen Frost writes:
> >>> Tom, I take it your suggestion is to have '-f -' be accepted to mean
> >>> 'goes to stdout' in all branches?
>
> >> Yes.
>
> > +1 for this, FWIW.
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Nov 4, 2019 at 8:26 AM Alvaro Herrera
> wrote:
> > On 2019-Sep-04, Alvaro Herrera wrote:
> > > I just noticed that we list auxiliary processes in pg_stat_ssl:
> > [...]
> > > But this seems pointless. Should we not hide those?
It's time to start the next commitfest. I seem to recall somebody
saying back in September that they'd run the next one, but I forget
who. Anyway, we need a volunteer to be chief nagger.
regards, tom lane
On 2019-Oct-09, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Oct 9, 2019 at 10:21 AM Tom Lane wrote:
> >> We could improve on matters so far as the postmaster's child-process
> >> arrays are concerned, by defining separate slot "pools" for the different
> >> types of child processes. But
Hi Amit,
On Fri, 11 Oct 2019 at 08:06, Amit Langote wrote:
>
> Thanks for sharing this case. I hadn't considered it, but you're
> right that it should be handled sensibly. I have fixed table sync
> code to handle this case properly. Could you please check your case
> with the attached
Em qua., 4 de set. de 2019 às 12:15, Alvaro Herrera
escreveu:
>
> I just noticed that we list auxiliary processes in pg_stat_ssl:
>
> 55432 13devel 28627=# select * from pg_stat_ssl ;
> pid │ ssl │ version │ cipher │ bits │ compression │
> client_dn │ client_serial │ issuer_dn
On Mon, Nov 4, 2019 at 11:13 AM Julien Rouhaud wrote:
>
> On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote:
> >
> > Here are some problems to think about:
> >
> > * We'd need to track dependencies on the default collation once we
> > have versioning for that [...]
Another problem I just
Em seg., 4 de nov. de 2019 às 11:53, Alvaro Herrera
escreveu:
>
> On 2019-Oct-17, Tom Lane wrote:
>
> > Stephen Frost writes:
> > > First, I'd like to clarify what I believe Tom's suggestion is, and then
> > > talk through that, as his vote sways this topic pretty heavily.
> >
> > > Tom, I take
On Mon, Nov 04, 2019 at 04:39:44PM +0300, Павел Ерёмин wrote:
And yet, if I try to implement a similar mechanism, if successful, will my
revision be considered?
Why wouldn't it be considered? If you submit a patch that demonstrably
improves the behavior (in this case reduces per-tuple
Alvaro Herrera writes:
> On 2019-Oct-17, Tom Lane wrote:
>> Stephen Frost writes:
>>> Tom, I take it your suggestion is to have '-f -' be accepted to mean
>>> 'goes to stdout' in all branches?
>> Yes.
> +1 for this, FWIW. Let's get it done before next week minors. Is
> anybody writing a
Peter Eisentraut writes:
> On 2019-11-02 15:36, Tom Lane wrote:
>> I hadn't actually tested this patch before commit, but now that
>> it's in, I'm seeing assorted compiler warnings:
> I've fixed the ones that I could reproduce on CentOS 6. I haven't seen
> any on a variety of newer systems.
On Mon, 4 Nov 2019 at 19:26, Amit Kapila wrote:
>
> On Mon, Nov 4, 2019 at 1:51 PM Masahiko Sawada wrote:
> >
> > On Mon, Nov 4, 2019 at 3:54 PM Amit Kapila wrote:
> > >
> > > I think approach-2 is better in throttling the system as it doesn't
> > > have the drawback of the first approach, but
On 2019-Oct-17, Tom Lane wrote:
> Stephen Frost writes:
> > First, I'd like to clarify what I believe Tom's suggestion is, and then
> > talk through that, as his vote sways this topic pretty heavily.
>
> > Tom, I take it your suggestion is to have '-f -' be accepted to mean
> > 'goes to stdout'
On Mon, Nov 4, 2019 at 8:26 AM Alvaro Herrera wrote:
> On 2019-Sep-04, Alvaro Herrera wrote:
> > I just noticed that we list auxiliary processes in pg_stat_ssl:
> [...]
> > But this seems pointless. Should we not hide those? Seems this only
> > happened as an unintended side-effect of
And yet, if I try to implement a similar mechanism, if successful, will my revision be considered? regards03.11.2019, 22:15, "Tomas Vondra" :On Sun, Nov 03, 2019 at 02:17:15PM +0300, Павел Ерёмин wrote: I completely agree with all of the above. Therefore, the proposed mechanism may entail
On 2019-Sep-04, Alvaro Herrera wrote:
> I just noticed that we list auxiliary processes in pg_stat_ssl:
[...]
> But this seems pointless. Should we not hide those? Seems this only
> happened as an unintended side-effect of fc70a4b0df38. It appears to me
> that we should redefine that view to
On Fri, Nov 1, 2019 at 8:53 PM Robert Haas wrote:
> On Wed, Oct 30, 2019 at 10:16 AM Asif Rehman
> wrote:
> > 'startptr' is used by sendFile() during checksum verification. Since
> > SendBackupFiles() is using sendFIle we have to set a valid WAL location.
>
> Ugh, global variables.
>
> Why are
Hello, hackers!
I`d like to propose a new argument for recovery_target parameter, which
will stand to recovering until all available WAL segments are applied.
Current PostgreSQL recovery default behavior(when no recovery target is
provided) does exactly that, but there are several
On Wed, Oct 30, 2019 at 9:38 AM vignesh C wrote:
>
> On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra
> wrote:
> >
> > I think the patch should do the simplest thing possible, i.e. what it
> > does today. Otherwise we'll never get it committed.
> >
> I found a couple of crashes while reviewing and
On Wed, 30 Oct 2019 09:26:21 +0900
Michael Paquier wrote:
> On Tue, Oct 29, 2019 at 04:42:07PM -0700, Peter Geoghegan wrote:
> > The same commit from Heikki omitted one field from that record, for no
> > good reason. I backpatched a bugfix to the output format for nbtree
> > page splits a few
Tom Lane writes:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
>> I just noticed that when contrib/seg was converted to V1 calling
>> convention (commit 389bb2818f4), the PG_GETARG_SEG_P() macro got defined
>> in terms of PG_GETARG_POINTER(). But it itself calls
On Thu, 10 Oct 2019 at 05:49, Craig Ringer wrote:
>
> On Tue, 1 Oct 2019 at 02:08, Robert Haas wrote:
>>
>>
>> Why does create_logical_slot_on_standby include sleep(1)?
>
>
> Yeah, we really need to avoid sleeps in regression tests.
Yeah, have already got rid of the sleeps from the patch-series
This patch seems excessively complicated to me. Why don't you just add
the actual partitioned table to pg_publication_rel and then expand the
partition hierarchy in pgoutput (get_rel_sync_entry() or
GetRelationPublications() or somewhere around there). Then you don't
need to do any work in
On Mon, Nov 4, 2019 at 1:03 PM Darafei "Komяpa" Praliaskouski
wrote:
>>
>>
>> This is somewhat similar to a memory usage problem with a
>> parallel query where each worker is allowed to use up to work_mem of
>> memory. We can say that the users using parallel operation can expect
>> more system
On Mon, Nov 4, 2019 at 1:51 PM Masahiko Sawada wrote:
>
> On Mon, Nov 4, 2019 at 3:54 PM Amit Kapila wrote:
> >
> > I think approach-2 is better in throttling the system as it doesn't
> > have the drawback of the first approach, but it might be a bit tricky
> > to implement.
>
> I might be
On 2019-11-02 15:36, Tom Lane wrote:
I hadn't actually tested this patch before commit, but now that
it's in, I'm seeing assorted compiler warnings:
I've fixed the ones that I could reproduce on CentOS 6. I haven't seen
any on a variety of newer systems.
It's not clear why only a handful
On Thu, Oct 24, 2019 at 7:07 PM Amit Kapila wrote:
>
> On Tue, Oct 22, 2019 at 10:30 AM Dilip Kumar wrote:
> >
> > I have merged bugs_and_review_comments_fix.patch changes to 0001 and 0002.
> >
>
> I was wondering whether we have checked the code coverage after this
> patch? Previously, the
Hello Thomas,
On Mon, Nov 4, 2019 at 4:58 AM Thomas Munro wrote:
>
> On Fri, Nov 1, 2019 at 2:21 AM Julien Rouhaud wrote:
> > Are you planning to continue working on it? For the record, that's
> > something needed to be able to implement a filter in REINDEX command
> > [1].
>
> Bonjour Julien,
On Mon, Nov 4, 2019 at 3:32 PM Dilip Kumar wrote:
>
> So your result shows that with "streaming on", performance is
> degrading? By any chance did you try to see where is the bottleneck?
>
Right. But, as we increase the logical_decoding_work_mem, the
performance improves. I've not analyzed the
1 - 100 of 107 matches
Mail list logo
