On 11/23/19 5:01 PM, Tom Lane wrote:
I ran into a couple of issues while trying to devise a regression test
illustrating the LISTEN-in-serializable-transaction issue Mark Dilger
reported. The first one is that an isolation test in which we expect
to see a cross-process NOTIFY immediately
On Sat, Nov 23, 2019 at 11:39 PM vignesh C wrote:
> * Copyright (c) 2016-2019, PostgreSQL Global Development Group
While we're talking about copyrights, I noticed while researching
something else that the PHP project recently got rid of all the
copyright years from their files, which is one
I ran into a couple of issues while trying to devise a regression test
illustrating the LISTEN-in-serializable-transaction issue Mark Dilger
reported. The first one is that an isolation test in which we expect
to see a cross-process NOTIFY immediately after a COMMIT turns out to
be not very
On 11/23/19 3:13 AM, Tels wrote:
>
> Without the strong hashes it would be pointless to sign the manifest.
>
>
I guess I must have missed where we are planning to add a cryptographic
signature.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL
On Wed, Nov 20, 2019 at 03:05:46PM +0900, Kyotaro Horiguchi wrote:
> By the way, before finalize this, I'd like to share the result of a
> brief benchmarking.
What non-default settings did you use? Please give the output of this or a
similar command:
select name, setting from pg_settings
I think that rl_insert_text and friends can probably only be used from
readline callback functions. So in principle maybe you could make it
work by having an rl_startup_hook that injects text if there is any
to inject. There would remain the issues of (a) is it portable across
a wide range
Mark Dilger writes:
> On 11/23/19 8:34 AM, Tom Lane wrote:
>> It suddenly strikes me to worry that we have an XID wraparound hazard
>> for entries in the notify queue.
> Is it worth checking for this condition in autovacuum?
Dunno, maybe. It's a different avenue to consider, at least.
> There
On 11/23/19 8:34 AM, Tom Lane wrote:
In connection with a different issue, I wrote:
* The point of calling asyncQueueReadAllNotifications in
Exec_ListenPreCommit is to advance over already-committed queue entries
before we start sending any events to the client. Without this, a
On Fri, Nov 22, 2019 at 2:12 AM Tom Lane wrote:
>
> Thomas Munro writes:
> > I'd like to get rid of those IDENTIFICATION lines completely (they are
> > left over from the time when the project used CVS, and that section
> > had a $Header$ "ident" tag, but in the git era, those ident tags are
> >
On Fri, Nov 22, 2019 at 01:21:31PM +0100, Peter Eisentraut wrote:
> On 2019-11-05 22:16, Robert Haas wrote:
> >First, I'd like to restate my understanding of the problem just to see
> >whether I've got the right idea and whether we're all on the same
> >page. When wal_level=minimal, we sometimes
In connection with a different issue, I wrote:
> * The point of calling asyncQueueReadAllNotifications in
> Exec_ListenPreCommit is to advance over already-committed queue entries
> before we start sending any events to the client. Without this, a
> newly-listening client could be sent some very
On 2019-Nov-23, Tom Lane wrote:
> I had occasion to try to use errbacktrace() just now, and it blew up
> on me. Investigation finds this:
>
> int
> errbacktrace(void)
> {
> ErrorData *edata = [errordata_stack_depth];
> MemoryContext oldcontext;
>
> Assert(false);
>
>
> I
Alvaro Herrera writes:
> On 2019-Oct-26, Peter Eisentraut wrote:
>> I hadn't realized that you had already attached a patch that implements
>> your idea. It looks good to me. Maybe a small comment near
>> check_backtrace_functions() why we're not using a regular list. Other
>> than that,
Mark Dilger writes:
> On 11/22/19 3:25 PM, Tom Lane wrote:
>> An alternative idea is to use some other way of getting a snapshot
>> in asyncQueueReadAllNotifications, one that always gets a current
>> snapshot and doesn't enter predicate.c. But that might have semantic
>> consequences on the
On 11/22/19 3:07 AM, Michael Paquier wrote:
> On Wed, Nov 20, 2019 at 02:30:12PM -0500, Joe Conway wrote:
>> I tested this successfully on Rhinoceros, both with and without
>> "db_table: { truncate }" loaded in the policy. Updated patches attached
>> here with some editorialization. If there are
On Fri, Nov 22, 2019 at 8:04 AM matsumura@fujitsu.com <
matsumura@fujitsu.com> wrote:
> Hi all
>
> I find a situation that WAL archive file is lost but any WAL segment file
> is not lost.
> It causes for archive recovery to fail. Is this behavior a bug?
>
> example:
>
> WAL segment
On Fri, Nov 22, 2019 at 3:16 PM vignesh C wrote:
>
> Thanks for fixing the comments. The changes looks fine to me. I have
> fixed the first comment, attached patch has the changes for the same.
>
Few comments:
--
1. There is a lot of duplicate code in this test.
On 11/22/19 10:58 PM, Ranier Vilela wrote:
Remove redutant test.
Yeah, this test does look redundant since we already check for if parent
is NULL earlier in the function. Any optimizing compiler should see this
too, but it is still a good idea to remove it for code clarity.
Andreas
Moin,
On 2019-11-22 23:30, David Steele wrote:
On 11/22/19 5:15 PM, Tels wrote:
On 2019-11-22 20:01, Robert Haas wrote:
On Fri, Nov 22, 2019 at 1:10 PM David Steele
wrote:
> Phrased more positively, if you want a cryptographic hash
> at all, you should probably use one that isn't widely
19 matches
Mail list logo
