> However having the nested queryid in
> pg_stat_activity would be convenient to track
> what is a long stored functions currently doing.
+1
And this could permit to get wait event sampling per queryid when
pg_stat_statements.track = all
Regards
PAscal
--
Sent from: https://www.postgresql
So this is the best commit messages I could come up with at this stupid
hour. I think the wording is pretty poor but at least it seems correct.
I'm not sure I'll be able to get this pushed tomorrow, but I'll try.
Improve pruning of a default partition
When querying a partitioned table contai
I had a look at the UNDO patches at
https://www.postgresql.org/message-id/CAA4eK1KKAFBCJuPnFtgdc89djv4xO%3DZkAdXvKQinqN4hWiRbvA%40mail.gmail.com,
and at the patch to use the UNDO logs to clean up orphaned files, from
undo-2019-05-10.tgz earlier in this thread. Are these the latest ones to
revie
On Wed, Jul 31, 2019 at 12:26 PM Andres Freund wrote:
>
> Hi,
>
> On 2019-07-31 11:19:08 +0530, vignesh C wrote:
> > I noticed that there are many header files being
> > included which need not be included.
> > I have tried this in a few files and found the
> > compilation and regression to be wor
> 2 авг. 2019 г., в 21:39, Andres Freund написал(а):
>
> On 2019-08-02 20:40:51 +0500, Andrey Borodin wrote:
>> We have some kind of "roadmap" of "extensible pglz". We plan to provide
>> implementation on Novembers CF.
>
> I don't understand why it's a good idea to improve the compression si
On Sun, Aug 04, 2019 at 02:41:24AM +0200, Petr Jelinek wrote:
Hi,
On 02/08/2019 21:48, Tomas Vondra wrote:
On Fri, Aug 02, 2019 at 11:20:03AM -0700, Andres Freund wrote:
Another question is whether we'd actually want to include the code in
core directly, or use system libraries (and if some
On 8/3/19 6:42 PM, Tom Lane wrote:
> I wrote:
>> * kerberos/t/001_auth.pl just blithely assumes that it can pick
>> any random port above 48K and that's guaranteed to be free.
>> Maybe we should split out the code in get_new_node for finding
>> a free TCP port, so we can call it here?
> I've conf
On 8/2/19 3:21 PM, Tom Lane wrote:
> See
> https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164
>
> Please send comments/corrections before Sunday.
While working on the PR, I noticed this line:
"This fixes a regression introduced in June's minor releases..."
Perhaps
On 2019-Aug-04, Alvaro Herrera wrote:
> So this is the best commit messages I could come up with at this stupid
> hour. I think the wording is pretty poor but at least it seems correct.
> I'm not sure I'll be able to get this pushed tomorrow, but I'll try.
Pushed. Since this is Sunday before mi
"Jonathan S. Katz" writes:
> Perhaps instead of "June" it could be the specific version number (which
> could cause some pain with the back branching?) or the "2019-06-20" release?
Putting in all the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the
Hi,
On 04/08/2019 11:57, Andrey Borodin wrote:
2 авг. 2019 г., в 21:39, Andres Freund написал(а):
On 2019-08-02 20:40:51 +0500, Andrey Borodin wrote:
We have some kind of "roadmap" of "extensible pglz". We plan to provide
implementation on Novembers CF.
I don't understand why it's a goo
Hi,
On 04/08/2019 13:52, Tomas Vondra wrote:
On Sun, Aug 04, 2019 at 02:41:24AM +0200, Petr Jelinek wrote:
Hi,
On 02/08/2019 21:48, Tomas Vondra wrote:
On Fri, Aug 02, 2019 at 11:20:03AM -0700, Andres Freund wrote:
Another question is whether we'd actually want to include the code in
core
Andrew Dunstan writes:
> On 8/3/19 6:42 PM, Tom Lane wrote:
>> So I propose the attached patch, which seems to fix this for me.
> Looks good. A couple of minor nits:
Will fix, thanks for the review!
regards, tom lane
On 8/4/19 10:52 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Perhaps instead of "June" it could be the specific version number (which
>> could cause some pain with the back branching?) or the "2019-06-20" release?
>
> Putting in all the version numbers seems like a mess, but specifying
> 2
On 8/4/19 11:08 AM, Jonathan S. Katz wrote:
> On 8/4/19 10:52 AM, Tom Lane wrote:
>> "Jonathan S. Katz" writes:
>>> Perhaps instead of "June" it could be the specific version number (which
>>> could cause some pain with the back branching?) or the "2019-06-20" release?
>>
>> Putting in all the ver
On Sun, Aug 04, 2019 at 05:53:26PM +0200, Petr Jelinek wrote:
...
4) I did a simple test with physical replication, with lz4 enabled on
both sides (well, can't build without lz4 anyway, per previous point).
It immediately failed like this:
FATAL: failed to restore block image
CONTEXT: WAL
=?UTF-8?B?SXZhbiBQYW5jaGVua28=?= writes:
> Tom Lane :
>> The core code seems to think that SvOK() is a sufficient test for an
>> undef. Should we be doing that before the switch, perhaps?
> Thank you, Tom. Yes, there is a solution with SvOK(), please see the attached
> patch.
Yeah, that looks
Hello everyone.
I am also was looking into possibility of such optimisation few days ago
(attempt to reduce memcpy overhead on IndexOnlyScan).
One thing I noticed here - whole page is scanned only if index quals are
"opened" at some side.
So, in case of
SELECT* FROM tbl WHERE k=:val AND ts
Hi,
On 2019-08-03 19:14:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I.e. something very roughly like
>
> > ereport(ERROR,
> > errmsg_rich("string with %{named}s references to %{parameter}s"),
> > errparam("named", somevar),
> > errparam("parameter", othervar, .re
On Fri, Aug 02, 2019 at 09:53:40AM +0200, Adrien Nayrat wrote:
On 8/1/19 12:04 PM, Tomas Vondra wrote:
On Thu, Aug 01, 2019 at 11:47:46AM +0200, Adrien Nayrat wrote:
Hi,
As we are at the end of this CF and there is still discussions about whether we
should revert log_statement_sample_limit and
Daniel Migowski writes:
> Am 03.08.2019 um 18:38 schrieb Tom Lane:
>> (After thinking a bit, I'm guessing that it seemed not to break because
>> your tests never actually exercised the generic-plan path, or perhaps
>> there was always a plancache invalidation before we tried to use the
>> query_li
Tomas Vondra writes:
> OK, I have the revert ready. The one thing I'm wondering about is
> whether we need to revert log_transaction_sample_rate too? I think it's
> pretty much independent feature, so I think we can keep that. Opinions?
Isn't the issue here the interaction between log_transaction
Hi,
On 2019-08-04 02:41:24 +0200, Petr Jelinek wrote:
> Same here.
>
> Just so that we don't idly talk, what do you think about the attached?
Cool!
> It:
> - adds new GUC compression_algorithm with possible values of pglz (default)
> and lz4 (if lz4 is compiled in), requires SIGHUP
As Tomas re
On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote:
Tomas Vondra writes:
OK, I have the revert ready. The one thing I'm wondering about is
whether we need to revert log_transaction_sample_rate too? I think it's
pretty much independent feature, so I think we can keep that. Opinions?
Isn'
Tomas Vondra writes:
> On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote:
>> Isn't the issue here the interaction between log_transaction_sample_rate
>> and log_min_duration_statement?
> No, that interaction only affects statement-level sampling.
OK, I was confusing the features.
> For t
On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote:
Isn't the issue here the interaction between log_transaction_sample_rate
and log_min_duration_statement?
No, that interaction only affects statement-level
Hello hackers,
Please consider fixing the next truss of typos and inconsistencies in
the tree:
9.1. NAMESPACE_SQLXML -> remove (not used since the introduction in
355e05ab)
9.2. NBXLOG_H -> NBTXLOG_H
9.3. NEWPAGE -> XLOG_FPI (orphaned since 54685338)
9.4. newXlogId, newXlogSeg -> newXlogSegNo (or
On Sun, Aug 04, 2019 at 10:48:48PM +0200, Tomas Vondra wrote:
On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote:
Isn't the issue here the interaction between log_transaction_sample_rate
and log_min_duration_
Hi,
On 04/08/2019 21:20, Andres Freund wrote:
On 2019-08-04 02:41:24 +0200, Petr Jelinek wrote:
Same here.
Just so that we don't idly talk, what do you think about the attached?
Cool!
It:
- adds new GUC compression_algorithm with possible values of pglz (default)
and lz4 (if lz4 is compile
On Fri, Aug 2, 2019 at 1:49 PM Ibrar Ahmed wrote:
> I did some clean-up on this patch. I have also refactored a small portion of
> the code
> to reduce the footprint of the patch. For simplicity, I have divided the
> patch into 6
> patches, now it is easy to review and debug.
> Please follow the
Hi,
On 2019-08-04 17:53:26 +0200, Petr Jelinek wrote:
> > 5) I wonder why compression_algorithm is defined as PGC_SIGHUP. Why not
> > to allow users to set it per session? I suppose we might have a separate
> > option for WAL compression_algorithm.
> >
>
> Yeah I was thinking we might want to ch
Hi,
On 05/08/2019 00:15, Andres Freund wrote:
Hi,
On 2019-08-04 17:53:26 +0200, Petr Jelinek wrote:
5) I wonder why compression_algorithm is defined as PGC_SIGHUP. Why not
to allow users to set it per session? I suppose we might have a separate
option for WAL compression_algorithm.
Yeah I w
On Sat, Aug 3, 2019 at 12:06 AM Robert Haas wrote:
> On Fri, Aug 2, 2019 at 6:37 AM Thomas Munro wrote:
> > Thanks. This looks pretty reasonable to me, and I don't think we need
> > to worry about the subxid list for now.
>
> Why not just do them all at once?
[tries for a couple of hours and ab
Hi,
On 2019-08-05 13:15:19 +1200, Thomas Munro wrote:
> On Sat, Aug 3, 2019 at 12:06 AM Robert Haas wrote:
> > On Fri, Aug 2, 2019 at 6:37 AM Thomas Munro wrote:
> > > Thanks. This looks pretty reasonable to me, and I don't think we need
> > > to worry about the subxid list for now.
> >
> > Why
Hi Alvaro,
On Mon, Aug 5, 2019 at 12:24 AM Alvaro Herrera wrote:
>
> On 2019-Aug-04, Alvaro Herrera wrote:
>
> > So this is the best commit messages I could come up with at this stupid
> > hour. I think the wording is pretty poor but at least it seems correct.
> > I'm not sure I'll be able to ge
On 2019-Aug-04, Alvaro Herrera wrote:
> Improve pruning of a default partition
I just noticed that I failed to credit Shawn Wang, Thibaut Madeleine,
Yoshikazu Imai, Kyotaro Horiguchi as reviewers of this patch.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development
I propose the comment rewordings as attached. Mostly, this updates the
comment atop the function to cover the case being modified, and then the
new comment just refers to the new explicitly stated policy, so it
bcomes simpler.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Postgre
Hi Alvaro and Amit,
Thanks for reviewing and fixing the patch.
Also, I confirmed the commit message explained
the modification clearly. Thanks a lot.
Yuzuko Hosoya
On Mon, Aug 5, 2019 at 12:24 AM Alvaro Herrera wrote:
>
> On 2019-Aug-04, Alvaro Herrera wrote:
>
> > So this is the best commit
On Mon, Aug 5, 2019 at 1:44 PM Andres Freund wrote:
> On 2019-08-05 13:15:19 +1200, Thomas Munro wrote:
> > On Sat, Aug 3, 2019 at 12:06 AM Robert Haas wrote:
> > > On Fri, Aug 2, 2019 at 6:37 AM Thomas Munro
> > > wrote:
> > > > Thanks. This looks pretty reasonable to me, and I don't think we
Hi,
On 2019-08-05 14:44:37 +1200, Thomas Munro wrote:
> Yeah. I think we're agreed for now that we don't want to change
> procarray (though we still need to figure out how to compute the 64
> bit horizons correctly and efficiently)
Hm. Is that actually hard? Can't we just use the current logic to
On Mon, Aug 05, 2019 at 12:33:34AM +0300, Alexander Lakhin wrote:
> 9.1. NAMESPACE_SQLXML -> remove (not used since the introduction in
> 355e05ab)
Looks important to keep as a matter of documentation.
> 9.12. not_point -> is_point (a contradiction with the check and a
> comment, appeared in 4c13
Hi all,
I have noticed today that the two functions in $subject are part of
libpq and remain around undocumented since they are around (see
6ef5846 and 2b84cbb). Isn't it past time to get rid of them? We have
PQprint as well, which was used in the past by psql but not today,
still that's documen
Hello Michael,
05.08.2019 6:15, Michael Paquier wrote:
>> 9.41. OWNER_TO -> OWNER TO
> This one needs a back-patch. I'll fix that separately.
>
I believe that all the fixes in doc/ should be back-patched too. If it's
not too late, I can produce such patches for the nearest releases.
>> 9.75. Poin
On Sun, Aug 4, 2019 at 12:13 PM Michael Paquier wrote:
> On Sat, Aug 03, 2019 at 11:57:01PM -0400, Alvaro Herrera wrote:
> > Can we please change the macro definition so that have_error is one of
> > the arguments? Having the variable be used inside the macro definition
> > but not appear litera
On Sun, Aug 4, 2019 at 2:46 PM Heikki Linnakangas wrote:
>
> I had a look at the UNDO patches at
> https://www.postgresql.org/message-id/CAA4eK1KKAFBCJuPnFtgdc89djv4xO%3DZkAdXvKQinqN4hWiRbvA%40mail.gmail.com,
> and at the patch to use the UNDO logs to clean up orphaned files, from
> undo-2019-05-1
On Mon, Aug 5, 2019 at 3:54 PM Amit Kapila wrote:
> On Sun, Aug 4, 2019 at 2:46 PM Heikki Linnakangas wrote:
> > I had a look at the UNDO patches at
> > https://www.postgresql.org/message-id/CAA4eK1KKAFBCJuPnFtgdc89djv4xO%3DZkAdXvKQinqN4hWiRbvA%40mail.gmail.com,
> > and at the patch to use the UN
Hi,
On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita wrote:
> On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > > If those are the choices, adding a parameter is clearly the preferable
> > > solution, because it makes the API breakage obvious a
Bonjour Michaël,
I have noticed today that the two functions in $subject are part of
libpq and remain around undocumented since they are around (see
6ef5846 and 2b84cbb). Isn't it past time to get rid of them? We have
PQprint as well, which was used in the past by psql but not today,
still th
Hi Alvaro,
Thanks for reviewing.
The modification you made seems correct to me.
However, I'm still concerned that the block
-
if (partconstr)
{
partconstr = (List *)
expression_planner((Expr *) partconstr);
if (context->rel->relid != 1)
Amit-san,
On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita wrote:
> > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > > On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > > > If those are the choices, adding a parameter is clearly the pref
On Mon, Aug 05, 2019 at 12:15:21PM +0900, Michael Paquier wrote:
> On Mon, Aug 05, 2019 at 12:33:34AM +0300, Alexander Lakhin wrote:
>> 9.41. OWNER_TO -> OWNER TO
>
> This one needs a back-patch. I'll fix that separately.
Done separately as of 05ba837, and back-patched down to 9.6 as this
has be
Fujita-san,
Thanks for the quick follow up.
On Mon, Aug 5, 2019 at 2:31 PM Etsuro Fujita wrote:
> On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> > On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita
> > wrote:
> > > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > > > On 2019-08-03 13:
On Mon, Aug 05, 2019 at 06:44:46AM +0300, Alexander Lakhin wrote:
> I believe that all the fixes in doc/ should be back-patched too. If it's
> not too late, I can produce such patches for the nearest releases.
I think that's unfortunately a bit too late for this release. Those
things have been ar
Amit-san,
On Mon, Aug 5, 2019 at 2:36 PM Amit Langote wrote:
> On Mon, Aug 5, 2019 at 2:31 PM Etsuro Fujita wrote:
> > On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> > > On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita
> > > wrote:
> > > > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote
On Mon, Aug 05, 2019 at 06:54:32AM +0200, Fabien COELHO wrote:
> How do you know that they are not used by anyone in the wild?
> If they are broken, it would be a clue. If not, possibly someone somewhere
> could be using it, eg for debug (what does this result look like?).
They have been around fo
On Wed, Jul 24, 2019 at 11:59 AM Thomas Munro wrote:
> On Tue, Jul 16, 2019 at 12:21 PM Tom Lane wrote:
> > In the meantime, we've had *lots* of buildfarm failures in the
> > added pg_stat_all_tables query, which indicate that indeed the
> > stats collector mechanism isn't terribly reliable. But
05.08.2019 8:40, Michael Paquier wrote:
> On Mon, Aug 05, 2019 at 06:44:46AM +0300, Alexander Lakhin wrote:
>> I believe that all the fixes in doc/ should be back-patched too. If it's
>> not too late, I can produce such patches for the nearest releases.
> I think that's unfortunately a bit too late
On Mon, Aug 05, 2019 at 09:15:02AM +0530, Jeevan Ladhe wrote:
> Please find attached patch with the changes to RETURN_ERROR and
> it's references in float.c
Thanks. Committed after applying some tweaks to it. I have noticed
that you forgot numeric_int4_opt_error() in the set.
--
Michael
signat
On 05/08/2019 07:23, Thomas Munro wrote:
On Mon, Aug 5, 2019 at 3:54 PM Amit Kapila wrote:
On Sun, Aug 4, 2019 at 2:46 PM Heikki Linnakangas wrote:
Could we leave out the UNDO and discard worker processes for now?
Execute all UNDO actions immediately at rollback, and after crash
recovery. Tha
On 8/4/19 4:13 AM, Tom Lane wrote:
Ian Barwick writes:
On 8/3/19 7:27 AM, Tom Lane wrote:
Tomas Vondra writes:
The main issue however is that no code was written yet.
Seems like it ought to be relatively simple ... but I didn't look.
The patch I originally sent does exactly this.
Ah,
On 8/4/19 1:59 AM, Tom Lane wrote:> Tomas Vondra
writes:
>> On Fri, Aug 02, 2019 at 06:08:02PM -0700, Andres Freund wrote:
>>> We're WAY WAY past feature freeze. This isn't the time to rewrite guc.c,
>>> guc-file.l to be suitable for running outside of a backend environment.
>
>> Right. And even
>
> Thanks. Committed after applying some tweaks to it. I have noticed
> that you forgot numeric_int4_opt_error() in the set.
Oops. Thanks for the commit, Michael.
Regards,
Jeevan Ladhe
62 matches
Mail list logo
