On Thu, Apr 09, 2020 at 11:44:11AM -0400, Andrew Dunstan wrote:
> 39 Always unpack @_ first
Requiring a "my @args = @_" does not improve this code:
sub CreateSolution
{
...
if ($visualStudioVersion eq '12.00')
{
return new VS2013Solution(@_);
On Fri, Feb 14, 2020 at 1:50 PM Thomas Munro wrote:
> On Thu, Feb 13, 2020 at 7:18 PM Thomas Munro wrote:
> > ... (1) I'm pretty sure some systems would not be happy
> > about that (see claims in this thread) ...
>
> I poked a couple of people off-list and learned that, although the
> Linux and
On Sat, Apr 11, 2020 at 1:00 AM Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Fri, Apr 10, 2020 at 9:14 PM Tom Lane wrote:
> >> I see no patch here ...
>
> > Sorry. Here it is
>
> LGTM, will push in a moment.
Thanks for taking care of this, Tom! Thanks for the patch, Ashutosh!
Thanks for
On 2020-Mar-30, Andres Freund wrote:
> If we are really concerned with truncation failing - I don't know why we
> would be, we accept that we have to be able to modify files etc to stay
> up - we can add a pre-check ensuring that permissions are set up
> appropriately to allow us to truncate.
I
Hi,
On 2020-04-10 16:32:08 -0400, David Steele wrote:
> On 4/10/20 4:09 AM, Michael Paquier wrote:
> >
> > I have noticed that attempting to use pg_basebackup from HEAD leads to
> > failures when using it with backend versions from 12 and older:
> > $ pg_basebackup -D hoge
> > pg_basebackup:
On Fri, 10 Apr 2020 at 21:52, Fujii Masao wrote:
>
>
>
> On 2020/04/10 20:56, Masahiko Sawada wrote:
> > On Fri, 10 Apr 2020 at 18:57, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/04/10 14:11, Masahiko Sawada wrote:
> >>> On Fri, 10 Apr 2020 at 13:20, Fujii Masao
> >>> wrote:
>
>
Thanks Andres and Kyotaro for the quick review. I have fixed the typos and
also included the critical section (emulated it with try-catch block since
palloc()s are causing issues in the truncate code). This time I used git
format-patch.
Regards
Teja
From:
Jesse Zhang writes:
> On the other hand, we examined the corresponding final functions
> (numeric_stddev_pop and friends), they all seem to carefully treat a
> NULL trans value the same as a "zero input" (as in, state.N == 0 &&
> state.NaNcount ==0). That does suggest to me that it should be fine
I wrote:
> A more useful test would be to directly experiment with contended
> spinlocks. As I recall, we had some test cases laying about when
> we were fooling with the spin delay stuff on Intel --- maybe
> resurrecting one of those would be useful?
The last really significant performance
Hi Andres,
On Fri, Apr 10, 2020 at 12:14 PM Andres Freund wrote:
>
> Shouldn't these just be marked as strict?
>
Are you suggesting that because none of the corresponding trans
functions (int8_avg_accum, int2_accum, and friends) ever output NULL?
That's what we thought, but then I realized that
On Fri, Apr 10, 2020 at 8:37 AM Ashutosh Bapat <
ashutosh.ba...@2ndquadrant.com> wrote:
> for a multi-key value the ^
> points to the first column and the reader may think that that's the
> problematci column. Should it instead point to ( ?
I attached a v2 of Amit's 0002 patch to also report the
Hi,
On 2020-04-10 17:23:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-04-10 16:40:02 -0400, Tom Lane wrote:
> >> It doesn't really seem like either name is problematic from that
> >> standpoint? "Verify backup" isn't prejudging what aspect of the
> >> backup is going to be
Hi,
On 2020-04-10 17:17:10 -0400, Tom Lane wrote:
> > ISTM that we can make it BEGIN AFTER 'xx/xx' or such, which'd not
> > require any keywords, it'd be easier to use than a procedure.
>
> I still don't see a good argument for tying this to BEGIN. If it
> has to be a statement, why not a
Andres Freund writes:
> On 2020-04-10 16:40:02 -0400, Tom Lane wrote:
>> It doesn't really seem like either name is problematic from that
>> standpoint? "Verify backup" isn't prejudging what aspect of the
>> backup is going to be verified, AFAICS.
> My point is that I'd eventually like to see
Hi,
On 2020-04-10 16:40:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-04-10 16:13:18 -0400, Tom Lane wrote:
> >> Well, we're not getting there for v13. Are you proposing that this
> >> patch just be reverted because it doesn't do everything at once?
>
> > No. I suggest choosing
Andres Freund writes:
> On 2020-04-10 16:29:39 -0400, Tom Lane wrote:
>> Good point, but we could address that by making it a procedure no?
> Probably. Don't think we have great infrastructure for builtin
> procedures yet though? We'd presumably not want to use plpgsql.
Don't think anyone's
Hi,
On 2020-04-10 16:29:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think a function is a good idea - it'll cause a snapshot to be
> > held while waiting. Which in turn will cause hot_standby_feedback to not
> > be able to report an increased xmin up. And it will possibly hit
>
On 4/10/20 4:41 PM, Stephen Frost wrote:
Greetings,
* David Steele (da...@pgmasters.net) wrote:
On 4/10/20 4:09 AM, Michael Paquier wrote:
I have noticed that attempting to use pg_basebackup from HEAD leads to
failures when using it with backend versions from 12 and older:
$ pg_basebackup -D
Greetings,
* David Steele (da...@pgmasters.net) wrote:
> On 4/10/20 4:09 AM, Michael Paquier wrote:
> >I have noticed that attempting to use pg_basebackup from HEAD leads to
> >failures when using it with backend versions from 12 and older:
> >$ pg_basebackup -D hoge
> >pg_basebackup: error:
Andres Freund writes:
> On 2020-04-10 16:13:18 -0400, Tom Lane wrote:
>> Well, we're not getting there for v13. Are you proposing that this
>> patch just be reverted because it doesn't do everything at once?
> No. I suggest choosing a name that's compatible with moving more
> capabilities under
Hi,
On 2020-04-10 16:13:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, I still think it's a mistake to accumulate all these bespoke
> > tools. We should go towards having one tool that can verify checksums,
> > validate backup manifests etc. Partially because it's more discoverable,
On 4/10/20 4:09 AM, Michael Paquier wrote:
I have noticed that attempting to use pg_basebackup from HEAD leads to
failures when using it with backend versions from 12 and older:
$ pg_basebackup -D hoge
pg_basebackup: error: backup manifests are not supported by server
version 12beta2
Andres Freund writes:
> I don't think a function is a good idea - it'll cause a snapshot to be
> held while waiting. Which in turn will cause hot_standby_feedback to not
> be able to report an increased xmin up. And it will possibly hit
> snapshot recovery conflicts.
Good point, but we could
"Bossart, Nathan" writes:
> I think I've found a small bug in pg_dump that could cause some schema
> privileges to be missed. In short, if you've renamed a schema that
> has an entry in pg_init_privs, pg_dump will skip dumping the initial
> ACL for the schema. This results in missing privileges
Andres Freund writes:
> On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
>> On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
>> using a sample C program (attached spin.c).
> PAUSE doesn't operate on the level of the CPU scheduler. So the OS won't
> just schedule another
Andres Freund writes:
> On 2020-04-09 16:22:11 -0700, Jesse Zhang wrote:
>> We found that several functions -- namely numeric_combine,
>> numeric_avg_combine, numeric_poly_combine, and int8_avg_combine -- are
>> returning NULL without signaling the nullity of datum in fcinfo.isnull.
>> This is
Andres Freund writes:
> FWIW, I still think it's a mistake to accumulate all these bespoke
> tools. We should go towards having one tool that can verify checksums,
> validate backup manifests etc. Partially because it's more discoverable,
> but also because it allows to verify multiple such
Konstantin Knizhnik writes:
> On 25.03.2020 13:36, Richard Guo wrote:
>> I tried this recipe on different PostgreSQL versions, starting from
>> current master and going backwards. I was able to reproduce this issue
>> on all versions above 8.4. In 8.4 version, we do not output information
>> on
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2020-04-10 14:56:48 -0400, David Steele wrote:
> > On 4/10/20 11:37 AM, Tom Lane wrote:
> > > Robert Haas writes:
> > > > Over at
> > > > https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com
> > >
Hi,
On 2020-04-10 14:56:48 -0400, David Steele wrote:
> On 4/10/20 11:37 AM, Tom Lane wrote:
> > Robert Haas writes:
> > > Over at
> > > https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com
> > > Peter Eisentraut suggests that pg_validatebackup should be
On Fri, Apr 10, 2020 at 8:17 AM Amit Kapila wrote:
>
> On Tue, Apr 7, 2020 at 2:48 PM Julien Rouhaud wrote:
> >
> > On Tue, Apr 7, 2020 at 4:36 AM Amit Kapila wrote:
> > >
> > > On Mon, Apr 6, 2020 at 7:58 PM Euler Taveira
> > > wrote:
> > > Few comments:
> > > 1.
> > > - int64 wal_num_fpw; /*
Hi,
On 2020-04-10 12:20:01 -0400, Robert Haas wrote:
> - We're only talking about writing a handful of tar files, and that's
> in the context of a full-database backup, which is a much
> heavier-weight operation than a query.
> - There is not really any state that needs to be maintained across
Hi,
On 2020-04-10 11:25:02 +0900, Fujii Masao wrote:
> > BEGIN
> > WAIT (LSN '16/B374D848', WHATEVER_OPTION_YOU_WANT);
> > ...
> > COMMIT;
> >
> > It requires only one reserved keyword 'WAIT'. The advantage of this
> > approach is that it can be extended to support xid, timestamp, csn or
> >
On 4/10/20 3:27 PM, Tom Lane wrote:
David Steele writes:
Having said that, I'm +1 on verify.
Me too, if only because it's shorter.
I also think it is (probably) more correct but failing that it is
*definitely* shorter!
--
-David
da...@pgmasters.net
David Steele writes:
> Having said that, I'm +1 on verify.
Me too, if only because it's shorter.
regards, tom lane
Hi,
On 2020-04-10 13:09:13 +0530, Amit Khandekar wrote:
> On my Intel Xeon machine with 8 cores, I tried to test PAUSE also
> using a sample C program (attached spin.c). Here, many child processes
> (much more than CPUs) wait in a tight loop for a shared variable to
> become 0, while the parent
Hi,
On 2020-04-09 16:22:11 -0700, Jesse Zhang wrote:
> We found that several functions -- namely numeric_combine,
> numeric_avg_combine, numeric_poly_combine, and int8_avg_combine -- are
> returning NULL without signaling the nullity of datum in fcinfo.isnull.
> This is obscured by the fact that
On 4/10/20 11:37 AM, Tom Lane wrote:
Robert Haas writes:
Over at
https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
Hi,
On 2020-04-10 07:40:06 -0400, Robert Haas wrote:
> On Thu, Apr 9, 2020 at 4:00 PM Andres Freund wrote:
> > Imo, yes, there should be only one process doing the chunking. For ilp,
> > cache efficiency, but also because the leader is the only process with
> > access to the network socket. It
Hi
rebase
Regards
Pavel
ne 22. 3. 2020 v 8:40 odesílatel Pavel Stehule
napsal:
> Hi
>
> rebase
>
> Regards
>
> Pavel
>
schema-variables-20200310.patch.gz
Description: application/gzip
On Fri, 10 Apr 2020 at 14:31, Amit Langote wrote:
> I agree with that. Tried that in the attached 0002, although trying
> to get the cursor to point to exactly the offending column seems a bit
> tough for partition overlap errors. The patch does allow to single
> out which one of the lower and
On Fri, Apr 10, 2020 at 10:54 AM Stephen Frost wrote:
> So, this goes to what I was just mentioning to Bruce independently- you
> could have made the same argument about FDWs, but it just doesn't
> actually hold any water. Sure, some of the FDWs aren't great, but
> there's certainly no shortage
Ashutosh Bapat writes:
> On Fri, Apr 10, 2020 at 9:14 PM Tom Lane wrote:
>> I see no patch here ...
> Sorry. Here it is
LGTM, will push in a moment.
regards, tom lane
On Fri, Apr 10, 2020 at 9:14 PM Tom Lane wrote:
>
> Ashutosh Bapat writes:
> > On Fri, 10 Apr 2020 at 20:44, Jeff Janes wrote:
> >> In that case, we really should add the PG_USED_FOR_ASSERTS_ONLY to make
> >> the compiler happy.
>
> > Attaching my patch again. It doesn't need
On Fri, Apr 10, 2020 at 10:54:10AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian wrote:
> > > Good point, but if there are multiple APIs, it makes shell script
> > > flexibility even more useful.
> >
>
Ashutosh Bapat writes:
> On Fri, 10 Apr 2020 at 20:44, Jeff Janes wrote:
>> In that case, we really should add the PG_USED_FOR_ASSERTS_ONLY to make
>> the compiler happy.
> Attaching my patch again. It doesn't need PG_USED_FOR_ASSERTS_ONLY as well.
> Kuntal has confirmed that this fixes the
On Fri, 10 Apr 2020 at 14:31, Amit Langote wrote:
> On Thu, Apr 9, 2020 at 11:04 PM Tom Lane wrote:
> > While I'm quite on board with providing useful error cursors,
> > the example cases in this patch don't seem all that useful:
> >
> > -- trying to create range partition with empty range
> >
Robert Haas writes:
> Over at
> https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com
> Peter Eisentraut suggests that pg_validatebackup should be called
> pg_verifybackup, with corresponding terminology changes throughout the
> code and documentation.
>
On Fri, 10 Apr 2020 at 20:44, Jeff Janes wrote:
> On Thu, Apr 9, 2020 at 10:04 AM Ashutosh Bapat <
> ashutosh.bapat@gmail.com> wrote:
>
>> On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita
>> wrote:
>> >
>> > On Thu, Apr 9, 2020 at 2:36 PM Tom Lane wrote:
>> > > Etsuro Fujita writes:
>> > > >
On 4/10/20 3:19 PM, Jeremy Morton wrote:
Oh well. Guess I keep using SQL Server then. datetimeoffset makes it
impossible for developers to make the mistake of forgetting to use UTC
instead of local datetime, and for that reason alone it makes it
invaluable in my opinion. It should be used
On Thu, Apr 9, 2020 at 10:04 AM Ashutosh Bapat
wrote:
> On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita
> wrote:
> >
> > On Thu, Apr 9, 2020 at 2:36 PM Tom Lane wrote:
> > > Etsuro Fujita writes:
> > > > Yeah, partition_bounds_merge() is currently called only from
> > > >
On 2020-04-10 05:25, Fujii Masao wrote:
On 2020/04/10 3:16, Alexey Kondratov wrote:
Just another idea in case if one will still decide to go with a
separate statement + BEGIN integration instead of a function. We could
use parenthesized options list here. This is already implemented for
On Fri, Apr 10, 2020 at 2:25 PM Amit Kapila wrote:
>
> I see that the kind of check you are talking is recently added by
> commit 352f6f2d. I think it is better to be consistent in all places.
> Let's pick one and use that if possible.
Currently there are two constructs to test the same
Over at
https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017...@2ndquadrant.com
Peter Eisentraut suggests that pg_validatebackup should be called
pg_verifybackup, with corresponding terminology changes throughout the
code and documentation.
Here's a patch for that. I'd like to
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian wrote:
> > Good point, but if there are multiple APIs, it makes shell script
> > flexibility even more useful.
>
> This is really the key point for me. There are so many existing tools
> that
Hi,
Attached is the latest patch (v15) to add support for Incremental Materialized
View Maintenance (IVM). It is possible to apply to current latest master branch.
Differences from the previous patch (v14) include:
* Fix to not use generate_series when views are queried
In the previous
> On Apr 10, 2020, at 8:19 AM, Jeremy Morton wrote:
>
> Oh well. Guess I keep using SQL Server then. datetimeoffset makes it
> impossible for developers to make the mistake of forgetting to use UTC
> instead of local datetime, and for that reason alone it makes it invaluable
> in my
One thing I just noticed and had a question about: in
preparePresortedCols (which sets up a function call context), do we
need to call pg_proc_aclcheck?
James
Jeremy Morton writes:
> Oh well. Guess I keep using SQL Server then. datetimeoffset makes it
> impossible for developers to make the mistake of forgetting to use UTC
> instead of local datetime,
Really? That would be a remarkable feat for a mere datatype to
accomplish.
> and for that
On Thu, Apr 9, 2020 at 1:46 AM Thomas Munro wrote:
> The attached highly experimental patch adds a new GUC
> dynamic_shared_memory_main_size. If you set it > 0, it creates a
> fixed sized shared memory region that supplies memory for "fast" DSM
> segments. When there isn't enough free space,
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Apr 9, 2020 at 04:15:07PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > I think we need to step back and look at the larger issue. The real
> > > argument goes back to the Unix command-line API vs
On Thu, Apr 9, 2020 at 6:44 PM Bruce Momjian wrote:
> Good point, but if there are multiple APIs, it makes shell script
> flexibility even more useful.
This is really the key point for me. There are so many existing tools
that store a file someplace that we really can't ever hope to support
them
On Fri, Apr 10, 2020 at 12:56:08PM +0530, Amit Kapila wrote:
> On Wed, Apr 8, 2020 at 12:49 PM Masahiko Sawada
> wrote:
> >
> > On Tue, 7 Apr 2020 at 13:55, Justin Pryzby wrote:
> > >
> >
> > I don't have comments on your change other than the comments Amit
> > already sent. Thank you for
Oh well. Guess I keep using SQL Server then. datetimeoffset makes it
impossible for developers to make the mistake of forgetting to use UTC
instead of local datetime, and for that reason alone it makes it
invaluable in my opinion. It should be used universally instead of
datetime.
--
Best
On Fri, Apr 10, 2020 at 10:34:02AM +0530, Amit Kapila wrote:
> On Thu, Apr 9, 2020 at 2:03 PM Justin Pryzby wrote:
> > On Thu, Apr 09, 2020 at 05:07:48PM +0900, Masahiko Sawada wrote:
> > > Yes but the difference is that we cannot disable PARSER or COPY by
> > > specifying options whereas we can
On Thu, Apr 9, 2020 at 10:08 PM Peter Geoghegan wrote:
>
> On Thu, Apr 9, 2020 at 6:47 PM James Coleman wrote:
> > I believe the write pattern to this table likely looks like:
> > - INSERT
> > - UPDATE
> > - DELETE
> > for every row. But tomorrow I can do some more digging if needed.
>
> The
On Wed, Feb 19, 2020 at 11:14 PM Andres Freund wrote:
> Here's a *draft* patch series for removing all use of SHM_QUEUE, and
> subsequently removing SHM_QUEUE.
+1 for that idea.
But color me skeptical of what Thomas described as the "incidental
constification".
--
Robert Haas
EnterpriseDB:
On Mon, Feb 10, 2020 at 11:22 PM Andres Freund wrote:
> To me this seems to go in the direction of having multiple bespoke lock
> managers with slightly different feature sets, different debugging /
> logging / monitoring support, with separate locking code each. That's
> bad for
On 2020/04/10 20:56, Masahiko Sawada wrote:
On Fri, 10 Apr 2020 at 18:57, Fujii Masao wrote:
On 2020/04/10 14:11, Masahiko Sawada wrote:
On Fri, 10 Apr 2020 at 13:20, Fujii Masao wrote:
On 2020/04/08 3:01, Ashwin Agrawal wrote:
On Mon, Apr 6, 2020 at 2:14 PM Andres Freund
On Fri, Apr 10, 2020 at 5:35 PM Amit Kapila wrote:
>
> On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha
> wrote:
> >
> > * I think you could save a couple of code lines, and make it clearer, by
> > merging both tests on _MSC_VER into a single #if... #else and leaving as
> > common
On 4/10/20 10:34 AM, Jeremy Morton wrote:
I've noticed that Postgres doesn't have support for DATETIMEOFFSET (or
any functional equivalent data type) yet. Is this on the roadmap to
implement? I find it a very useful data type that I use all over the
place in TSQL databases.
Hi,
I do not
On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha
wrote:
>
> * I think you could save a couple of code lines, and make it clearer, by
> merging both tests on _MSC_VER into a single #if... #else and leaving as
> common code:
> + }
> + else
> + return NULL;
> +#endif /*_MSC_VER &&
On Mon, Apr 6, 2020 at 4:38 PM davinder singh
wrote:
>
> Hi All,
>
> I am working on “pg_locale compilation error with Visual Studio 2017”,
> Related threads[1],[2].
> We are getting compilation error in static char *IsoLocaleName(const char
> *winlocname) function in pg_locale.c file. This
On Fri, 10 Apr 2020 at 18:57, Fujii Masao wrote:
>
>
>
> On 2020/04/10 14:11, Masahiko Sawada wrote:
> > On Fri, 10 Apr 2020 at 13:20, Fujii Masao
> > wrote:
> >>
> >>
> >>
> >> On 2020/04/08 3:01, Ashwin Agrawal wrote:
> >>>
> >>> On Mon, Apr 6, 2020 at 2:14 PM Andres Freund >>>
On Thu, Apr 9, 2020 at 4:00 PM Andres Freund wrote:
> I've not yet read the whole thread. So I'm probably restating ideas.
Yeah, but that's OK.
> Imo, yes, there should be only one process doing the chunking. For ilp, cache
> efficiency, but also because the leader is the only process with
On 2020/04/10 14:11, Masahiko Sawada wrote:
On Fri, 10 Apr 2020 at 13:20, Fujii Masao wrote:
On 2020/04/08 3:01, Ashwin Agrawal wrote:
On Mon, Apr 6, 2020 at 2:14 PM Andres Freund mailto:and...@anarazel.de>> wrote:
> How about we change it to this ?
Hm. Better. But I think
On Thu, Apr 9, 2020 at 11:04 PM Tom Lane wrote:
> While I'm quite on board with providing useful error cursors,
> the example cases in this patch don't seem all that useful:
>
> -- trying to create range partition with empty range
> CREATE TABLE fail_part PARTITION OF range_parted2 FOR VALUES
I've noticed that Postgres doesn't have support for DATETIMEOFFSET (or
any functional equivalent data type) yet. Is this on the roadmap to
implement? I find it a very useful data type that I use all over the
place in TSQL databases.
--
Best regards,
Jeremy Morton (Jez)
Hello,
I was off the point.
I want to organize the discussion and suggest feature design.
There are two opinions.
1. COMMIT should not take a long time because errors are more likely to occur.
2. The data area should be released when COMMIT is completed because COMMIT has
to be an atomic
Hi,
I have noticed that attempting to use pg_basebackup from HEAD leads to
failures when using it with backend versions from 12 and older:
$ pg_basebackup -D hoge
pg_basebackup: error: backup manifests are not supported by server
version 12beta2
pg_basebackup: removing data directory "hoge"
This
On Fri, 10 Apr 2020 at 16:26, Amit Kapila wrote:
>
> On Wed, Apr 8, 2020 at 12:49 PM Masahiko Sawada
> wrote:
> >
> > On Tue, 7 Apr 2020 at 13:55, Justin Pryzby wrote:
> > >
> >
> > I don't have comments on your change other than the comments Amit
> > already sent. Thank you for reviewing this
Hi,
We use (an equivalent of) the PAUSE instruction in spin_delay() for
Intel architectures. The goal is to slow down the spinlock tight loop
and thus prevent it from eating CPU and causing CPU starvation, so
that other processes get their fair share of the CPU time. Intel
documentation [1]
On Wed, Apr 8, 2020 at 12:49 PM Masahiko Sawada
wrote:
>
> On Tue, 7 Apr 2020 at 13:55, Justin Pryzby wrote:
> >
>
> I don't have comments on your change other than the comments Amit
> already sent. Thank you for reviewing this part!
>
I have made the modifications as per my comments. What do
FWIW, I don't object for adding the feature like this (in other words
+1), since I see the advantages Alex mentioned is valid. (Even though
most of our customers notices server restart by client
disconnections..)
At Wed, 8 Apr 2020 11:49:11 -0400, David Steele wrote in
> On 2/24/20 10:57 PM,
On Thu, Apr 09, 2020 at 10:01:51PM -0500, Justin Pryzby wrote:
> On Fri, Apr 10, 2020 at 11:27:46AM +0900, Michael Paquier wrote:
>> required pages to remove both downlink and rightlink are already locked.
>> That
>> -evades potential right to left page locking order, which could deadlock with
On Tue, Apr 7, 2020 at 2:48 PM Julien Rouhaud wrote:
>
> On Tue, Apr 7, 2020 at 4:36 AM Amit Kapila wrote:
> >
> > On Mon, Apr 6, 2020 at 7:58 PM Euler Taveira
> > wrote:
> > >
> > > On Mon, 6 Apr 2020 at 10:37, Julien Rouhaud wrote:
> > >>
> > >> On Mon, Apr 06, 2020 at 10:12:55AM -0300,
86 matches
Mail list logo
