On Sun, Mar 15, 2020 at 04:05:37PM -0700, Jeff Davis wrote:
> > + if (from_tape)
> > + partition_mem += HASHAGG_READ_BUFFER_SIZE;
> > + partition_mem = npartitions * HASHAGG_WRITE_BUFFER_SIZE;
> >
> > => That looks wrong ; should say += ?
>
> Good catch! Fixed.
> +++ b/src/backend/
On 2020/03/18 22:37, Atsushi Torikoshi wrote:
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I meant the following part in the doc.
-
At startup, the standby begins by restoring all WAL available in the archive
lo
On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote:
> On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote:
> > Having now played with the patch, I'll suggest that 1000 is too high a
> > threshold. If autovacuum runs without FREEZE, I don't see why it couldn't
> > be
> > much lower (1
On Tue, 2020-03-17 at 18:02 -0700, Andres Freund wrote:
> I don't think a default scale factor of 0 is going to be ok. For
> large-ish tables this will basically cause permanent vacuums. And it'll
> sometimes trigger for tables that actually coped well so far. 10 million
> rows could be a few secon
On Thu, Mar 19, 2020 at 3:55 AM Chris Bandy wrote:
>
>
> Sorry for these troubles. Attached are patches created using `git
> format-patch -n -v6` on master at 487e9861d0.
>
No problem. I have extracted your code changes as a separate patch
(see attached) as I am not sure we want to add tests for
On Wed, 18 Mar 2020 at 04:24, Alvaro Herrera
wrote:
>
> Thanks Arseny and Masahiko, I pushed this patch just now. I changed
> some comments while at it, hopefully they are improvements.
>
> On 2020-Mar-09, Masahiko Sawada wrote:
>
> > ctx = CreateInitDecodingContext(plugin, NIL,
> > -
On Thu, Mar 19, 2020 at 08:20:51AM +0530, Amit Kapila wrote:
> On Tue, Mar 17, 2020 at 11:51 AM Amit Kapila wrote:
> > On Tue, Mar 17, 2020 at 9:52 AM Amit Kapila wrote:
> > >
> > > Another minor point, don't we need to remove the error stack by doing
> > > "error_context_stack = errcallback.prev
On Wed, 18 Mar 2020 at 13:57, Amit Kapila wrote:
>
> On Wed, Mar 18, 2020 at 9:01 AM Amit Kapila wrote:
> >
> > On Tue, Mar 17, 2020 at 7:39 PM Tom Lane wrote:
> > >
> > > Amit Kapila writes:
> > > > On Tue, Mar 17, 2020 at 3:28 PM Michael Paquier
> > > > wrote:
> > > >> Definitely an oversig
On Wed, Mar 18, 2020 at 04:35:43PM +0100, Julien Rouhaud wrote:
> On Wed, Mar 18, 2020 at 09:56:40AM +0100, Julien Rouhaud wrote:
> AFAICT it was only missing a call to index_update_collation_versions() in
> ReindexRelationConcurrently. I added regression tests to make sure that
> REINDEX, REINDEX
On 2020-Mar-19, Michael Paquier wrote:
> Do any of you have any arguments against the patch proposed upthread
> switching "float4" to "floating point" then? Better be sure..
None here.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DB
On Thu, Mar 19, 2020 at 11:45 AM Fujii Masao
wrote:
> On 2020/03/19 11:32, Amit Langote wrote:
> > On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
> > wrote:
> >> On 2020-Mar-19, Amit Langote wrote:
> >>
> >>> Magnus' idea of checking the values in pg_stat_get_progress_info() to
> >>> determine w
On Tue, Mar 17, 2020 at 11:51 AM Amit Kapila wrote:
>
> On Tue, Mar 17, 2020 at 9:52 AM Amit Kapila wrote:
> >
> >
> > Another minor point, don't we need to remove the error stack by doing
> > "error_context_stack = errcallback.previous;" in parallel_vacuum_main?
> >
>
> Few other comments:
> 1.
On 2020/03/19 11:32, Amit Langote wrote:
On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
wrote:
On 2020-Mar-19, Amit Langote wrote:
Magnus' idea of checking the values in pg_stat_get_progress_info() to
determine whether to return NULL seems fine to me.
So you think that the latest patch
On Wed, Mar 18, 2020 at 02:29:17PM -0300, Alvaro Herrera wrote:
> I don't think it will, directly; debian.codesearch.net says only patroni
> and slony1-2 contain the "parse_real", and both have their own
> implementations (patroni is Python anyway). I didn't find any
> relopt_real anywhere.
Relop
On 2020-Mar-19, Amit Langote wrote:
> On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
> wrote:
> > On 2020-Mar-19, Amit Langote wrote:
> >
> > > Magnus' idea of checking the values in pg_stat_get_progress_info() to
> > > determine whether to return NULL seems fine to me. We will need to
> > > up
On Fri, Mar 13, 2020 at 12:18 AM Jürgen Purtz wrote:
>
> The statement that names of schema objects are unique isn't *strictly* true,
> just *mostly* true. Take the case of a unique constraints.
>
> Concerning CONSTRAINTS you are right. Constraints seems to be an exception:
>
>- Their name be
On Thu, Mar 19, 2020 at 11:24 AM Alvaro Herrera
wrote:
> On 2020-Mar-19, Amit Langote wrote:
>
> > Magnus' idea of checking the values in pg_stat_get_progress_info() to
> > determine whether to return NULL seems fine to me. We will need to
> > update the documentation of st_progress_param, becaus
On Tue, Mar 17, 2020 at 11:39:11PM +0300, Sergei Kornilov wrote:
> We need this change to set is_temp_slot properly. PrimarySlotName
> GUC can usually be an empty string, so just "slotname != NULL" is
> not enough.
Yep, or a temporary slot would never be created even if there is no
slot defined, a
On 2020-Mar-19, Amit Langote wrote:
> Magnus' idea of checking the values in pg_stat_get_progress_info() to
> determine whether to return NULL seems fine to me. We will need to
> update the documentation of st_progress_param, because it currently
> says:
>
> * ...but the meaning of each el
Hello,
On Thu, Mar 19, 2020 at 1:47 AM Fujii Masao wrote:
> On 2020/03/19 1:22, Magnus Hagander wrote:
> > Would it perhaps be better to return NULL instead of 0 in the
> > statistics view if there is no data?
> >>>
> >>> Did you miss this comment, or not agree? :)
> >>
> >> Oh, I forgot
On Wed, Mar 18, 2020 at 03:33:40PM +0100, Julien Rouhaud wrote:
> While looking at RIC for the collation versioning issue Michael raised
> earlier,
> I found a thinko in a nearby comment, apparently introduced in the original
> REINDEX CONCURRENTLY patch (5dc92b8). Trivial patch attached.
Thanks
Here's a pretty-nearly-final version of the patch.
In 0001 below, I've left it throwing an error for the case of all
ANYCOMPATIBLE inputs being unknown, but the documentation fails to
acknowledge that. 0002 below is a delta patch that switches to the
other approach of resolving as TEXT. I'm pret
On Wed, Mar 18, 2020 at 09:29:55PM +0100, Peter Eisentraut wrote:
> OK, I have committed the regcollation patch, and some surrounding cleanup of
> the reg* types documentation.
Thanks, Peter.
--
Michael
signature.asc
Description: PGP signature
On Wed, Mar 18, 2020 at 04:35:57PM -0700, Jeff Davis wrote:
Committed.
\o/
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Committed.
There's some future work that would be nice (some of these are just
ideas and may not be worth it):
* Refactor MemoryContextMemAllocated() to be a part of
MemoryContextStats(), but allow it to avoid walking through the blocks
and freelists.
* Improve the choice of the initial number
On 2020-Mar-18, Jeff Davis wrote:
> Disk-based Hash Aggregation.
>
> While performing hash aggregation, track memory usage when adding new
> groups to a hash table. If the memory usage exceeds work_mem, enter
> "spill mode".
Kudos!!
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
On Tue, Feb 25, 2020 at 09:35:52AM +0100, Antonin Houska wrote:
> I've noticed that two variables in RelationCopyStorage() are defined in a
> scope higher than necessary. Please see the patch.
It seems cleaner to me to allocate the variables once before the loop
starts, rather than for each loop i
On Mon, 2020-03-16 at 11:45 -0700, Jeff Davis wrote:
> Attached is a patch that makes mem_allocated a method (rather than a
> field) of MemoryContext, and allows each memory context type to track
> the memory its own way. They all do the same thing as before
> (increment/decrement a field), but All
On 3/18/20 6:56 AM, Amit Kapila wrote:
> On Thu, Mar 12, 2020 at 7:46 PM Amit Kapila wrote:
>>
>> On Wed, Mar 11, 2020 at 8:51 PM Chris Bandy wrote:
>>>
>>> On 3/11/20 6:29 AM, Amit Kapila wrote:
I have tried with git am as well, but it failed. I am not sure what
is the reason. C
Thanks for the reviews; I have pushed it now.
(I made the doc edits you mentioned too.)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Mar 15, 2020 at 12:49:33PM +0100, Julien Rouhaud wrote:
> On Sun, Mar 15, 2020 at 06:18:31AM -0500, Justin Pryzby wrote:
> > See also:
> > https://commitfest.postgresql.org/27/2390/
> > https://www.postgresql.org/message-id/flat/caobau_yy5bt0vtpz2_lum6cucgeqmynoj8-rgto+c2+w3de...@mail.gmail
On Wed, Mar 18, 2020 at 09:29:55PM +0100, Peter Eisentraut wrote:
> On 2020-03-17 18:43, Julien Rouhaud wrote:
> > On Tue, Mar 17, 2020 at 05:31:47PM +0100, Christoph Berg wrote:
> > > Re: Peter Eisentraut
> > > 2020-03-17
> > > > Did we discuss the regcollation type? In the current patch set, it
On 2020-Mar-17, Ashutosh Bapat wrote:
> On Fri, 13 Mar 2020 at 21:55, Alvaro Herrera
> wrote:
> > Note that in this implementation I no longer know which column is the
> > problematic one, but I suppose users have clue enough. Wording
> > suggestions welcome.
>
> When we have expression as a p
On 2020-03-17 18:43, Julien Rouhaud wrote:
On Tue, Mar 17, 2020 at 05:31:47PM +0100, Christoph Berg wrote:
Re: Peter Eisentraut
2020-03-17
Did we discuss the regcollation type? In the current patch set, it's only
used in two places in a new regression test, where it can easily be replaced
by
Hi,
On 2020-03-18 16:54:19 -0300, Alvaro Herrera wrote:
> On 2020-Mar-18, Andres Freund wrote:
> > On 2020-03-18 16:46:23 +0100, Peter Eisentraut wrote:
> > > When SaveSlotToPath() is called with elevel=LOG, the early exits don't
> > > release the slot's io_in_progress_lock. Fix attached.
> >
>
On Thu, Mar 19, 2020 at 4:46 AM Peter Eisentraut
wrote:
> [patch]
+ * releaseing even in that case.
Typo.
On Tue, 2020-03-17 at 17:26 -0700, Andres Freund wrote:
> On 2020-03-17 01:14:02 +0100, Laurenz Albe wrote:
> > lazy_check_needs_freeze() is only called for an aggressive vacuum, which
> > this isn't.
>
> Hm? I mean some of these will be aggressive vacuums, because it's older
> than vacuum_freeze_
On 2020-Mar-18, Andres Freund wrote:
> Hi,
>
> On 2020-03-18 16:46:23 +0100, Peter Eisentraut wrote:
> > When SaveSlotToPath() is called with elevel=LOG, the early exits don't
> > release the slot's io_in_progress_lock. Fix attached.
>
> I'm a bit confused as to why we we ever call it with elev
On 2020-Mar-18, Alvaro Herrera wrote:
> On 2020-Mar-18, Alvaro Herrera wrote:
>
> > There were conflicts again, so I rebased once more. Didn't do anything
> > else.
>
> This compiles fine, but tests seem to hang forever with no output.
well, not "forever", but:
$ make check PROVE_TESTS=t/019_
On Sun, Mar 15, 2020 at 12:37:37PM +, Dean Rasheed wrote:
On Sun, 15 Mar 2020 at 00:08, Tomas Vondra wrote:
On Sat, Mar 14, 2020 at 05:56:10PM +0100, Tomas Vondra wrote:
>
>Attached is a patch series rebased on top of the current master, after
>committing the ScalarArrayOpExpr enhancements
On Wed, Mar 18, 2020 at 08:48:17PM +0300, Kirill Bychik wrote:
> > I'm attaching a v5 with fp records only for temp tables, so there's no risk
> > of
> > instability. As I previously said I'm fine with your two patches, so unless
> > you have objections on the fpi test for temp tables or the docu
Hi,
On 2020-03-18 16:46:23 +0100, Peter Eisentraut wrote:
> When SaveSlotToPath() is called with elevel=LOG, the early exits don't
> release the slot's io_in_progress_lock. Fix attached.
I'm a bit confused as to why we we ever call it with elevel = LOG
(i.e. why we have the elevel parameter at a
On 2020-Mar-18, Alvaro Herrera wrote:
> There were conflicts again, so I rebased once more. Didn't do anything
> else.
This compiles fine, but tests seem to hang forever with no output.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote D
There were conflicts again, so I rebased once more. Didn't do anything
else.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From e2f5cedfc35652f198f9ca3bca9a45572f8845fb Mon Sep 17 00:00:00 2001
From: Amit Khan
On Wednesday, March 18, 2020, Tom Lane wrote:
> Bruce Momjian writes:
> > OK, updated patch attached.
>
> LGTM, thanks
>
+1
David J.
> > There is a higher-level Instrumentation API that can be used with
> > INSTRUMENT_WAL flag to collect the wal usage information. I believe
> > the instrumentation is widely used in the executor code, so it should
> > not be a problem to colelct instrumentation information on autovacuum
> > worke
On Wed, Mar 18, 2020 at 1:08 PM Andres Freund wrote:
>
> Hi,
>
> On 2020-03-17 21:58:53 -0400, James Coleman wrote:
> > On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> > >
> > > Hi,
> > >
> > > On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > > > I think Andres was thinking this wou
On Tue, Mar 17, 2020 at 11:37 PM Justin Pryzby wrote:
>
> On Tue, Mar 17, 2020 at 09:58:53PM -0400, James Coleman wrote:
> > On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> > >
> > > On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > > > I think Andres was thinking this would maybe be
On 2020-Mar-18, Tom Lane wrote:
> Alvaro Herrera writes:
> > Ah, I hadn't checked -- I was taking the function and struct names at
> > face value, but it turns out that they're lies as well -- parse_real,
> > relopt_real all parsing/storing doubles *is* confusing.
>
> Yeah, that's certainly true
st 18. 3. 2020 v 18:09 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
> >> No, because if you've got that alongside foo2(anycompatible,
> >> anycompatible) then your queries will fail due to both functions
> >> matching anything that's
On Wed, Mar 18, 2020 at 09:02:58AM +0300, Kirill Bychik wrote:
>
> There is a higher-level Instrumentation API that can be used with
> INSTRUMENT_WAL flag to collect the wal usage information. I believe
> the instrumentation is widely used in the executor code, so it should
> not be a problem to co
Alvaro Herrera writes:
> Ah, I hadn't checked -- I was taking the function and struct names at
> face value, but it turns out that they're lies as well -- parse_real,
> relopt_real all parsing/storing doubles *is* confusing.
Yeah, that's certainly true. I wonder if we could rename them
without c
On 2020-Mar-18, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Mar-18, Michael Paquier wrote:
> >> On Mon, Mar 16, 2020 at 11:07:37AM +0900, Atsushi Torikoshi wrote:
> In this case, the parsing uses parse_real(), which is exactly the same
> code path as what real GUCs use.
>
> >
Hi,
On 2020-03-17 21:58:53 -0400, James Coleman wrote:
> On Tue, Mar 17, 2020 at 9:03 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2020-03-17 20:42:07 +0100, Laurenz Albe wrote:
> > > > I think Andres was thinking this would maybe be an optimization
> > > > independent of
> > > > is_insert_onl
Pavel Stehule writes:
> st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
>> No, because if you've got that alongside foo2(anycompatible,
>> anycompatible) then your queries will fail due to both functions
>> matching anything that's promotable to text.
> It is working for anyelement
[ pokes a
st 18. 3. 2020 v 17:54 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
> >> However, it seems to me that this is inconsistent with the definition,
> >> namely that we resolve the common type the same way select_common_type()
> >> does,
Alvaro Herrera writes:
> On 2020-Mar-18, Michael Paquier wrote:
>> On Mon, Mar 16, 2020 at 11:07:37AM +0900, Atsushi Torikoshi wrote:
In this case, the parsing uses parse_real(), which is exactly the same
code path as what real GUCs use.
> Hmm. So unadorned 'floating point' seems to re
On Wed, Mar 18, 2020 at 12:54 PM Alvaro Herrera
wrote:
>
> On 2020-Mar-18, Mike Palmiotto wrote:
>
> > On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto
> > wrote:
> > >
> > > On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby
> > > wrote:
> > > > Also, I saw this was failing tests both before and af
Pavel Stehule writes:
> st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
>> However, it seems to me that this is inconsistent with the definition,
>> namely that we resolve the common type the same way select_common_type()
>> does, because select_common_type() will choose TEXT when given all-un
On 2020-Mar-18, Mike Palmiotto wrote:
> On Wed, Mar 18, 2020 at 11:26 AM Mike Palmiotto
> wrote:
> >
> > On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby wrote:
> > > Also, I saw this was failing tests both before and after my rebase.
> > >
> > > http://cfbot.cputube.org/
> > > https://ci.appveyor
On 2020-Mar-18, Michael Paquier wrote:
> On Mon, Mar 16, 2020 at 11:07:37AM +0900, Atsushi Torikoshi wrote:
> > As far as I read the reloptions.c, autovacuum_vacuum_cost_delay,
> > autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor
> > are the members of relopt_real, so their type
Bruce Momjian writes:
> OK, updated patch attached.
LGTM, thanks.
regards, tom lane
On 2020/03/19 1:22, Magnus Hagander wrote:
On Wed, Mar 18, 2020 at 5:14 PM Fujii Masao wrote:
On 2020/03/19 0:37, Magnus Hagander wrote:
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
st 18. 3. 2020 v 17:14 odesílatel Tom Lane napsal:
> So ... there is a definitional question here that doesn't seem to have
> been mentioned anywhere in the thread. For the traditional polymorphic
> types, we insist that at least one non-unknown input be supplied, thus
> you get
>
> regression=#
Regarding this patch:
+* the ANALYZE message as it resets the partition's changes_since_analze
=> analyze
+* If the relation is a partitioned table, we must add up children's
childrens'
The approach in general:
I see an issue for timeseries data, where only the most recent parti
On Tue, Mar 17, 2020 at 10:58:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I have implemented the ideas above in the attached patch. I have
> > synchronized the syntax to match SELECT, and synchronized the paragraphs
> > describing the item.
>
> I think that the DELETE synopsis should
On Wed, Mar 18, 2020 at 5:14 PM Fujii Masao wrote:
>
>
>
> On 2020/03/19 0:37, Magnus Hagander wrote:
> > On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/11 3:39, Magnus Hagander wrote:
> >>> On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao
> >>> wrote:
>
So ... there is a definitional question here that doesn't seem to have
been mentioned anywhere in the thread. For the traditional polymorphic
types, we insist that at least one non-unknown input be supplied, thus
you get
regression=# create function foo(anyelement, anyelement) returns bool
regres
On 2020/03/19 0:37, Magnus Hagander wrote:
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
On 2020/03/11 3:39, Magnus Hagander wrote:
On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao wrote:
On 2020/03/10 22:43, Amit Langote wrote:
On Tue, Mar 10, 2020 at 6:09 PM Fujii Masao wrote:
S
On Tue, Mar 17, 2020 at 04:37:06PM +0100, Tomas Vondra wrote:
On Tue, Mar 17, 2020 at 12:42:52PM +, Dean Rasheed wrote:
On Sat, 14 Mar 2020 at 18:45, Tomas Vondra wrote:
I realized there's one more thing that probably needs discussing.
Essentially, these two clause types are the same:
On Wed, Mar 18, 2020 at 01:32:19PM +, Shinoda, Noriyoshi (PN Japan
A&PS Delivery) wrote:
Hi,
Thanks for the report. Yes, this is clearly an omission. I think it
would be better to use wording >similar to attstattarget, per the
attached patch. That is, without reference to ALTER STATISTICS a
When SaveSlotToPath() is called with elevel=LOG, the early exits don't
release the slot's io_in_progress_lock. Fix attached.
This could result in a walsender being stuck on the lock forever. A
possible way to get into this situation is if the offending code paths
are triggered in a low disk
On Wed, Mar 11, 2020 at 5:53 AM Fujii Masao wrote:
>
>
>
> On 2020/03/11 3:39, Magnus Hagander wrote:
> > On Tue, Mar 10, 2020 at 6:19 PM Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/03/10 22:43, Amit Langote wrote:
> >>> On Tue, Mar 10, 2020 at 6:09 PM Fujii Masao
> >>> wrote:
> > S
On Wed, Mar 18, 2020 at 10:17 AM Justin Pryzby wrote:
>
> On Wed, Mar 18, 2020 at 09:22:58AM -0400, Mike Palmiotto wrote:
> > On Tue, Mar 17, 2020 at 9:04 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2020-Mar-17, Justin Pryzby wrote:
> > >
> > > > +static PgSubprocess process_types[] = {
> > > >
I was expecting that documentation somewhere covered the fact that BR
triggers are not supported on a partitioned table. And this patch
would remove/improve that portion of the code. But I don't see any
documentation changes in this patch.
On Tue, Mar 17, 2020 at 10:11 PM Ashutosh Bapat
wrote:
>
> On Mar 17, 2020, at 9:33 PM, Michael Paquier wrote:
>
> On Tue, Mar 17, 2020 at 12:39:35PM -0700, Mark Dilger wrote:
>> I agree that this does not need to be back-patched. I was debating
>> whether it constitutes a bug for the purpose of putting the fix into
>> v13 vs. punting the patch forw
Hi,
While looking at RIC for the collation versioning issue Michael raised earlier,
I found a thinko in a nearby comment, apparently introduced in the original
REINDEX CONCURRENTLY patch (5dc92b8). Trivial patch attached.
>From 161ea86380a50caeee8de81fe82d6eb106a2fd39 Mon Sep 17 00:00:00 2001
Fro
> Hm. There was never really any expectation that support functions
> would be attached to PL functions --- since you have to write the
> former in C, it seems a little odd for the supported function not
> to also be C. Perhaps more to the point though, what simplification
> knowledge is this sup
On Wed, Mar 18, 2020 at 8:16 PM Peter Eisentraut
wrote:
> On 2020-03-18 04:06, Amit Langote wrote:
> > + if (isnull || !remote_is_publishable)
> > + ereport(ERROR,
> > + (errmsg("table \"%s.%s\" on the publisher is not
> > publishable",
> > + nspname, r
On Wed, Mar 18, 2020 at 09:22:58AM -0400, Mike Palmiotto wrote:
> On Tue, Mar 17, 2020 at 9:04 PM Alvaro Herrera
> wrote:
> >
> > On 2020-Mar-17, Justin Pryzby wrote:
> >
> > > +static PgSubprocess process_types[] = {
> > > + {
> > > + .desc = "checker",
> > > + .entry
Ronan Dunklau writes:
> What I want to do is to evaluate whether id = t1_id AND somecolumn is NOT
> NULL at planification time, and replace the function by another one if this
> can be pruned altogether.
Hm. There was never really any expectation that support functions
would be attached to PL fu
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao
wrote:
>
> I meant the following part in the doc.
>
> -
> At startup, the standby begins by restoring all WAL available in the
> archive
> location, calling restore_command. Once it reaches the end of WAL available
> there and restor
Hi,
>Thanks for the report. Yes, this is clearly an omission. I think it would be
>better to use wording >similar to attstattarget, per the attached patch. That
>is, without reference to ALTER STATISTICS and >better explaination of what
>positive/negative values do. Do you agree?
Thank you fo
On Tue, Mar 17, 2020 at 9:04 PM Alvaro Herrera wrote:
>
> On 2020-Mar-17, Justin Pryzby wrote:
>
> > +static PgSubprocess process_types[] = {
> > + {
> > + .desc = "checker",
> > + .entrypoint = CheckerModeMain
> > + },
> > + {
> > + .desc = "bootstr
Hi,
After a thorough Java-Swig-libpq test, I can confirm that INSERT/SELECT
is working properly:
1. server_encoding: SQL_ASCII
2. client_encoding: SQL_ASCII
3. INSERT / SELECT java string with x00
libpq, psql - everything is OK !
Vladimir Kokovic, DP senior (69)
Serbia, Belgrade, March 18,
Hi,
On Wed, Mar 18, 2020 at 04:28:34AM +, Shinoda, Noriyoshi (PN Japan A&PS
Delivery) wrote:
Hello,
I found a missing column description in the pg_statistic_ext catalog document
for this new feature.
The attached patch adds a description of the 'stxstattarget' column to
pg_statistic_ext
On Thu, Mar 12, 2020 at 7:46 PM Amit Kapila wrote:
>
> On Wed, Mar 11, 2020 at 8:51 PM Chris Bandy wrote:
> >
> > On 3/11/20 6:29 AM, Amit Kapila wrote:
> > >
> > > I have tried with git am as well, but it failed. I am not sure what
> > > is the reason. Can you please once check at your end?
>
On 2020-03-18 04:06, Amit Langote wrote:
+ if (isnull || !remote_is_publishable)
+ ereport(ERROR,
+ (errmsg("table \"%s.%s\" on the publisher is not publishable",
+ nspname, relname)));
Maybe add a one-line comment above this to say it's an "not suppos
On Wed, Mar 18, 2020 at 07:06:19AM +0100, Julien Rouhaud wrote:
> On Wed, Mar 18, 2020 at 01:20:47PM +0900, Michael Paquier wrote:
> > On Mon, Mar 16, 2020 at 09:21:22AM +0100, Julien Rouhaud wrote:
> > > On Mon, Mar 16, 2020 at 12:29:28PM +0900, Michael Paquier wrote:
> > >> With a large amount of
On 2020/03/18 17:56, Atsushi Torikoshi wrote:
On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
> > Waiting when WAL data is not available from any kind of sources
> > (local, archive or stream) before trying again to retrieve WAL
dat
Hello,
I've been trying to play with support functions for a use-case of ours, and
found some behaviors I don't know are expected or not.
The use case: we have some complicated queries, where whole-branches of the
execution tree could be cut if some things were evaluated at planning time.
Take th
On 2020/03/17 14:52, Atsushi Torikoshi wrote:
On Mon, Mar 16, 2020 at 11:32 PM Alvaro Herrera mailto:alvhe...@2ndquadrant.com>> wrote:
> Should I also change it to "enum"?
Yeah, these were strings until recently (commit 773df883e8f7 Sept 2019).
Thanks!
Attached a patch for manua
On Wed, Mar 18, 2020 at 04:55:25PM +0900, Michael Paquier wrote:
> On Tue, Mar 17, 2020 at 11:42:34AM +0100, Julien Rouhaud wrote:
> > On Tue, Mar 17, 2020 at 08:19:30AM +0100, Julien Rouhaud wrote:
>
> It would be good to be careful about the indentation. Certain parts
> of 0003 don't respect the
On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao
wrote:
> > >Waiting when WAL data is not available from any kind of sources
> > >(local, archive or stream) before trying again to retrieve WAL
> data,
> >
> > I think 'local' means pg_wal here, but the comment on
> > WaitForWALToBecomeAvaila
On Tue, Mar 17, 2020 at 11:42:34AM +0100, Julien Rouhaud wrote:
> On Tue, Mar 17, 2020 at 08:19:30AM +0100, Julien Rouhaud wrote:
>> On Tue, Mar 17, 2020 at 03:37:49PM +0900, Michael Paquier wrote:
>>> It seems to me that you could add an extra test with a catalog that
>>> does not exist, making su
On Wed, Mar 18, 2020 at 12:06 PM Amit Langote wrote:
> Hi Peter,
>
> On Mon, Mar 16, 2020 at 9:49 PM Peter Eisentraut
> wrote:
> >
> > I was trying to extract some preparatory work from the remaining patches
> > and came up with the attached. This is part of your patch 0003, but
> > also relevan
96 matches
Mail list logo
