st 1. 7. 2020 v 22:54 odesílatel Vik Fearing
napsal:
> On 7/1/20 10:34 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> >>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> >>> napsal:
> >>>
> On 7/1/20
> >
> > one comment: instead of having block variables onexit, in the while
> > loops in shmem_exit, can we have a single local variable defined at
> > the start of the shmem_exit function
> > and reuse them in the while loops? same comment for onexit block
> > variable in proc_exit_prepare()
On Thu, Mar 19, 2020 at 10:30:11PM +0900, Michael Paquier wrote:
> The new FORMAT_TYPE_* flag still makes sense to me while reading this
> code once again, as well as the extensibility of the new APIs for
> operators and procedures. One doubt I still have is if we should
> really change the
On Tue, Jun 30, 2020 at 10:11:04AM +0200, Peter Eisentraut wrote:
> On 2020-05-04 07:50, Michael Paquier wrote:
>> Yeah. The years have visibly proved that the README had updates when
>> it came to the general descriptions of the libpqwalreceiver interface,
>> but that we had better consolidate
cfbot is complaining as this is no longer applicable. Rebased.
In v14, some reference to XLogReaderState parameter to read_pages
functions are accidentally replaced by the reference to the global
variable xlogreader. Fixed it, too.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Sat, Jun 13, 2020 at 8:36 AM David Rowley wrote:
> I ended up chickening out of doing the larger allocation
> unconditionally. Instead, I pushed the original idea of doing the
> palloc/memcpy of the length returned by pg_lltoa. That gets us most
> of the gains without the change in memory
On Tue, Jun 30, 2020 at 9:30 AM Amit Kapila wrote:
>
> >
> > If I am not missing anything then that change was in
> > lazy_cleanup_index and after this patch, it won't be required because
> > we are using a different variable name.
> >
> > I have combined both the patches now.
> >
>
> I am
On Tue, 30 Jun 2020 at 12:58, Amit Kapila wrote:
>
> On Tue, Jun 30, 2020 at 6:38 AM Masahiko Sawada
> wrote:
> >
> > On Mon, 29 Jun 2020 at 20:37, Amit Kapila wrote:
> > >
> > > On Mon, Jun 29, 2020 at 10:26 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > I agree that it would not be a common
Horiguchi-san,
On Thu, Jul 2, 2020 at 11:14 AM Kyotaro Horiguchi
wrote:
> As the result of a discussion with Fujita-san off-list, I'm going to
> hold off development until he decides whether mine or Thomas' is
> better.
I'd like to join the party, but IIUC, we don't yet reach a consensus
on
On Sat, Jun 6, 2020 at 12:36 PM Stephen Frost wrote:
> * Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> > I wonder if we can collect some stats to measure how effective the
> > prefetching actually is. Ultimately we want something like cache hit
> > ratio, but we're only preloading into
On Wed, Jul 1, 2020 at 11:40 PM Tom Lane wrote:
> Etsuro Fujita writes:
> > On Wed, Jul 1, 2020 at 7:21 AM Tom Lane wrote:
> >> +baserel->tuples = Max(baserel->tuples, baserel->rows);
>
> > for consistency, this should be
> > baserel->tuples = clamp_row_est(baserel->rows / sel);
> > where
Hello.
As the result of a discussion with Fujita-san off-list, I'm going to
hold off development until he decides whether mine or Thomas' is
better.
However, I fixed two misbehaviors and rebased.
A. It runs ordered Append asynchronously, but that leads to a bogus
result. I taught
On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> On Tue, 30 Jun 2020 at 02:17, Madan Kumar wrote:
>> It may be better to have one single function returning both
>> timestamp and origin for a given transaction ID.
>
> No need to change existing APIs.
Adding a new function able to
On Tue, Jun 30, 2020 at 02:32:47PM -0400, Alvaro Herrera wrote:
> On 2020-Jun-30, Michael Paquier wrote:
>> Another question that has popped up when doing this review is what
>> would be the use-case of adding this information at SQL level knowing
>> that logical replication exists since 10?
>
>
On 2020-Jul-02, mich...@paquier.xyz wrote:
> pg_replication_slots would make sense to me than a stat view for a
> distance column. Now, I have to admit that I am worried when seeing
> design discussions on this thread for 13 after beta2 has been shipped,
We already had this discussion and one
On Wed, Jul 01, 2020 at 11:14:21AM -0400, Alvaro Herrera wrote:
> On 2020-Jul-01, Amit Kapila wrote:
>> Okay, but do we think it is better to display this in
>> pg_replication_slots or some new view like pg_stat_*_slots as being
>> discussed in [1]? It should not happen that we later decide to
Thomas Munro writes:
> On Wed, Jul 1, 2020 at 5:58 AM Robert Haas wrote:
>> With what other implementations is it compatible?
> Judging by the Wikipedia article[1], it sounds like at least DB2 and
> MySQL/MariaDB are purposely striving for conformance.
> [1]
On Wed, 1 Jul 2020 15:58:57 -0400
Robert Haas wrote:
> On Wed, Jul 1, 2020 at 3:50 PM Magnus Hagander wrote:
> > As far as I've seen, the one thing that people have problems with in the
> > exclusive mode backups are precisely the fact that they have to keep a
> > persistent conneciton open,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I disagree with this and instead lean more towards the side that Robert
> > and Jeff were taking in that this would be a useful extension and
> > something we should consider including in core. I disagree with Tom and
On Wed, Jul 1, 2020 at 5:58 AM Robert Haas wrote:
> On Tue, Jun 30, 2020 at 1:49 PM Peter Eisentraut
> wrote:
> > This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
> > statements for language SQL with a function body that conforms to the
> > SQL standard and is portable to other
Stephen Frost writes:
> I disagree with this and instead lean more towards the side that Robert
> and Jeff were taking in that this would be a useful extension and
> something we should consider including in core. I disagree with Tom and
> Noah, specifically because, if we add this capability
Joe Conway writes:
> The only downside is that the max filesize is reduced to (MaxAllocSize -
> MIN_READ_SIZE - 1) compared to MaxAllocSize with the old method.
Hm, I was expecting that the last successful iteration of
enlargeStringInfo would increase the buffer size to MaxAllocSize,
so that
Amit Khandekar writes:
> There are a couple of function call overheads I observed in pl/pgsql
> code : exec_stmt() and exec_cast_value(). Removing these overheads
> resulted in some performance gains.
I took a look at the 0001/0002 patches (not 0003 as yet). I do not
like 0001 too much. The
On Wed, Jul 1, 2020 at 11:08 PM David Steele wrote:
> On 7/1/20 4:39 PM, Magnus Hagander wrote:
> > On Wed, Jul 1, 2020 at 10:28 PM David Steele > Here's a thought. What if we just stored the oldest starting LSN and
> a
> > count of how many backups have been requested. When the backup
On 7/1/20 5:17 PM, Joe Conway wrote:
> On 7/1/20 4:12 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> I did some performance testing of the worst case/largest possible file and
>>> found
>>> that skipping the stat and bulk read does cause a significant regression.
>>
>> Yeah, I was wondering a
On Wed, Jul 1, 2020 at 05:20:16PM -0400, David Steele wrote:
> On 7/1/20 4:32 PM, Bruce Momjian wrote:
> > On Wed, Jul 1, 2020 at 04:27:58PM -0400, David Steele wrote:
> > > On 7/1/20 3:58 PM, Robert Haas wrote:
> > > > If we could jigger things so that you don't need to stop the backup at
> > >
On Thu, Jun 11, 2020 at 09:36:18AM +0200, Pavel Stehule wrote:
> st 10. 6. 2020 v 0:30 odesílatel Justin Pryzby napsal:
> > > + /* ignore empty rows */
> > > + if (*line != '\0')
> >
> > Maybe: if line=='\0':
On 7/1/20 4:32 PM, Bruce Momjian wrote:
On Wed, Jul 1, 2020 at 04:27:58PM -0400, David Steele wrote:
On 7/1/20 3:58 PM, Robert Haas wrote:
If we could jigger things so that you don't need to stop the backup at
all, you only start it, and whether you ever finish copying everything
is something
On 7/1/20 4:12 PM, Tom Lane wrote:
> Joe Conway writes:
>> I did some performance testing of the worst case/largest possible file and
>> found
>> that skipping the stat and bulk read does cause a significant regression.
>
> Yeah, I was wondering a little bit if that'd be an issue.
>
>> In the
On 7/1/20 4:39 PM, Magnus Hagander wrote:
On Wed, Jul 1, 2020 at 10:28 PM David Steele Here's a thought. What if we just stored the oldest starting LSN and a
count of how many backups have been requested. When the backup ends it
checks that backup count is > 0 and starting LSN is <=
st 1. 7. 2020 v 22:54 odesílatel Vik Fearing
napsal:
> On 7/1/20 10:34 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> >>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> >>> napsal:
> >>>
> On 7/1/20
st 1. 7. 2020 v 22:41 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I propose new psql environment variable PSQL_WATCH_PAGER. When this
> > variable is not empty, then \watch command starts specified pager, and
> > redirect output to related pipe. When pipe is closed - by pager, then
Greetings,
* Michael Banck (michael.ba...@credativ.de) wrote:
> On Wed, Jul 01, 2020 at 12:12:14AM -0400, Stephen Frost wrote:
> > Specifically, if you take a backup off a primary and, while that backup
> > is going on, some replica is promoted and drops a .history file into the
> > WAL repo,
On 7/1/20 10:34 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 9:32 PM, Pavel Stehule wrote:
>>> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
>>> napsal:
>>>
On 7/1/20 3:36 PM, Robert Haas wrote:
> I actually don't have a very clear
Sandro Mani writes:
> The following patch, which we added to build mingw-postgresql on Fedora,
> adds some missing libraries to Libs.private of libpq.pc, discovered when
> attempting to statically link with libpq:
TBH, I think we should just reject this patch. We do not encourage or
support
Hi,
On Wed, Jul 01, 2020 at 12:12:14AM -0400, Stephen Frost wrote:
> Specifically, if you take a backup off a primary and, while that backup
> is going on, some replica is promoted and drops a .history file into the
> WAL repo, that backup is no longer able to be restored with the new
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 4:29 PM Bruce Momjian wrote:
> > Agreed. I don't think three modes would help anyone.
>
> Well, I think that if and when we remove the existing exclusive mode,
> we're going to break a bunch of people's backup
On Wed, Jul 1, 2020 at 04:36:03PM -0400, Robert Haas wrote:
> On Wed, Jul 1, 2020 at 4:29 PM Bruce Momjian wrote:
> > Agreed. I don't think three modes would help anyone.
>
> Well, I think that if and when we remove the existing exclusive mode,
> we're going to break a bunch of people's backup
Pavel Stehule writes:
> I propose new psql environment variable PSQL_WATCH_PAGER. When this
> variable is not empty, then \watch command starts specified pager, and
> redirect output to related pipe. When pipe is closed - by pager, then
> \watch cycle is leaved.
I dunno, this just seems really
On Wed, Jul 1, 2020 at 10:28 PM David Steele wrote:
> On 7/1/20 3:58 PM, Robert Haas wrote:
> > On Wed, Jul 1, 2020 at 3:50 PM Magnus Hagander
> wrote:
> >> As far as I've seen, the one thing that people have problems with in
> the exclusive mode backups are precisely the fact that they have to
On Wed, Jul 1, 2020 at 4:29 PM Bruce Momjian wrote:
> Agreed. I don't think three modes would help anyone.
Well, I think that if and when we remove the existing exclusive mode,
we're going to break a bunch of people's backup scripts. I think it's
appropriate to do that eventually, but I'm not
On 7/1/20 4:27 PM, David Steele wrote:
Here's a thought. What if we just stored the oldest starting LSN and a
count of how many backups have been requested. When the backup ends it
checks that backup count is > 0 and starting LSN is <= its starting LSN.
If not, it throws an error. When
On Wed, Jul 1, 2020 at 04:25:35PM -0400, Alvaro Herrera wrote:
> On 2020-Jul-01, Bruce Momjian wrote:
>
> > We have the following wal*size GUC settings:
> >
> > SELECT name FROM pg_settings WHERE name LIKE '%wal%size%';
> > name
> >
> >
st 1. 7. 2020 v 22:31 odesílatel Vik Fearing
napsal:
> On 7/1/20 9:32 PM, Pavel Stehule wrote:
> > st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> > napsal:
> >
> >> On 7/1/20 3:36 PM, Robert Haas wrote:
> >>> I actually don't have a very clear idea of what the standard has to
> >>> say about
On Wed, Jul 1, 2020 at 4:27 PM David Steele wrote:
> Well, the only thing pg_stop_backup() *really* needs to know is the
> starting WAL position. pg_start_backup() gets that info so if it passes
> it back to pg_stop_backup() that could be enough. Or as was proposed
> above, it just passes the
Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 5/22/20 1:53 AM, Noah Misch wrote:
> > On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote:
> >> On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote:
> >>> There surely are use-cases for true rational arithmetic, but I'm
On Wed, Jul 1, 2020 at 04:27:58PM -0400, David Steele wrote:
> On 7/1/20 3:58 PM, Robert Haas wrote:
> > If we could jigger things so that you don't need to stop the backup at
> > all, you only start it, and whether you ever finish copying everything
> > is something about which the system need
On 7/1/20 9:32 PM, Pavel Stehule wrote:
> st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
> napsal:
>
>> On 7/1/20 3:36 PM, Robert Haas wrote:
>>> I actually don't have a very clear idea of what the standard has to
>>> say about SQL-language functions. Does it just say it's a list of
>>>
On Wed, Jul 1, 2020 at 10:24:15PM +0200, Magnus Hagander wrote:
> On Wed, Jul 1, 2020 at 9:59 PM Robert Haas wrote:
> Yeah, I guess that's a pretty fair point. I have to confess to having
> somewhat limited enthusiasm for adding a third mode here, but it might
> be worth it.
> The
On 7/1/20 3:58 PM, Robert Haas wrote:
On Wed, Jul 1, 2020 at 3:50 PM Magnus Hagander wrote:
As far as I've seen, the one thing that people have problems with in the
exclusive mode backups are precisely the fact that they have to keep a
persistent conneciton open, and thus it cannot work
st 1. 7. 2020 v 20:06 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > Last week I played with dbms_sql extension and some patterns of usage
> > cursor in PL/SQL and PL/pgSQL. I found fact, so iteration over cursor
> (FOR
> > statement) doesn't support unbound cursors. I think so this
On 2020-Jul-01, Bruce Momjian wrote:
> We have the following wal*size GUC settings:
>
> SELECT name FROM pg_settings WHERE name LIKE '%wal%size%';
> name
>
>max_slot_wal_keep_size
>max_wal_size
>min_wal_size
>
On Wed, Jul 1, 2020 at 9:59 PM Robert Haas wrote:
> On Wed, Jul 1, 2020 at 3:50 PM Magnus Hagander
> wrote:
> > As far as I've seen, the one thing that people have problems with in the
> exclusive mode backups are precisely the fact that they have to keep a
> persistent conneciton open, and
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 4:02 PM Stephen Frost wrote:
> > There's two solutions, really- first would be, as you suggest, configure
> > PG to stay on the timeline that the backup was taken on, but I suspect
> > that's often *not* what the
Joe Conway writes:
> I did some performance testing of the worst case/largest possible file and
> found
> that skipping the stat and bulk read does cause a significant regression.
Yeah, I was wondering a little bit if that'd be an issue.
> In the attached patch I was able to get most of the
On 5/22/20 1:53 AM, Noah Misch wrote:
> On Thu, May 21, 2020 at 01:40:10PM -0400, Robert Haas wrote:
>> On Mon, May 18, 2020 at 6:15 PM Tom Lane wrote:
>>> There surely are use-cases for true rational arithmetic, but I'm
>>> dubious that it belongs in core Postgres. I don't think that enough
On Wed, Jul 1, 2020 at 4:02 PM Stephen Frost wrote:
> There's two solutions, really- first would be, as you suggest, configure
> PG to stay on the timeline that the backup was taken on, but I suspect
> that's often *not* what the user actually wants- what they really want
> is to restore an
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 12:12 AM Stephen Frost wrote:
> > Among the changes made to PG's recovery in v12 was to set
> > recovery_target_timeline to be 'latest' by default. That's handy when
> > you're flipping back and forth between
On Wed, Jul 1, 2020 at 3:50 PM Magnus Hagander wrote:
> As far as I've seen, the one thing that people have problems with in the
> exclusive mode backups are precisely the fact that they have to keep a
> persistent conneciton open, and thus it cannot work together with backup
> software that
On Wed, Jul 1, 2020 at 12:12 AM Stephen Frost wrote:
> Among the changes made to PG's recovery in v12 was to set
> recovery_target_timeline to be 'latest' by default. That's handy when
> you're flipping back and forth between replicas and want to have
> everyone follow that game, but it's made
On Wed, Jul 1, 2020 at 9:43 PM Robert Haas wrote:
> On Wed, Jul 1, 2020 at 11:48 AM Magnus Hagander
> wrote:
> > We don't even need to make it an exclusive mode -- we can allow
> *nonexclusive* backups but remove the requirement to run start and stop
> backup in the same connection, which I
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 11:48 AM Magnus Hagander wrote:
> > We don't even need to make it an exclusive mode -- we can allow
> > *nonexclusive* backups but remove the requirement to run start and stop
> > backup in the same connection,
On Wed, Jul 1, 2020 at 01:23:21PM -0400, Stephen Frost wrote:
> > Or, how about we require them to provide the backup label contents in its
> > entirety? Which I believe does contain that WAL portion? The downside of
> > that is that it would be multiline which might screw with shellscripts.
>
On Wed, Jul 1, 2020 at 01:18:06PM -0400, David Steele wrote:
> On 7/1/20 10:54 AM, Alvaro Herrera wrote:
> > On 2020-Jul-01, Fujii Masao wrote:
> >
> > > On 2020/07/01 12:26, Alvaro Herrera wrote:
> > > > On 2020-Jun-30, Fujii Masao wrote:
> > > >
> > > > > When I talked about
On Wed, Jul 1, 2020 at 11:48 AM Magnus Hagander wrote:
> We don't even need to make it an exclusive mode -- we can allow
> *nonexclusive* backups but remove the requirement to run start and stop
> backup in the same connection, which I believe is the problem that people
> have with the
st 1. 7. 2020 v 20:19 odesílatel Vik Fearing
napsal:
> On 7/1/20 3:36 PM, Robert Haas wrote:
> > I actually don't have a very clear idea of what the standard has to
> > say about SQL-language functions. Does it just say it's a list of
> > statements, or does it involve variables and control-flow
Pavel Borisov writes:
> Below is my variant how to patch Gin-Gist weights issue:
I looked at this patch, but I'm unimpressed, because it's buggy.
You would have noticed if you'd included the test cases I wrote:
--- /home/postgres/pgsql/src/test/regress/expected/tsearch.out 2020-07-01 14:58
Hi,
On 2020-06-28 17:10:02 +0200, Tomas Vondra wrote:
> 3) Should we do batching for COPY insteads?
>
> While looking at multi_insert, I've realized it's mostly exactly what
> the new "batching insert" API function would need to be. But it's only
> really used in COPY, so I wonder if we should
On 7/1/20 3:36 PM, Robert Haas wrote:
> I actually don't have a very clear idea of what the standard has to
> say about SQL-language functions. Does it just say it's a list of
> statements, or does it involve variables and control-flow constructs
> and stuff like that, too?
It's either a single
Pavel Stehule writes:
> Last week I played with dbms_sql extension and some patterns of usage
> cursor in PL/SQL and PL/pgSQL. I found fact, so iteration over cursor (FOR
> statement) doesn't support unbound cursors. I think so this limit is not
> necessary.
I guess I don't understand why we
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Jul 1, 2020 at 6:29 PM Stephen Frost wrote:
> > * Magnus Hagander (mag...@hagander.net) wrote:
> > > On Wed, Jul 1, 2020 at 2:47 PM Stephen Frost wrote:
> > > > This would presumably be for the exclusive API as a way to make it
On 7/1/20 10:54 AM, Alvaro Herrera wrote:
On 2020-Jul-01, Fujii Masao wrote:
On 2020/07/01 12:26, Alvaro Herrera wrote:
On 2020-Jun-30, Fujii Masao wrote:
When I talked about max_slot_wal_keep_size as new feature in v13
at the conference, I received the question like "Why are the units of
Hi,
On 2020-07-01 22:20:50 +0900, Fujii Masao wrote:
> On 2020/07/01 4:03, Andres Freund wrote:
> > Why did you add the hashing here? It seems a lot better to just add an
> > lwlock in-place instead of the spinlock? The added size is neglegible
> > compared to the size of pgssEntry.
>
> Because
On Wed, Jul 1, 2020 at 6:29 PM Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
> > On Wed, Jul 1, 2020 at 2:47 PM Stephen Frost wrote:
> > > This would presumably be for the exclusive API as a way to make it not
> > > completely broken, maybe.
> > >
> > > If
Bruce Momjian writes:
> Is the SQL-standard function body verified as preventing function
> inlining? That seems to be a major downside.
I see no reason why that would make any difference. There might
be more code to be written than is in the patch, but in principle
inlining should not care
> On Jul 1, 2020, at 2:45 AM, Daniel Gustafsson wrote:
>
>> On 3 Jun 2020, at 19:05, Mark Dilger wrote:
>
>> The attached patch cleans this up.
>
> The gram.y hunks in this patch no longer applies, please submit a rebased
> version. I'm marking the entry Waiting on Author in the meantime.
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Jul 1, 2020 at 2:47 PM Stephen Frost wrote:
> > This would presumably be for the exclusive API as a way to make it not
> > completely broken, maybe.
> >
> > If we wanted to try and make this work in a non-exclusive manner then
>
On Wed, Jul 1, 2020 at 2:47 PM Stephen Frost wrote:
>
> This would presumably be for the exclusive API as a way to make it not
> completely broken, maybe.
>
> If we wanted to try and make this work in a non-exclusive manner then
> we'd need to do something like have the user save some info out
On Wed, Jul 1, 2020 at 10:14:10AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > In my experience, there's certainly demand for some kind of mode where
> > plpgsql functions get checked at function definition time, rather than
> > at execution time.
>
> Yeah, absolutely agreed. But I'm
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Wed, Jul 1, 2020 at 04:46:59PM +0200, Laurenz Albe wrote:
> > On Wed, 2020-07-01 at 08:47 -0400, Stephen Frost wrote:
> > > > I remain -1 on removing the exclusive backup API.
> > >
> > > It's still deprecated and I'm certainly against
On Wed, Jul 1, 2020 at 04:46:59PM +0200, Laurenz Albe wrote:
> On Wed, 2020-07-01 at 08:47 -0400, Stephen Frost wrote:
> > > I remain -1 on removing the exclusive backup API.
> >
> > It's still deprecated and I'm certainly against removing that status
> > until/unless someone actually fixes it
On 2020-Jul-01, Amit Kapila wrote:
> Okay, but do we think it is better to display this in
> pg_replication_slots or some new view like pg_stat_*_slots as being
> discussed in [1]? It should not happen that we later decide to move
> this or similar stats to that view.
It seems that the main
On 2020-Jul-01, Daniel Gustafsson wrote:
> > On 19 Mar 2020, at 08:55, Daniel Gustafsson wrote:
>
> > With no response for 2 weeks during the commitfest, I propose to move this
> > to
> > the next CF to allow time for discussions.
>
> This patch no longer applies, the failing hunk being in
On 2020-Jul-01, Fujii Masao wrote:
> On 2020/07/01 12:26, Alvaro Herrera wrote:
> > On 2020-Jun-30, Fujii Masao wrote:
> >
> > > When I talked about max_slot_wal_keep_size as new feature in v13
> > > at the conference, I received the question like "Why are the units of
> > > setting values in
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Wed, 2020-07-01 at 08:47 -0400, Stephen Frost wrote:
> > > I remain -1 on removing the exclusive backup API.
> >
> > It's still deprecated and I'm certainly against removing that status
> > until/unless someone actually fixes it
On Wed, 2020-07-01 at 08:47 -0400, Stephen Frost wrote:
> > I remain -1 on removing the exclusive backup API.
>
> It's still deprecated and I'm certainly against removing that status
> until/unless someone actually fixes it (including documentation), and if
> we're not going to do that then we
Etsuro Fujita writes:
> On Wed, Jul 1, 2020 at 7:21 AM Tom Lane wrote:
>> +baserel->tuples = Max(baserel->tuples, baserel->rows);
> for consistency, this should be
> baserel->tuples = clamp_row_est(baserel->rows / sel);
> where sel is the selectivity of the baserestrictinfo clauses?
If
st 1. 7. 2020 v 16:14 odesílatel Tom Lane napsal:
> Robert Haas writes:
> > In my experience, there's certainly demand for some kind of mode where
> > plpgsql functions get checked at function definition time, rather than
> > at execution time.
>
> Yeah, absolutely agreed. But I'm afraid this
Robert Haas writes:
> In my experience, there's certainly demand for some kind of mode where
> plpgsql functions get checked at function definition time, rather than
> at execution time.
Yeah, absolutely agreed. But I'm afraid this proposal takes us too
far in the other direction: with this,
st 1. 7. 2020 v 15:37 odesílatel Robert Haas napsal:
> On Tue, Jun 30, 2020 at 2:51 PM Tom Lane wrote:
> > On further thought, we probably don't have to. Re-parsing the function
> > body the same way is exactly the same problem as re-parsing a view or
> > matview body the same way. I don't
On 2020/07/01 22:15, torikoshia wrote:
On Wed, Jul 1, 2020 at 4:43 PM Fujii Masao wrote:
Thanks for reviewing!
You treat pg_stat_local_memory_contexts view as a dynamic statistics view.
But isn't it better to treat it as just system view like pg_shmem_allocations
or pg_prepared_statements
On Wed, 1 Jul 2020 at 18:14, Bharath Rupireddy
wrote:
>
> >
> > I've not looked at your patch deeply but if this problem is talking
> > only about postgres_fdw I think we should improve postgres_fdw, not
> > adding a GUC to the core. It’s not that all FDW plugins use connection
> > cache and
On Tue, Jun 30, 2020 at 2:51 PM Tom Lane wrote:
> On further thought, we probably don't have to. Re-parsing the function
> body the same way is exactly the same problem as re-parsing a view or
> matview body the same way. I don't want to claim that that's a 100%
> solved problem, but I've heard
On Wed, Jul 1, 2020 at 3:54 PM Bharath Rupireddy
wrote:
> If we were to use idle_session_timeout (from patch [1]) for the remote
> session to go off without
> having to delete the corresponding entry from local connection cache and
> after that if we submit foreign query from local session, then
> On 4 Apr 2020, at 01:26, Nikita Glukhov wrote:
> Fixed patch attached.
This patch cause a regression in the ltree_plpython module, it needs the below
trivial change to make it pass again:
--- a/contrib/ltree_plpython/expected/ltree_plpython.out
+++
On 2020/07/01 4:03, Andres Freund wrote:
Hi,
On 2020-06-30 14:43:39 +0900, Fujii Masao wrote:
I did a prototype patch that replaces spinlocks with futexes, but was not able
to find a workload where it mattered.
I'm not familiar with futex, but could you tell me why you used futex instead
On 2020-07-01 20:47, Daniel Gustafsson wrote:
For the next version (if there will be one), please remove the
catversion bump
from the patch as it will otherwise just break patch application
without
constant rebasing (as it's done now). The committer will handle the
catversion
change if/when
On Wed, Jul 1, 2020 at 4:43 PM Fujii Masao
wrote:
Thanks for reviewing!
You treat pg_stat_local_memory_contexts view as a dynamic statistics
view.
But isn't it better to treat it as just system view like
pg_shmem_allocations
or pg_prepared_statements because it's not statistics
On Wed, Jul 1, 2020 at 4:29 PM Bharath Rupireddy
wrote:
>
> changes look good to me.
Thanks for looking at the patch.
>
> one comment: instead of having block variables onexit, in the while
> loops in shmem_exit, can we have a single local variable defined at
> the start of the shmem_exit
On 2020/07/01 12:26, Alvaro Herrera wrote:
On 2020-Jun-30, Fujii Masao wrote:
Hi,
When I talked about max_slot_wal_keep_size as new feature in v13
at the conference, I received the question like "Why are the units of
setting values in max_slot_wal_keep_size and wal_keep_segments
1 - 100 of 142 matches
Mail list logo
