Hello pg hackers,
This is the definition of the function:
SyncRepWaitForLSN(XLogRecPtr lsn, bool commit)
1. In the code, it emits ereport(WARNING) for the
ProcDiePending/QueryCancelPending case like this:
ereport(WARNING,
(errcode(ERRCODE_ADMIN_SHUTDOWN),
On Mon, Dec 16, 2019 at 7:21 PM Andrew Dunstan
wrote:
> On Mon, Dec 16, 2019 at 2:50 PM Thomas Munro wrote:
> > > If you're going to link to anything it should probably be to the Msys2
> > > binaries, because a) they are likely to be more up to date and b)
> > > unlike msys1 they are available
On Thu, 12 Dec 2019 at 15:28, Rahila Syed wrote:
>
> Hi Amit,
>
>
> 2. Following test fails with error.
> make -C src/test/recovery/ check
> PROVE_TESTS=t/018_standby_logical_decoding_xmins.pl
> # Failed test 'physical catalog_xmin not null'
> # at t/018_standby_logical_decoding_xmins.pl
On Mon, Dec 16, 2019 at 2:50 PM Thomas Munro wrote:
> > If you're going to link to anything it should probably be to the Msys2
> > binaries, because a) they are likely to be more up to date and b)
> > unlike msys1 they are available by default for all four VS toolsets
> > Appveyor provides.
>
>
On Wed, Oct 30, 2019 at 10:32 PM Peter Eisentraut
wrote:
>
> To move this topic a long, I'll submit some preparatory patches in a
> committable order.
>
> First is the patch to deal with getpeereid() that was already included
> in the previous patch series. This is just some refactoring that
>
On Mon, Dec 16, 2019 at 4:49 PM Andrew Dunstan
wrote:
> The reason I use chocolatey is to avoid having a dependency on Msys/Msys2 ;-)
Heh. Well Chocolatey looks like a really nice project, and I see that
they package PostgreSQL, and their site shows 85,427 downloads. Neat!
I just think it's a
On Mon, Dec 16, 2019 at 2:04 PM Thomas Munro wrote:
>
> On Mon, Dec 16, 2019 at 4:31 PM Amit Kapila wrote:
> > On Mon, Dec 16, 2019 at 8:16 AM Michael Paquier wrote:
> > > On Mon, Dec 16, 2019 at 11:25:55AM +1300, Thomas Munro wrote:
> > > > You can see MinGW, MSYS and Cygwin there, and I
On Mon, Dec 16, 2019 at 4:31 PM Amit Kapila wrote:
> On Mon, Dec 16, 2019 at 8:16 AM Michael Paquier wrote:
> > On Mon, Dec 16, 2019 at 11:25:55AM +1300, Thomas Munro wrote:
> > > You can see MinGW, MSYS and Cygwin there, and I suspect that one of
> > > those is the answer, but I'm not familiar
On Mon, Dec 16, 2019 at 8:16 AM Michael Paquier wrote:
>
> On Mon, Dec 16, 2019 at 11:25:55AM +1300, Thomas Munro wrote:
> > You can see MinGW, MSYS and Cygwin there, and I suspect that one of
> > those is the answer, but I'm not familiar with them or what else might
> > be available to install
On Sun, Dec 15, 2019 at 8:51 AM Robert Haas wrote:
>
> On Thu, Dec 12, 2019 at 9:23 PM Amit Kapila wrote:
> > Do you think we need such an Assert after having StaticAssert for
> > (THRESHOLD_SUBTRANS_CLOG_OPT <= PGPROC_MAX_CACHED_SUBXIDS) and then
> > an if statement containing (nsubxids <=
On Fri, Nov 29, 2019 at 11:39 AM Michael Paquier wrote:
>
> On Thu, Oct 03, 2019 at 05:54:40PM +0900, Fujii Masao wrote:
> > On Thu, Oct 3, 2019 at 1:57 PM Michael Paquier wrote:
> > >
> > > On Thu, Oct 03, 2019 at 01:49:34PM +0900, Fujii Masao wrote:
> > > > But this can cause subsequent
On Sun, Dec 15, 2019 at 10:27:12AM -0600, Justin Pryzby wrote:
> I named it so because it calls both lazy_vacuum_index
> ("PROGRESS_VACUUM_PHASE_VACUUM_INDEX") and
> lazy_vacuum_heap("PROGRESS_VACUUM_PHASE_VACUUM_HEAP")
>
> I suppose you don't think the other way around is better?
>
On Mon, Dec 16, 2019 at 11:25:55AM +1300, Thomas Munro wrote:
> You can see MinGW, MSYS and Cygwin there, and I suspect that one of
> those is the answer, but I'm not familiar with them or what else might
> be available to install popular F/OSS bits and pieces on that
> operating system, because I
On Sun, Dec 15, 2019 at 10:35:54PM +0100, Fabien COELHO wrote:
>> Also, perhaps I am missing something, but I do not see anyplace in the
>> current code base that ever *clears* CancelRequested.
For bin/scripts/, that's not really a problem, because all code paths
triggering a cancellation, aka in
On Sat, Dec 14, 2019 at 12:35 AM Alvaro Herrera
wrote:
>
> On 2019-Oct-19, Michael Paquier wrote:
>
> > On Thu, Oct 17, 2019 at 02:35:13PM +0900, Michael Paquier wrote:
> > > ArchiveRecoveryRequested will be set to true if recovery.signal or
> > > standby.signal are found, so it seems to me that
At Fri, 13 Dec 2019 18:50:25 -0500, David Steele wrote in
> On 12/13/19 3:56 AM, Magnus Hagander wrote:
> > On Fri, Dec 13, 2019 at 9:00 AM Michael Paquier > think that's a bad idea to put a restriction of this kind. There
> > are large consumers of 2PC, and everybody needs backups.
> >
On Wed, Nov 27, 2019 at 10:38 AM Peter Eisentraut
wrote:
> On 2019-11-26 21:39, Thomas Munro wrote:
> > On Fri, Nov 8, 2019 at 12:44 PM Thomas Munro wrote:
> >> The reason for returning an empty string for "C" and "POSIX" is the
> >> following comment for get_collation_actual_version():
> >>
>
Hans Buschmann writes:
> The planner correctly sets the index conditions (knows that the xx_season
> columns are constant), but fails to apply this constantness to the hash
> conditions by discarding a constant column in a hash table.
Yeah. The reason for this behavior is that, after
Hello,
On cfbot.cputube.org, we keep seeing random failures on appveyor (the
CI provider it uses for Windows) in this step:
- appveyor-retry cinst winflexbison
"cinst" is the apt/yum/pkg-like tool from the Chocolatey package
system, but unfortunately its repository is frequently unavailable.
Hello Tom,
My 0.02 €:
Given the rather small number of existing uses of CancelRequested,
I wonder if it wouldn't be a better idea to rename it to cancel_pressed?
I prefer the former because it is more functional (a cancellation has been
requested, however the mean to do so) while "pressed"
On 2019-Dec-15, Tom Lane wrote:
> Robert Haas writes:
> > Being able to get debugging information from
> > failures that happen on those installations that enables us to fix
> > things without having to go through a time-consuming process of
> > guesswork and attempted reproduction is really
I think this would be ready to abstract away behind a few functions that
could always be replaced by something else later...
However on further thought I really think just using a 32-bit float and 32
bits of other bitmaps or counters would be a better approach.
On Sun., Dec. 15, 2019, 14:54
Michael Paquier writes:
> Looked at it already. And yes, I can see the difference. This comes
> from the switch from cancel_pressed to CancelRequested in psql,
> especially PSQLexecWatch() in this case. And actually, now that I
> look at it, I think that we should simply get rid of
Thomas Munro writes:
> On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe wrote:
>> Doesn't that rely on a specific implementation of double precision (IEEE)?
>> I thought that we don't want to limit ourselves to platforms with IEEE
>> floats.
> Just by the way, you might want to read the second
I wrote:
> I have just found out the hard way (cf commits 22864f6e0, 776a2c887)
> that if one uses EXPLAIN with both ANALYZE and VERBOSE selected,
> the output is not the same between force_parallel_mode = off and
> force_parallel_mode = regress. This seems to me to be quite broken;
> what's the
On Sun, Dec 15, 2019 at 10:07:08PM +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2019 at 04:47:35PM -0600, Justin Pryzby wrote:
> > It's related code which I cleaned up before adding new stuff. Not
> > essential,
> > thus separate (0002 should be backpatched).
>
> The issue just causes some
Robert Haas writes:
> On Fri, Dec 13, 2019 at 7:26 AM Peter Eisentraut
>> Are people interested in backtraces on abort()? That was asked for in
>> an earlier thread.
FWIW, I don't have too much of an opinion about abort() yet.
Aren't we covering most of the possible cases for that already?
I
On Fri, Dec 13, 2019 at 04:47:35PM -0600, Justin Pryzby wrote:
> It's related code which I cleaned up before adding new stuff. Not essential,
> thus separate (0002 should be backpatched).
The issue just causes some extra work and that's not a bug, so applied
without a backpatch.
>> The
On 12/11/19 8:49 PM, Tom Lane wrote:
Andrey Lepikhov writes:
During NestLoop execution we have bad corner case: if outer subtree
contains tuples the join node will scan inner subtree even if it does
not return any tuples.
So the first question about corner-case optimizations like this is
29 matches
Mail list logo
