On Thu, Apr 20, 2017 at 9:31 AM, Kyotaro HORIGUCHI
wrote:
> Ok, I got the point.
>
> At Wed, 19 Apr 2017 17:39:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170419.173901.16598616.horiguchi.kyot...@lab.ntt.co.jp>
>> > >> |
>> > >> | Quorum-based synchronous replicati
On April 23, 2017 10:31:18 PM PDT, Petr Jelinek
wrote:
>On 24/04/17 04:31, Petr Jelinek wrote:
>So actually maybe running regression tests through it might be
>reasonable approach if we add new make target for it.
That sounds like a good plan.
>Note that the first patch is huge. That's becau
Here I attached a small patch that adds the build support for
visual studio 2017.
The tools version number is still 14.X, irrespective of VS 2017
version of 15.0. I modified the versions accordingly.
Regards,
Hari Babu
Fujitsu Australia
vs2017_build_support.patch
Description: Binary data
--
S
For reference this has been asked, and eventually answered on -general at:
https://www.postgresql.org/message-id/flat/CAKFQuwZDS7nA0SvVnumwjHBxz4CWKQm3bVNTHVeWdtAW_oXNJg%40mail.gmail.com#cakfquwzds7na0svvnumwjhbxz4cwkqm3bvnthvewdtaw_ox...@mail.gmail.com
Further comments below; partly a rehash of
On 04/23/2017 10:33 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> AFAICT, unlike the pg_regress checks, which in the installcheck case run
>> against a running instance of postgres, for TAP tests the only
>> difference is that that for the check case a temp install is done,
>> possibly with so
Thomas Munro writes:
> On Sun, Apr 23, 2017 at 6:01 PM, Tom Lane wrote:
>> Fair enough. But I'd still like an explanation of why only about
>> half of the population is showing a failure here. Seems like every
>> machine should be seeing the LSN as moving backwards in this test.
>> So (a) why a
On Mon, Apr 24, 2017 at 10:03 AM, Vitaly Burovoy
wrote:
> On 4/23/17, Robert Haas wrote:
>> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
>> wrote:
>> But why do we need it? Instead of:
>>
>> ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
>> SET GENERATED { ALWAYS | BY DEFAULT }
>> DROP I
On Sun, Apr 23, 2017 at 10:15 AM, Petr Jelinek
wrote:
> On 21/04/17 06:11, Michael Paquier wrote:
>> On Fri, Apr 21, 2017 at 12:29 AM, Peter Eisentraut
>> wrote:
>> Hmm. I have been actually looking at this solution and I am having
>> doubts regarding its robustness. In short this would need to b
Andrew Dunstan writes:
> AFAICT, unlike the pg_regress checks, which in the installcheck case run
> against a running instance of postgres, for TAP tests the only
> difference is that that for the check case a temp install is done,
> possibly with some extra contrib modules. Is that correct? If is
On 2017-04-24 04:27:58 +0200, Petr Jelinek wrote:
> On 24/04/17 01:43, Andres Freund wrote:
> >
> >> BTW while looking at the code, I don't understand why we call
> >> latch_sigusr1_handler after calling SetLatch(MyLatch), shouldn't just
> >> the SetLatch be enough (they both end up calling sendSe
On 2017-04-24 04:26:16 +0200, Petr Jelinek wrote:
> > WalSndLastCycleHandler is genuinely different. WalSndSigHupHandler
> > currently sets a different variable from postgres.c, but that seems like
> > a bad idea, because afaics we'll plainly ignore SIGHUPS unless in
> > WalSndLoop, WalSndWriteData
On 24/04/17 02:04, Andres Freund wrote:
> Hi,
>
> Oh, and one more point: There desperately need to be tests exercising
> "SQL via walsender". Including the issue of parallelism here, the missed
> cancel handler, timeouts, and such. One way to do so is to use
> pg_regress with an adjusted connect
On 24/04/17 01:43, Andres Freund wrote:
>
>> BTW while looking at the code, I don't understand why we call
>> latch_sigusr1_handler after calling SetLatch(MyLatch), shouldn't just
>> the SetLatch be enough (they both end up calling sendSelfPipeByte()
>> eventually)?
>
> Historic raisins - there d
On 24/04/17 01:59, Andres Freund wrote:
> Hi,
>
> On 2017-04-22 17:53:19 +0200, Petr Jelinek wrote:
>> Here is patch. I changed both SIGINT and SIGUSR1 handlers, afaics it
>> does not break anything for existing walsender usage.
>
>> diff --git a/src/backend/replication/logical/launcher.c
>> b/s
On Sat, Apr 22, 2017 at 4:26 AM, Fujii Masao wrote:
> On Fri, Apr 21, 2017 at 4:02 PM, Masahiko Sawada
> wrote:
>> On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote:
>>> On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada
>>> wrote:
On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI
On 4/23/17, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
> wrote:
>> OK. Let's go through it again.
>> IDENTITY is a property of a column. There are no syntax to change any
>> property of any DB object via the "ADD" syntax.
>> Yes, a structure (a sequence) is created. But
On Mon, Apr 24, 2017 at 7:29 AM, Andrew Dunstan
wrote:
>
> AFAICT, unlike the pg_regress checks, which in the installcheck case run
> against a running instance of postgres, for TAP tests the only
> difference is that that for the check case a temp install is done,
> possibly with some extra contr
Hi,
On 2017-04-23 16:59:41 -0700, Andres Freund wrote:
> Hi,
>
> On 2017-04-22 17:53:19 +0200, Petr Jelinek wrote:
> > Here is patch. I changed both SIGINT and SIGUSR1 handlers, afaics it
> > does not break anything for existing walsender usage.
>
> > diff --git a/src/backend/replication/logical
On 2017-04-23 11:31:05 +0900, Michael Paquier wrote:
> Keeping folders in case of failures is something that I have been
> advocating in favor of for some time, but this never got into the tree
> :(
I don't think it'd be ok to do so unless you the randomness of dirnames
is changed as you'd just ac
On Thu, Apr 20, 2017 at 11:34:34PM -0700, Noah Misch wrote:
> On Fri, Apr 21, 2017 at 01:20:05PM +0900, Masahiko Sawada wrote:
> > On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch wrote:
> > > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote:
> > >> On Wed, Apr 19, 2017 at 12:34 PM, Noa
Hi,
On 2017-04-22 17:53:19 +0200, Petr Jelinek wrote:
> Here is patch. I changed both SIGINT and SIGUSR1 handlers, afaics it
> does not break anything for existing walsender usage.
> diff --git a/src/backend/replication/logical/launcher.c
> b/src/backend/replication/logical/launcher.c
> index 76
Noah, all,
On Sun, Apr 23, 2017 at 19:52 Noah Misch wrote:
> On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> > On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > > * Noah Misch (n...@leadboat.com) wrote:
> > > > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Fros
On Sun, Apr 23, 2017 at 10:05 PM, Craig Ringer
wrote:
> On 23 Apr. 2017 10:32, "Michael Paquier" wrote:
> On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote:
>> Skipping the tempdir and instead using ${testname}_data_${name} without a
>> random suffix, we can achieve this with something al
On Sat, Apr 22, 2017 at 01:14:08PM -0700, Noah Misch wrote:
> On Thu, Apr 20, 2017 at 09:53:28PM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote:
> > > > I've put up a new patch for review on the thread and
On 2017-04-21 04:20:26 +0200, Petr Jelinek wrote:
> Looks like SIGUSR1 being different is problem here - it's normally used
> to . I also noticed that we don't handle SIGINT (query cancel).
I think we really need to unify the paths between walsender and normal
backends to a much larger degree.
>
Hi,
On 2017-04-23 11:05:44 +0100, Simon Riggs wrote:
> > Yikes. This is clearly way undertested. It's also pretty scary that
> > the code has recently been whacked out quite heavily (both 9.6 and
> > master), without hitting anything around this - doesn't seem to bode
> > well for how in-depth t
Hi,
On 2017-04-20 17:27:42 -0400, Tom Lane wrote:
> In short: yeah, let's nuke the WAIT_USE_SELECT implementation.
> It's dead code and it's unlikely to get resurrected.
Done.
> BTW, noting that SUSv2 specifies not , I wonder
> whether we couldn't drop configure's test for the latter along wit
On 2017-04-22 21:08:18 +0200, Petr Jelinek wrote:
> On 22/04/17 20:31, Andres Freund wrote:
> > Hi,
> >
> > I enabled skink / the valgrind animal to run the tap tests too (hugely
> > increasing the test time :(), and that paid of:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&d
On Sun, Apr 23, 2017 at 6:01 PM, Tom Lane wrote:
> Thomas Munro writes:
>> On Sun, Apr 23, 2017 at 3:41 AM, Tom Lane wrote:
>>> As for this patch itself, is it reasonable to try to assert that the
>>> timeline has in fact changed?
>
>> The protocol doesn't include the timeline in reply messages,
AFAICT, unlike the pg_regress checks, which in the installcheck case run
against a running instance of postgres, for TAP tests the only
difference is that that for the check case a temp install is done,
possibly with some extra contrib modules. Is that correct? If is is, why
aren't we providing an
On 22/04/17 21:16, Andres Freund wrote:
> Hi,
>
> On 2017-04-22 21:08:18 +0200, Petr Jelinek wrote:
>> Thanks, here is patch to fix that - I also removed the individual
>> settings of everything to NULL/0/InvalidOid etc and just replaced it all
>> with memset.
>
> Cool.
>
>> diff --git a/src/bac
On 23 April 2017 at 18:41, Simon Riggs wrote:
> On 23 April 2017 at 17:17, Tom Lane wrote:
>> Simon Riggs writes:
Also, when I fix that, it gets further but still crashes at the same
Assert in SubTransSetParent. The proximate cause this time seems to be
that RecoverPreparedTransa
Here's a patch that will allow calling vcregress.pl to run a single TAP
test set. It would work like this:
vcregress.pl src/test/recover true
The second argument if true (in the perl sense, of course) would trigger
a temp install before running the tests. It defaults to off, in an
attempt
On Thu, Apr 20, 2017 at 12:05 AM, Vitaly Burovoy
wrote:
>> I am still not fond of this change. There is precedent all over the
>> place for having separate commands for creating a structure, changing a
>> structure, and removing a structure. I don't understand what the
>> problem with that is.
Hello Nikolay,
Hmmm. The pre-existing TAP test in pgbench is about concurrent commits, it
is not to test pgbench itself. Pgbench allows to run some programmable
clients in parallel very easily, which cannot be done simply otherwise. I
think that having it there would encourage such uses.
Sin
2017-04-19 10:05 GMT+02:00 Jan Michálek :
> 2017-04-19 9:18 GMT+02:00 Fabien COELHO :
>
>>
>> I still do not understand "why" this variant vs CommonMark or whatever
other version.
>>>
>>> Because of simply implementation and readability (looks similar to
>>> aligned
>>> format) and it is
Hi Team,
I am using Postgresql 9.5 and I have created backup_admin user and created
dba_admin ROLE with SUPERUSER and REPLICATION ,after that GRANT dba_admin
role to backup_admin user and executed pg_basebakup utility with
backup_admin user.
But I am not able to use the pg_basebackup utility u
On 23 April 2017 at 17:17, Tom Lane wrote:
> Simon Riggs writes:
>>> Also, when I fix that, it gets further but still crashes at the same
>>> Assert in SubTransSetParent. The proximate cause this time seems to be
>>> that RecoverPreparedTransactions's calculation of overwriteOK is wrong:
>>> it'
Simon Riggs writes:
> On 23 April 2017 at 00:55, Tom Lane wrote:
>> It's not clear to me how much potential this has to create user data
>> corruption, but it doesn't look good at first glance. Discuss.
> SubTransSetParent() only matters for the case where we are half-way
> through a commit wit
В письме от 20 апреля 2017 19:14:34 пользователь Fabien COELHO написал:
> >> (1) extends the existing perl tap test infrastructure with methods to
> >> test
> >> pgbench, i.e. "pgbench" which runs a pgbench test and "pgbench_likes"
> >> which allows to check for expectations.
> >
> > I do not thi
Simon Riggs writes:
>> Also, when I fix that, it gets further but still crashes at the same
>> Assert in SubTransSetParent. The proximate cause this time seems to be
>> that RecoverPreparedTransactions's calculation of overwriteOK is wrong:
>> it's computing that as "false", but in reality the su
Michael Banck writes:
> On Sat, Apr 22, 2017 at 02:05:13PM -0700, Andres Freund wrote:
>> Agreed. If paths are reproducible and cleaned up on next run it's also
>> much less of an issue to just leave them around till the next run.
>> Which we imo also should do for non-failing tmp_check directori
On Thu, Apr 20, 2017 at 5:50 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2017-04-20 17:27:42 -0400, Tom Lane wrote:
>>> In short: yeah, let's nuke the WAIT_USE_SELECT implementation.
>>> It's dead code and it's unlikely to get resurrected.
>
>> Ok, cool. v10 or wait till v11? I see very l
On Thu, Apr 20, 2017 at 5:24 PM, Claudio Freire wrote:
>> What's not clear to me is how sensitive the performance of vacuum is
>> to the number of cycles used here. For a large index, the number of
>> searches will presumably be quite large, so it does seem worth
>> worrying about performance. B
On 04/23/2017 04:16 PM, Bruce Momjian wrote:
On Sun, Apr 23, 2017 at 10:01:16AM -0400, Bruce Momjian wrote:
On Sun, Apr 23, 2017 at 11:44:12AM +0100, Simon Riggs wrote:
For us "functional dependency" would sound like something to do with
functions (e.g. CREATE FUNCTION), so just "dependency" ap
On 04/23/2017 12:44 PM, Simon Riggs wrote:
On 23 April 2017 at 09:17, Dean Rasheed wrote:
On 23 April 2017 at 03:37, Bruce Momjian wrote:
In looking at the new multi-column statistics "dependency" option in
Postgres 10, I am quite confused by the term "dependency". Wouldn't
"correlation" be
On Sun, Apr 23, 2017 at 10:01:16AM -0400, Bruce Momjian wrote:
> On Sun, Apr 23, 2017 at 11:44:12AM +0100, Simon Riggs wrote:
> > For us "functional dependency" would sound like something to do with
> > functions (e.g. CREATE FUNCTION), so just "dependency" appears to me
> > to be the best term for
On Sun, Apr 23, 2017 at 11:44:12AM +0100, Simon Riggs wrote:
> For us "functional dependency" would sound like something to do with
> functions (e.g. CREATE FUNCTION), so just "dependency" appears to me
> to be the best term for this.
>
> There are multiple statistics for dependency stored, hence
On 23 Apr. 2017 10:32, "Michael Paquier" wrote:
On Sun, Apr 23, 2017 at 7:48 AM, Daniel Gustafsson wrote:
> Skipping the tempdir and instead using ${testname}_data_${name} without a
> random suffix, we can achieve this with something along the lines of the
> attached PoC. It works as now (retai
On 23 April 2017 at 09:17, Dean Rasheed wrote:
> On 23 April 2017 at 03:37, Bruce Momjian wrote:
>> In looking at the new multi-column statistics "dependency" option in
>> Postgres 10, I am quite confused by the term "dependency". Wouldn't
>> "correlation" be clearer and less confusing as "colum
On 22 April 2017 at 16:41, Tom Lane wrote:
> Thomas Munro writes:
>> The assertion fails reliably for me, because standby2's reported write
>> LSN jumps backwards after the timeline changes: for example I see
>> 302 then 3028470 then 302 followed by a normal progression.
>> Surprisingly,
On 23 April 2017 at 01:19, Andres Freund wrote:
> On 2017-04-22 19:55:18 -0400, Tom Lane wrote:
>> Now that we've got consistent failure reports about the 009_twophase.pl
>> recovery test, I set out to find out why it's failing. It looks to me
>> like the reason is that this (twophase.c:2145):
>>
On 23 April 2017 at 00:55, Tom Lane wrote:
> Now that we've got consistent failure reports about the 009_twophase.pl
> recovery test, I set out to find out why it's failing. It looks to me
> like the reason is that this (twophase.c:2145):
>
> SubTransSetParent(xid, subxid, overwriteOK
On Sat, Apr 22, 2017 at 02:05:13PM -0700, Andres Freund wrote:
> On 2017-04-22 16:22:59 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2017-04-22 13:51:30 -0400, Tom Lane wrote:
> > >> I think we need to fix TestLib and/or PostgresNode so that there's a way
> > >> to make TAP tests not
On 23 April 2017 at 03:37, Bruce Momjian wrote:
> In looking at the new multi-column statistics "dependency" option in
> Postgres 10, I am quite confused by the term "dependency". Wouldn't
> "correlation" be clearer and less confusing as "column dependency"
> already means something else.
>
Actu
On 04/22/2017 04:43 PM, Andrew Dunstan wrote:
> After we got over the Test::More version issue, the recovery tests
> proceeded to fail fairly spectacularly in a test run on jacana.
>
>
> Test 6 fails because there is a CR in the returned stdout from psql. I'm
> inclined to adjust that in Postgres
56 matches
Mail list logo
