Re: [HACKERS] autonomous transactions

On 3 Sep. 2016 20:27, "Greg Stark" wrote: > > Well using a separate process also requires rewriting locking and > deadlock detection since a reasonable user might expect that second > process to have access to data locked in their current transaction. The user is going to hit

Re: [HACKERS] LSN as a recovery target

On Sun, Sep 4, 2016 at 8:05 AM, Michael Paquier wrote: > On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote: >> On 24 August 2016 at 05:50, Michael Paquier >> wrote: >> > Everything else looks in good order. >> >>

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

Andrew Dunstan writes: > OK, did that. Here is a patch that is undocumented but I think is > otherwise complete. It's been tested a bit and we haven't been able to > break it. Comments welcome. Got around to looking at this. Attached is a revised version that I think is

Re: [HACKERS] Long options for pg_ctl waiting

On Sun, Sep 4, 2016 at 5:57 AM, Vik Fearing wrote: > One thing that has been irking me ever since I came to PostgreSQL is the > fact that pg_ctl -w (and -W) don't have longhand equivalents. I like to > use the long version in scripts and such as extra documentation, and >

Re: [HACKERS] LSN as a recovery target

On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote: > On 24 August 2016 at 05:50, Michael Paquier wrote: > Everything else looks in good order. > > Committed. Thanks. Thanks for the commit! -- Michael -- Sent via pgsql-hackers mailing

Re: [HACKERS] sequence data type

On 04/09/16 06:41, Vik Fearing wrote: On 08/31/2016 06:22 AM, Peter Eisentraut wrote: Here is a patch that adds the notion of a data type to a sequence. So it might be CREATE SEQUENCE foo AS integer. The types are restricted to int{2,4,8} as now. This patch does not apply cleanly to current

Re: [HACKERS] autonomous transactions

> On Sep 3, 2016, at 5:25 AM, Greg Stark wrote: > > On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote: >> So doing autonomous transactions inside a single backend doesn't gain >> you very much, yet it is an enormously invasive patch to do it that >> way,

[HACKERS] Long options for pg_ctl waiting

One thing that has been irking me ever since I came to PostgreSQL is the fact that pg_ctl -w (and -W) don't have longhand equivalents. I like to use the long version in scripts and such as extra documentation, and I've never been able to with these. What's more, I keep forgetting that --wait

Re: [HACKERS] [PATCH] Alter or rename enum value

Emre Hasegeli writes: > Other than these, it looks good to me. I am marking it as Ready for > Committer. I started looking at this patch. I'm kind of unhappy with having *both* IF EXISTS and IF NOT EXISTS options on the statement, especially since the locations of those

Re: [HACKERS] \timing interval

I wrote: > Attached is an updated patch that does it like that. Sample output > (generated by forcing specific arguments to PrintTiming): > Time: 0.100 ms > Time: 1.200 ms > Time: 1001.200 ms (00:01.001) > Time: 12001.200 ms (00:12.001) > Time: 60001.200 ms (01:00.001) > Time: 720001.200 ms

Re: [HACKERS] Logical Replication WIP

On 03/09/16 18:04, Tom Lane wrote: Petr Jelinek writes: On 02/09/16 22:57, Peter Eisentraut wrote: The new system catalog pg_publication_rel has columns pubid, relid, and does not use the customary column name prefixes. Maybe that is OK here. I can't actually think of

Re: [HACKERS] sequence data type

On 08/31/2016 06:22 AM, Peter Eisentraut wrote: > Here is a patch that adds the notion of a data type to a sequence. So > it might be CREATE SEQUENCE foo AS integer. The types are restricted to > int{2,4,8} as now. This patch does not apply cleanly to current master (=600dc4c). -- Vik Fearing

Re: [HACKERS] (Comment)Bug in CteScanNext

Jim Nasby writes: > In CteScanNext(): > /* >* If we are not at the end of the tuplestore, or are going > backwards, try >* to fetch a tuple from tuplestore. >*/ > eof_tuplestore = tuplestore_ateof(tuplestorestate); > if

Re: [HACKERS] [sqlsmith] Failed assertion in numeric aggregate

Andreas Seltenreich writes: > Digging in the coredumps, it looks like set_var_from_num() is invoked on > an uninitialized NumericVar. Sample gdb session below. Hm, yeah, looks like numeric_poly_deserialize is missing a required init_var() step. Slightly astonishing that

Re: [HACKERS] INSERT .. SET syntax

On 08/31/2016 04:12 PM, Marko Tiikkaja wrote: > Hello hello, > > Here's a rebased and updated patch for $SUBJECT for the September commit > fest. Review: This patch is pretty straightforward, using mostly already existing infrastructure. I tried to break it in various ways and could not. I do

Re: [HACKERS] LSN as a recovery target

On 24 August 2016 at 05:50, Michael Paquier wrote: >>> Everything else looks in good order. Committed. Thanks. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] Index Onlys Scan for expressions

Ildar>The reason why this doesn't work is that '~~' operator (which is a Ildar>synonym for 'like') isn't supported by operator class for btree. Since Ildar>the only operators supported by btree are <, <=, =, >=, >, you can use Ildar>it with queries like: Ildar>And in 3rd query 'OFFSET' statement

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

