Re: [HACKERS] jsonb_set array append hack?

On 20 September 2015 at 16:17, Dmitry Dolgov <9erthali...@gmail.com> wrote: > I'm sorry, but I'm not sure, what behavior is expected in this case? > Right now the following logic was implemented: > "we trying to set an element inside an array, but we've got a > non-integer path item >

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Mon, Aug 31, 2015 at 9:49 PM, Amit Kapila wrote: > Increasing CLOG buffers to 64 helps in reducing the contention due to second > reason. Experiments revealed that increasing CLOG buffers only helps > once the contention around ProcArrayLock is reduced. There has

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Fri, Sep 18, 2015 at 4:43 PM, Vladimir Borodin wrote: > No, probably you misunderstood the results, let me explain one more time. Yeah, I did, sorry. > Unpatched PostgreSQL from REL9_4_STABLE gave 15500 tps. Version with timings > - 14500 tps which is 6,5% worse. Version

Re: [HACKERS] [BUGS] BUG #12989: pg_size_pretty with negative values

Hi all, Am 06.04.2015 um 20:52 schrieb Tom Lane: > "David G. Johnston" writes: >> I'll let a hacker determine whether this is a bug or a feature request >> though it is a POLA violation in either case. > > I'd say it's a feature request --- a perfectly reasonable

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-18 14:58, Alexander Korotkov wrote: On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev > wrote: validate_opclass was renamed to amvalidate. It seems to me, that amvalidate method of AM should get as argument only Oid of

Re: [HACKERS] WIP: Rework access method interface

On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek wrote: > On 2015-09-18 14:58, Alexander Korotkov wrote: > >> On Wed, Sep 16, 2015 at 8:44 PM, Teodor Sigaev > > wrote: >> >> validate_opclass was renamed to amvalidate. >> >>

Re: [HACKERS] jsonb_set array append hack?

I'm sorry, but I'm not sure, what behavior is expected in this case? Right now the following logic was implemented: "we trying to set an element inside an array, but we've got a non-integer path item ("nonsense" in this particular case), so we're going to add a new element at the end of

Re: [HACKERS] Improving test coverage of extensions with pg_dump

On 17-09-2015 14:21, Michael Paquier wrote: pg_dump relies on attnum to define the column ordering, so one possibility would be to do things more consistently at backend level. Thoughts? According to your example, problem is the columns from the parent table "aa" are added _before_ declaring

Re: [HACKERS] 9.3.9 and pg_multixact corruption

Re: Andreas Seltenreich 2015-09-13 <87si6i1875@credativ.de> > I managed disassemble RecordNewMultiXact from the core dump using a > cross-binutils, and it reveals that the compiler[1] appears to have > indeed generated a signed division here. I'm attaching a piece of C > code that does the

Re: [HACKERS] WIP: Rework access method interface

Petr Jelinek writes: > On 2015-09-18 14:58, Alexander Korotkov wrote: >> After, further personal discussion with Teodor, we decided that >> amvalidate is out of scope for this patch. >> It's not evident what should we validate in amvalidate and which way. I >> think if we

Re: [HACKERS] WIP: Rework access method interface

On 2015-09-20 16:17, Alexander Korotkov wrote: On Sun, Sep 20, 2015 at 5:02 PM, Petr Jelinek

Re: [HACKERS] WIP: Rework access method interface

On Sun, Sep 20, 2015 at 5:18 PM, Tom Lane wrote: > Petr Jelinek writes: > > On 2015-09-18 14:58, Alexander Korotkov wrote: > >> After, further personal discussion with Teodor, we decided that > >> amvalidate is out of scope for this patch. > >> It's not

Re: [HACKERS] creating extension including dependencies

On 2015-09-18 04:52, Petr Jelinek wrote: On 2015-09-17 17:31, Jeff Janes wrote: If I fail to specify CASCADE and get an ERROR, I think there should be a HINT which suggests the use of CASCADE. create extension earthdistance ; ERROR: required extension "cube" is not installed (no hint)

[HACKERS] Limit GIST_MAX_SPLIT_PAGES to XLR_MAX_BLOCK_ID

Gin code respects the XLR_MAX_BLOCK_ID when calling XLogEnsureRecordSpace(). But it appears that the Gist code does not try to limit its block-id consumption to XLR_MAX_BLOCK_ID. The GIST_MAX_SPLIT_PAGES is hard-coded at 75, but XLogEnsureRecordSpace() would reject a request of more than 32

Re: [HACKERS] row_security GUC, BYPASSRLS

Robert Haas writes: > On Sun, Sep 20, 2015 at 5:35 PM, Stephen Frost wrote: >> * Joe Conway (m...@joeconway.com) wrote: >>> That would be awesome, but I would say that if we do #1 & 2 for 9.5, we >>> also need #3. >> Agreed on all of the above. >

Re: [HACKERS] row_security GUC, BYPASSRLS

On Sun, Sep 20, 2015 at 5:35 PM, Stephen Frost wrote: > * Joe Conway (m...@joeconway.com) wrote: >> On 09/18/2015 01:07 AM, Noah Misch wrote: >> > Great. Robert, does that work for you, too? If so, this sub-thread is >> > looking at three patches: >> > >> > 1. remove

Re: [HACKERS] [POC] FETCH limited by bytes.

On Fri, Sep 4, 2015 at 2:45 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > > > > @@ -915,6 +933,23 @@ postgresBeginForeignScan(ForeignScanState *node, > > > int eflags) > ... > > > > + def = get_option(table->options, "fetch_size"); > > > > > I don't think it's a

Re: [HACKERS] row_security GUC, BYPASSRLS

On Mon, Sep 14, 2015 at 03:29:16AM -0400, Noah Misch wrote: > On a related topic, check_enable_rls() has two kinds of RLS bypass semantics. > Under row_security=off|on, superusers bypass every policy, and table owners > bypass policies of their own tables. Under row_security=off only, roles with

Re: [HACKERS] row_security GUC, BYPASSRLS

On Fri, Sep 18, 2015 at 09:27:13AM -0500, Joe Conway wrote: > On 09/18/2015 09:25 AM, Adam Brightwell wrote: > >>> 1. remove row_security=force > >>> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to > >>> policies > >>> 3. add DDL-controlled, per-table policy forcing > >>> >

Re: [HACKERS] row_security GUC, BYPASSRLS

* Joe Conway (m...@joeconway.com) wrote: > On 09/18/2015 01:07 AM, Noah Misch wrote: > > Great. Robert, does that work for you, too? If so, this sub-thread is > > looking at three patches: > > > > 1. remove row_security=force > > 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject

Re: [HACKERS] CREATE POLICY and RETURNING

Zhaomo, * Zhaomo Yang (zmp...@gmail.com) wrote: > > I agree that if we force a single visibility policy for all commands > > then we wouldn't need the USING clauses for UPDATE and DELETE, but we > > would certainly need *some* policy for DELETE to prevent users from > > being able to delete

Re: [HACKERS] RemoveLocalLock pfree'ing NULL when out-of-memory

Andreas Seltenreich writes: > a memory-starved instance of sqlsmith just caught RemoveLocalLock > pfree'ing a NULL in locallock->lockOwners. I think what happened is > that it was called to clean up after LockAcquireExtended's > MemoryContextAlloc failed. The content of

[HACKERS] RemoveLocalLock pfree'ing NULL when out-of-memory

Hi, a memory-starved instance of sqlsmith just caught RemoveLocalLock pfree'ing a NULL in locallock->lockOwners. I think what happened is that it was called to clean up after LockAcquireExtended's MemoryContextAlloc failed. The content of errordata seems consistent with this. Caught in master