Re: [HACKERS] safer node casting

On Sat, Dec 31, 2016 at 11:30 PM, Tom Lane wrote: > Peter Eisentraut writes: >> I propose a macro castNode() that combines the assertion and the cast, >> so this would become >> RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc)); >

Re: [HACKERS] proposal: session server side variables

On 1 Jan. 2017 20:03, "Fabien COELHO" wrote: What if setup_user() succeeds as a function but the transaction it belongs to fails for some reason (eg deferred constraints, other operation related to setting user up but outside of this function fails, there is replication

Re: [HACKERS] Logical Replication WIP

On 12/30/2016 05:53 AM, Petr Jelinek wrote: Hi, I rebased this for the changes made to inheritance and merged in the fixes that I previously sent separately. I'm not sure if the following is expected or not I have 1 publisher and 1 subscriber. I then do pg_dump on my subscriber ./pg_dump

Re: [HACKERS] Cache Hash Index meta page.

On Tue, Dec 27, 2016 at 1:36 PM, Mithun Cy wrote: > On Thu, Dec 22, 2016 at 12:17 PM, Amit Kapila wrote: >> On Wed, Dec 21, 2016 at 9:26 PM, Robert Haas wrote: >>> On Tue, Dec 20, 2016 at 2:25 PM, Mithun Cy

Re: [HACKERS] Odd behavior with PG_TRY

On Mon, Jan 2, 2017 at 11:14 AM, Jim Nasby wrote: > In the attached patch (snippet below), I'm seeing something strange with > args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things > in lldb just fine: > > (lldb) call args->in.r.atts[0].func >

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Thu, Dec 29, 2016 at 4:50 AM, Alvaro Herrera wrote: > Pursuant to my comments at > https://www.postgresql.org/message-id/20161223192245.hx4rbrxbrwtgwj6i@alvherre.pgsql > and because of a stupid bug I found in my indirect indexes patch, I > rewrote (read: removed)

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila wrote: > > I think there is some chance that such a change could induce > regression for the cases when there are many index columns or I think > even when index is on multiple columns (consider index is on first and > eight

Re: [HACKERS] proposal: session server side variables

2017-01-02 3:06 GMT+01:00 Craig Ringer : > > > On 1 Jan. 2017 20:03, "Fabien COELHO" wrote: > > > > What if setup_user() succeeds as a function but the transaction it belongs > to fails for some reason (eg deferred constraints, other operation related

[HACKERS] Odd behavior with PG_TRY

In the attached patch (snippet below), I'm seeing something strange with args->in.r.atts[]. Prior to entering the PG_TRY block, I can inspect things in lldb just fine: (lldb) call args->in.r.atts[0].func (PLyDatumToObFunc) $49 = 0x00010fc4dc70 (plpython3.so`PLyString_FromDatum at

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Sat, Dec 31, 2016 at 2:52 AM, Thomas Munro wrote: > Unfortunately it's been a bit trickier than I anticipated to get the > interprocess batch file sharing and hash table shrinking working > correctly and I don't yet have a new patch in good enough shape to > post

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee wrote: > > > On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila wrote: >> >> >> I think there is some chance that such a change could induce >> regression for the cases when there are many index columns or

Re: [HACKERS] Fixing pgbench's logging of transaction timestamps

Fabien COELHO writes: >> 3. Forget about using the instr_time result and just have doLog() execute >> gettimeofday() to obtain the timestamp to print. This is kind of >> conceptually ugly, but realistically the added overhead is probably >> insignificant. A larger objection

Re: [HACKERS] Proposal for changes to recovery.conf API

On 20 December 2016 at 15:11, Simon Riggs wrote: > On 20 December 2016 at 15:03, Fujii Masao wrote: > >> API for crash recovery will never be changed. That is, crash recovery needs >> neither recovery.trigger nor standby.trigger. When the server

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Mon, Jan 2, 2017 at 10:17 AM, Amit Kapila wrote: > On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee > wrote: > > > > > > On Mon, Jan 2, 2017 at 8:52 AM, Amit Kapila > wrote: > >> > >> > >> I think there is some chance

Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey

On Mon, Jan 2, 2017 at 10:59 AM, Pavan Deolasee wrote: > > On Mon, Jan 2, 2017 at 10:17 AM, Amit Kapila > wrote: >> >> On Mon, Jan 2, 2017 at 9:28 AM, Pavan Deolasee >> wrote: >> > >> > >> > On Mon, Jan 2, 2017 at 8:52

[HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE

Hi hackers, Here is a small patch to add a test exercising SERIALIZABLE READ ONLY DEFERRABLE. It shows a well known example of a serialisation anomaly caused by a read-only transaction under REPEATABLE READ (snapshot isolation), then shows the different ways that SERIALIZABLE and SERIALIZABLE

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Sun, Jan 1, 2017 at 12:34 PM, David Fetter wrote: > I've rolled your patches into this next one and clarified the commit > message, as there appears to have been some confusion about the scope. Not all the comments have been considered! Here are some example.. =# set

Re: [HACKERS] proposal: session server side variables

Hello Craig, and happy new year, Someone asked me off-list what use cases such a thing would have, since it seems not to be spelled out very clearly in this discussion. I think we're all assuming knowledge here. So. * Session starts * app does SELECT setup_user('user-auth-key-data',

Re: [HACKERS] proposal: session server side variables

Hello Pavel, and Happy new year! (1) Having some kind of variable, especially in interactive mode, allows to manipulate previous results and reuse them later, without having to resort to repeated sub-queries or to retype non trivial values. Client side psql :-variables are untyped and

Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG

Hi Ideriha-san, > I created a patch. Thank you. Would it be possible for you to re-create the patch without the white-space changes? > I marked [WIP] to the title because some documentation is lacked and > format needs some fixing. I noticed that the docs say the statement is a PostgreSQL

Re: [HACKERS] Fixing pgbench's logging of transaction timestamps

Hello and happy new year, -l [...] My 0.02€: There are at least three ways we could fix it: 1. Switch over to printing the timestamp in the form of elapsed seconds since the pgbench run start, [...] About the only reason I can see for liking the current definition is that it makes it

Re: [HACKERS] merging some features from plpgsql2 project

Hi I wrote some initial patch Do you think so has sense to continue in this topic? Regards Pavel diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 77e7440..15b867fa 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -3616,6 +3616,24 @@

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 12/30/16 9:57 AM, Stephen Frost wrote: > Additionally, people who are actually using these bits of the system are > almost certainly going to have to adjust things for the directory > change, Some *xlog* functions are commonly used to measure replay lag. That usage would not be affected by

Re: [HACKERS] proposal: session server side variables

2017-01-01 11:28 GMT+01:00 Fabien COELHO : > > Hello Pavel, and Happy new year! > > (1) Having some kind of variable, especially in interactive mode, allows to >>> manipulate previous results and reuse them later, without having to > resort to repeated sub-queries or

Re: [HACKERS] Commit fest 2017-01 will begin soon!

Em sáb, 31 de dez de 2016 às 21:52, Michael Paquier < michael.paqu...@gmail.com> escreveu: > On Tue, Dec 27, 2016 at 12:41 PM, Michael Paquier > > wrote: > > > There are still a couple of days to register patches! So if you don't > > > want your fancy feature to be