Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

On Mon, Jul 25, 2016 at 2:38 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > Yeah, thanks, pushed. However this doesn't explain all the failures we see: I missed those ones, thanks for the reminder. > 1) In >

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

Michael Paquier wrote: > Lately hamster is failing every 4/5 days on the recovery regression > tests in 003 covering the recovery targets, with that: > # Postmaster PID for node "standby_2" is 20510 > # > Timed out while waiting for standby to catch up at > t/003_recovery_targets.pl line 36. > >

Re: [HACKERS] Problem in PostgresSQL Configuration with YII 1 & Wordpress

On 24 July 2016 at 02:20, Jyoti Sharma wrote: > Hi Team, > > Currently we have a project running with MySQL with YII & Wordpress, Now i > want to change the Database from MYSQL to PostgreSQL. > Hi. The pgsql-hackers mailing list is for development of PostgreSQL its

[HACKERS] Increasing timeout of poll_query_until for TAP tests

Hi all, Lately hamster is failing every 4/5 days on the recovery regression tests in 003 covering the recovery targets, with that: # Postmaster PID for node "standby_2" is 20510 # Timed out while waiting for standby to catch up at t/003_recovery_targets.pl line 36. Which means that

Re: [HACKERS] Constraint merge and not valid status

Hello, At Fri, 22 Jul 2016 17:35:48 +0900, Amit Langote wrote in <9733fae3-c32f-b150-e368-a8f87d546...@lab.ntt.co.jp> > On 2016/07/22 17:06, Kyotaro HORIGUCHI wrote: > > At Fri, 22 Jul 2016 14:10:48 +0900, Amit Langote wrote: > >> On 2016/07/22 0:38, Robert Haas

Re: [HACKERS] LWLocks in DSM memory

On Mon, Jul 25, 2016 at 3:02 PM, Thomas Munro wrote: > I measured the following times for unpatched master, on my 4 core laptop: > > 16 workers = 73.067s, 74.869s, 75.338s > 8 workers = 65.846s, 67.622s, 68.039s > 4 workers = 68.763s, 68.980s, 69.035s <--

Re: [HACKERS] LWLocks in DSM memory

On Sun, Jul 24, 2016 at 1:10 AM, Thomas Munro wrote: > One solution could be to provide a non-circular variant of the dlist > interface that uses NULL list termination. I've attached a quick > sketch of something like that which seems to work correctly. It is >

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Andrew Borodin wrote: > >If a feature changes the shape of WAL records, XLOG_PAGE_MAGIC is bumped to > >prevent any problems. > I've attached patch with a bump, but, obviously, it'll be irrelevant > after any other commit changing WAL shape. > > Here is a patch with updated GiST README. > I

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Michael Paquier writes: > On Sun, Jul 24, 2016 at 7:18 PM, Andrew Borodin wrote: >> I've attached patch with a bump, but, obviously, it'll be irrelevant >> after any other commit changing WAL shape. > Usually the committer in charge of reviewing

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Amit Kapila writes: > On Fri, Jul 22, 2016 at 4:32 AM, Tom Lane wrote: >> The problem is that exec_stmt_dynexecute() loses control to the error >> thrown from the bogus command, and therefore leaks its "querystr" local >> variable --- which is not

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Sun, Jul 24, 2016 at 12:40 PM, Amit Kapila wrote: > In short, why do you think > it is better to create a new context rather than using "SPI Exec"? > I think life span of the memory allocated from "SPI Exec" is only within "Executor", and after that SPI_Exec will be

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

On Sun, Jul 24, 2016 at 7:18 PM, Andrew Borodin wrote: >>If a feature changes the shape of WAL records, XLOG_PAGE_MAGIC is bumped to >>prevent any problems. > > I've attached patch with a bump, but, obviously, it'll be irrelevant > after any other commit changing WAL shape.

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

>If a feature changes the shape of WAL records, XLOG_PAGE_MAGIC is bumped to >prevent any problems. I've attached patch with a bump, but, obviously, it'll be irrelevant after any other commit changing WAL shape. Here is a patch with updated GiST README. I haven't found apropriate place to

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On Fri, Jul 22, 2016 at 4:32 AM, Tom Lane wrote: > In > https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com > it was pointed out that you could get an intra-function-call memory leak > from something like > > LOOP > BEGIN >