Re: [HACKERS] Quorum commit for multiple synchronous replication.

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 >

Re: [HACKERS] walsender & parallelism

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

[HACKERS] visual studio 2017 build support

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 --

Re: [HACKERS] pg_basebackup issue

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

Re: [HACKERS] TAP tests - installcheck vs check

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

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

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

Re: [HACKERS] identity columns

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 |

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

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

Re: [HACKERS] TAP tests - installcheck vs check

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

Re: [HACKERS] walsender & parallelism

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

Re: [HACKERS] walsender & parallelism

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,

Re: [HACKERS] walsender & parallelism

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

Re: [HACKERS] walsender & parallelism

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

Re: [HACKERS] walsender & parallelism

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 >>

Re: [HACKERS] some review comments on logical rep code

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

Re: [HACKERS] identity columns

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"

Re: [HACKERS] TAP tests - installcheck vs check

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,

Re: [HACKERS] walsender & parallelism

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

Re: [HACKERS] A note about debugging TAP failures

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

Re: [HACKERS] Quorum commit for multiple synchronous replication.

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,

Re: [HACKERS] walsender & parallelism

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

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

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

Re: [HACKERS] A note about debugging TAP failures

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

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

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

Re: [HACKERS] walsender & parallelism

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.

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

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

Re: [HACKERS] valgrind error in subscription code

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: > >

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

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

[HACKERS] TAP tests - installcheck vs check

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

Re: [HACKERS] valgrind error in subscription code

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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

[HACKERS] vcregress support for single TAP tests

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

Re: [HACKERS] identity columns

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

Re: [HACKERS] pgbench tap tests & minor fixes

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.

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

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

[HACKERS] pg_basebackup issue

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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

Re: [HACKERS] pgbench tap tests & minor fixes

В письме от 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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

Re: [HACKERS] A note about debugging TAP failures

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

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

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,

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

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 >>

Re: Do we need multi-column frequency/histogram stats? WAS Re: [HACKERS] Statistics "dependency"

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"

Re: [HACKERS] Statistics "dependency"

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

Do we need multi-column frequency/histogram stats? WAS Re: [HACKERS] Statistics "dependency"

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

Re: [HACKERS] Statistics "dependency"

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

Re: [HACKERS] A note about debugging TAP failures

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

Re: [HACKERS] Statistics "dependency"

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 >>

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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

Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly

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): > >

Re: [HACKERS] A note about debugging TAP failures

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 > > >>

Re: [HACKERS] Statistics "dependency"

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

Re: [HACKERS] recovery tests vs windows

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

Re: [HACKERS] [COMMITTERS] pgsql: Replication lag tracking for walsenders

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, so