Hi,
Attached patch makes an adjustment to ipc.c code to be in the 80-column
window.
Regards,
Amul
0001-cleanup-adjust-code-in-80-column-window.patch
Description: Binary data
On 2020/07/01 14:48, torikoshia wrote:
On Mon, Jun 29, 2020 at 3:13 PM Fujii Masao wrote:
Could you add this patch to Commitfest 2020-07?
Thanks for notifying, I've added it.
BTW, I registered you as an author because this patch used
lots of pg_cheat_funcs' codes.
https://commitfest.p
On Tue, 2020-06-30 at 17:38 -0400, David Steele wrote:
> Rebased patch is attached.
I remain -1 on removing the exclusive backup API.
People who don't mind manual intervention when PostgreSQL doesn't
start after a crash in backup mode could safely use it.
We have been over this, and there is not
> On 29 Jun 2020, at 13:52, Robert Haas wrote:
> On Sun, Jun 28, 2020 at 11:24 AM Hamid Akhtar wrote:
>> The new status of this patch is: Ready for Committer
>
> Thanks, but this was committed on June 15th, as per my previous email.
> Perhaps I forgot to update the CommitFest application
D
> On 27 Mar 2020, at 11:22, Haozhou Wang wrote:
> We rebased this patch with the newest master.
This patch now fails to build according to Travis:
smgr.c: In function ‘smgrtruncate’:
smgr.c:578:47: error: passing argument 4 of ‘smgrtruncate_hook’ makes integer
from pointer without a cast [-Wer
Hi,
This patch fails to apply to HEAD, please submit a rebased version. I've
marked this as as Waiting on Author.
cheers ./daniel
> On 29 Mar 2020, at 17:27, Tomas Vondra wrote:
> On Sun, Mar 29, 2020 at 10:22:25AM +0100, Dean Rasheed wrote:
>> On Sat, 28 Mar 2020 at 13:18, Dean Rasheed wrote:
>>> OK, I've pushed that with your recommendation for that function name.
>>
>> Does this now complete everything that you wanted
On Tue, Jun 30, 2020 at 7:53 PM Fujii Masao wrote:
>
> On 2020/06/30 17:07, Fujii Masao wrote:
> >
> >
> > On 2020/06/26 13:45, Amit Kapila wrote:
> >>
> >> Can we consider an option to "Remove min_safe_lsn; document how a user
> >> can monitor the distance"? We have a function to get current WAL
> On 7 Apr 2020, at 21:45, Dave Cramer wrote:
> New patch that fixes a number of errors in the check for validity as well as
> reduces the memory usage by
> dynamically allocating the data changed as well as collapsing the changed and
> binary arrays into a format array.
The 0001 patch fails t
> 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 docs part. As
stated in my review earlier in the thread I
On Tue, Jun 30, 2020 at 8:54 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
> On Mon, 22 Jun 2020 at 14:56, Bharath Rupireddy
> wrote:
> >
> > Hi,
> >
> > When a query on foreign table is executed from a local session using
> > postgres_fdw, as expected the local postgres backend op
> On 2 Mar 2020, at 00:45, Rémi Lapeyre wrote:
> I created an entry for this patch in the new CommiFest but it seems that it
> is not finding it. Is there anything that I need to do?
This patch no longer applies cleanly on HEAD, due to changes in the regress
tests. Please submit a rebased vers
> On 27 Dec 2019, at 08:34, Kohei KaiGai wrote:
> The attached v2 fixed the problem, and regression test finished correctly.
This patch no longer applies to HEAD, please submit an rebased version.
Marking the entry Waiting on Author in the meantime.
cheers ./daniel
>
> 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 postgres_fdw’s connection cache is implemented within
> postgres_fdw, I
> On 1 Mar 2020, at 20:26, Tom Lane wrote:
> In short, I really think we ought to reject this patch and move on.
> Maybe it could be resurrected sometime in the future when we have a
> better handle on when to cache plans and when not.
>
> If you want to press forward with it anyway, certainly t
On Tue, Jun 30, 2020 at 02:25:07PM +0200, Daniel Gustafsson wrote:
> Ok, once the final state of this patchset is known I can take a stab at
> recording multiple dependencies with different behaviors as a separate
> patchset.
Thanks. I have applied 0001 and 0002 today, in a reversed order
actuall
> On 21 Apr 2020, at 18:21, yuzuko wrote:
> I'll update the patch soon.
Do you have an updated version to submit? The previous patch no longer applies
to HEAD, so I'm marking this entry Waiting on Author in the meantime.
cheers ./daniel
> On 24 Mar 2020, at 17:24, Konstantin Knizhnik
> wrote:
> Rebased version of the patch is attached.
And this patch also fails to apply now, can you please submit a new version?
Marking the entry as Waiting on Author in the meantime.
cheers ./daniel
Hi,
Added this to commitfest incase this is useful -
https://commitfest.postgresql.org/28/
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jun 29, 2020 at 10:50 AM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> Hi Hackers,
>
> For Copy Fr
This patch incurs a compiler warning, which probably is quite simple to fix:
heapam.c: In function ‘heap_multi_insert’:
heapam.c:2349:4: error: ‘recptr’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
visibilitymap_set(relation, BufferGetBlockNumber(buffer), buffer,
> 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.
cheers ./daniel
> On 1 Jul 2020, at 08:30, Amit Langote wrote:
>
> On Fri, Jun 26, 2020 at 9:36 PM Amit Langote wrote:
>> I would like to discuss a refactoring patch that builds on top of the
>> patches at [1] to address $subject.
>
> I forgot to update a place in postgres_fdw causing one of its tests to crash
> On 2 Mar 2020, at 06:08, Amit Langote wrote:
>
> On Mon, Mar 2, 2020 at 4:43 AM Tom Lane wrote:
>> Amit Langote writes:
>>> Rebased again.
>>
>> Seems to need that again, according to cfbot :-(
>
> Thank you, done.
..and another one is needed as it no longer applies, please submit a rebase
On Wed, Jul 1, 2020 at 2:45 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> 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
On Fri, 26 Jun 2020 16:14:38 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Thu, 25 Jun 2020 19:27:54 +0200, Jehan-Guillaume de Rorthais
> wrote in
> > Here is a summary of my work during the last few days on this demote
> > approach.
> >
> > Please, find in attachment v2-0001-Demote-Po
>
> I thought we would add a core capability, idle_session_timeout, which
> would disconnect idle sessions, and the postgres_fdw would use that. We
> have already had requests for idle_session_timeout, but avoided it
> because it seemed better to tell people to monitor pg_stat_activity and
> termi
Honestly I'm getting a little weary of fixing this up only to have the
patch not get reviewed.
Apparently it has no value so unless someone is willing to review it and
get it committed I'm just going to let it go.
Thanks,
Dave Cramer
On Wed, 1 Jul 2020 at 04:53, Daniel Gustafsson wrote:
> >
changes look good to me.
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() fun
On Wed, Jul 1, 2020 at 7:21 AM Tom Lane wrote:
> Attached are a couple of quick-hack patches along each of those lines.
> Either one resolves the crazy number-of-groups estimate for Jeff's
> example; neither changes any existing regression test results.
>
> On the whole I'm not sure I like 0001 (i
> On 24 Mar 2020, at 15:33, Tomas Vondra wrote:
>
> On Tue, Mar 24, 2020 at 01:20:07PM +, Dean Rasheed wrote:
>> Sounds like a reasonable approach, but I think it would be better to
>> preserve the current public API by having clauselist_selectivity()
>> become a thin wrapper around a new f
> On 9 Apr 2020, at 05:54, Craig Ringer wrote:
> Any thoughts here? I'd like to get it merged if possible and I hope my
> explanation of why I did it that way clears things up.
According to the CFBot patch tester, this fails the test_extensions and
test_extdepend test suites. I've marked the p
> On 1 Jul 2020, at 07:48, torikoshia wrote:
> Attached a patch for creating a view for local memory context
> and its explanation on the document.
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 with
> On 29 Feb 2020, at 18:24, Andrey M. Borodin wrote:
> I've fixed this and added patch with GiST reloption to provide sort support
> function.
0002 in this patchset fails to apply, please submit a rebased version. I've
marked the entry Waiting for Author in the meantime.
cheers ./daniel
> On 4 Mar 2020, at 12:06, Masahiko Sawada
> wrote:
> Attached updated patch that incorporated comments from Amit and Vignesh.
This patch fails to compile due to an Oid collision in pg_proc.dat. Please
submit a new version with an Oid from the recommended range for new patches:
8000-. See
> On 30 Jun 2020, at 15:54, Vik Fearing wrote:
> This feature adds RESPECT NULLS and IGNORE NULLS syntax to several
> window functions, according to the SQL Standard.
This fails compilation due to a compiler warning in WinGetFuncArgInPartition
and WinGetFuncArgInFrame (same warning in both):
no
> On 8 Apr 2020, at 02:21, Jeff Davis wrote:
> The attached patch is narrow and solves the problem for HashAgg nicely
> without interfering with anything else, so I plan to commit it soon for
> v13.
If I read this thread correctly, there is nothing outstanding here for 14 from
this patch? I've
This patch no longer applies to HEAD, please submit a rebased version. I've
marked it Waiting on Author in the meantime.
cheers ./daniel
Hi,
While reviewing copy from I identified few improvements for copy from
that can be done :
a) copy from stdin copies lesser amount of data to buffer even though
space is available in buffer because minread was passed as 1 to
CopyGetData, Hence it only reads until the data read from libpq is
les
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Tue, 2020-06-30 at 17:38 -0400, David Steele wrote:
> > Rebased patch is attached.
>
> I remain -1 on removing the exclusive backup API.
It's still deprecated and I'm certainly against removing that status
until/unless someone actu
> On 3 Mar 2020, at 21:21, Soumyadeep Chakraborty
> wrote:
> Attached is a patch on top of
> v2-0026-WIP-expression-eval-relative-pointer-suppport.patch that eliminates
> the
> const pointer references to fmgrInfo in the generated code.
Since the CFBot patch tester isn't to apply and test a pa
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 different?"
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
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 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 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 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 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 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, 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 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
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
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 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
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
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
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 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
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, 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 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
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 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
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
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 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.
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 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
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 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
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
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
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
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
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.
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
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
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 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.
>
>
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 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
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 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
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 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
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
>>
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
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
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
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
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 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
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 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 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
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 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
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: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
1 - 100 of 141 matches
Mail list logo
