Hackers,
In the hope of this not being derailed by larger/more unpopular pieces of
work, I'm attaching a tiny patch which I don't believe will have any
negative impact - but will remove one blocker for $subject (sigprocmask
usage is "unspecified" in multithreaded code [1]).
The patch replaces *si
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 3
> >
> > 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() funct
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 signat
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 th
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 usag
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 plannin
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 whic
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 page
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 create_append
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 re
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?
>
> L
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 of
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 mov
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] https://en.wikipedia.org/wiki/SQL/PSM
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, and
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 the
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 we'd
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 mos
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 e
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 lit
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': c
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 a
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 <= i
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 3
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, that
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 idea
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 st
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
> recovery_t
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 scri
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 st
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 in
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 backup
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
> >
> > max_slo
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 SQL
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 back
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 no
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
>>> statements,
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 int
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 toget
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 lim
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
>wal
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 thus
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 use
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 per
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 earlie
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 replic
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 is
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 do
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 beli
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, whi
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 max_slot_wal_keep_
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 exclusiv
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
:56.
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 ju
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 s
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 shou
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
se
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 p
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 whe
> 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 at
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 afraid
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 re
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 (i
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 moti
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 the
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 max
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 (in
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 sho
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 we
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 p
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, you
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 wan
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 postg
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
+++ b/contrib/ltree_plpython/expected/ltree_plpy
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 information?
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 functi
1 - 100 of 141 matches
Mail list logo