"Daniel Verite" writes: > Rushabh Lathia wrote: >> so its good to have all the set variable related checks inside >> SetVariable(). > There's already another way to skip the \set check: > select 'on' as "AUTOCOMMIT" \gset Hmm, that might be a bug.

Re: [HACKERS] Logical Replication WIP

Petr Jelinek writes: > On 02/09/16 22:57, Peter Eisentraut wrote: >> The new system catalog pg_publication_rel has columns pubid, relid, >> and does not use the customary column name prefixes. Maybe that is OK >> here. I can't actually think of a naming scheme that

Re: [HACKERS] pg_hba_file_settings view patch

On 15 August 2016 at 12:17, Haribabu Kommi wrote: > comments? This looks like a good feature contribution, thanks. At present the patch doesn't apply cleanly, please rebase. The patch doesn't contain any tests, which means I can't see what the output looks like, so I

Re: [HACKERS] pg_basebackup stream xlog to tar

On Thu, Sep 1, 2016 at 2:39 PM, Michael Paquier wrote: > On Thu, Sep 1, 2016 at 5:13 PM, Magnus Hagander > wrote: > > We don't seem to check for similar issues as the one just found in the > > existing tests though, do we? As in, we don't actually

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 10:26 PM, Magnus Hagander wrote: > Yes, we should definitely not allow that combination. In fact, maybe that > argument in itself is enough not to have it for pg_receivexlog -- the cause > of confusion. > > I can see how you might want to avoid it for

Re: [HACKERS] Speedup twophase transactions

On Fri, Sep 2, 2016 at 5:06 AM, Simon Riggs wrote: > On 13 April 2016 at 15:31, Stas Kelvich wrote: > >> Fixed patch attached. There already was infrastructure to skip currently >> held locks during replay of standby_redo() and I’ve extended that

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 3:21 PM, Michael Paquier wrote: > On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander > wrote: > > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > >> On Fri, Sep 2, 2016 at 2:20 AM,

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 10:22 PM, Michael Paquier wrote: > On Sat, Sep 3, 2016 at 10:21 PM, Michael Paquier > wrote: >> Oh, well. I have just implemented it on top of the two other patches >> for pg_basebackup. For pg_receivexlog, I am

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 10:21 PM, Michael Paquier wrote: > On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander wrote: >> On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier >> wrote: >>> On Fri, Sep 2, 2016 at 2:20 AM, Peter

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Sat, Sep 3, 2016 at 12:42 AM, Magnus Hagander wrote: > On Fri, Sep 2, 2016 at 8:50 AM, Michael Paquier > wrote: >> On Fri, Sep 2, 2016 at 2:20 AM, Peter Eisentraut >> wrote: >> > On 5/13/16 2:39 AM, Michael

[HACKERS] [sqlsmith] Failed assertion in numeric aggregate

Hi, updating master from be7f7ee..39b691f, the following assertion is triggered frequently by sqlsmith: TRAP: BadArgument("!(((context) != ((void *)0) && (const Node*)((context)))->type) == T_AllocSetContext", File: "mcxt.c", Line: 1010) Digging in the coredumps, it looks like

Re: [HACKERS] autonomous transactions

On Sat, Sep 3, 2016 at 12:09 PM, Simon Riggs wrote: > So doing autonomous transactions inside a single backend doesn't gain > you very much, yet it is an enormously invasive patch to do it that > way, not least because it requires you to rewrite locking and > deadlocks to

Re: [HACKERS] Index Onlys Scan for expressions

Hi Ildar, I've looked at this patch again today to do a bit more thorough review, and I think it's fine. There are a few comments (particularly in the new code in check_index_only) that need improving, and also a few small tweaks in the walkers. Attached is a modified v5 patch with the

Re: [HACKERS] autonomous transactions

On 2 September 2016 at 09:45, Robert Haas wrote: > On Wed, Aug 31, 2016 at 7:20 AM, Peter Eisentraut > wrote: >> I would like to propose the attached patch implementing autonomous >> transactions for discussion and review. > > I'm pretty

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

Rushabh Lathia wrote: > It might happen that SetVariable() can be called from other places in > future, > so its good to have all the set variable related checks inside > SetVariable(). There's already another way to skip the \set check: select 'on' as "AUTOCOMMIT" \gset But there's a

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

Rahila Syed wrote: > >Above error coming because in below code block change, you don't have > check for > >command (you should check opt0 for AUTOCOMMIT command) > Corrected in the attached. There are other values than ON: true/yes and theirs abbreviations, the value 1, and anything

Re: [HACKERS] Logical Replication WIP

On 02/09/16 22:57, Peter Eisentraut wrote: Review of 0001-Add-PUBLICATION-catalogs-and-DDL.patch: Thanks! The new system catalog pg_publication_rel has columns pubid, relid, and does not use the customary column name prefixes. Maybe that is OK here. I can't actually think of a naming

Re: [HACKERS] standalone backend PANICs during recovery

Bernd Helmle writes: > Well, the "use case" was a crashed hot standby at a customer site (it kept > PANICing after restarting), where i decided to have a look through the > recovery process with gdb. The exact PANIC was > 2016-03-29 15:12:40 CEST [16097]: [26-1]