Re: [HACKERS] PL/pgSQL, RAISE and error context

2013/8/22 Marko Tiikkaja > On 8/22/13 9:08 AM, Pavel Stehule wrote: > >> Probably we can introduce a new level of verbosity, but I am thinking so >> this behave is reasonable. Everybody who use a VERBOSE level expect lot of >> balast and it show expected info (context of error) >> >> Can be this

Re: [HACKERS] Does larger i/o size make sense?

The big-picture problem with work in this area is that no matter how you do it, any benefit is likely to be both platform- and workload-specific. So the prospects for getting a patch accepted aren't all that bright. Indeed. Would it make sense to have something easier to configure that recomp

Re: [HACKERS] Does larger i/o size make sense?

2013/8/23 Tom Lane : > Merlin Moncure writes: >> On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai wrote: >>> An idea that I'd like to investigate is, PostgreSQL allocates a set of >>> continuous buffers to fit larger i/o size when block is referenced due to >>> sequential scan, then invokes consolid

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 22, 2013 at 9:34 PM, Bruce Momjian wrote: > On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote: >> * Amit Kapila (amit.kapil...@gmail.com) wrote: >> >This can resolve the problem of whether to read auto file rather >> > cleanly, so the idea is: >> > >> > Enable/Disable r

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: >>This can resolve the problem of whether to read auto file rather >> cleanly, so the idea is: >> >> Enable/Disable reading of auto file >> ---

Re: [HACKERS] PL/pgSQL PERFORM with CTE

2013/8/23 Josh Berkus > Tom, > > > > Jan might remember more about his thought process here, but I'm thinking > > that he copied the SELECT-must-have-INTO rule and then chose to invent > > a new statement for the case of wanting to discard the result. I think > > you could make an argument for t

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Tom, > Jan might remember more about his thought process here, but I'm thinking > that he copied the SELECT-must-have-INTO rule and then chose to invent > a new statement for the case of wanting to discard the result. I think > you could make an argument for that being good from an oversight-det

Re: [HACKERS] PL/pgSQL PERFORM with CTE

Josh Berkus writes: > I have to agree with Merlin. I've always thought the PERFORM thing was > a wart we'd get around to removing eventually. In what way is it a feature? I'd always assumed it was a PL/SQL compatibility thing, but a look in a PL/SQL reference doesn't turn up any such statement.

Re: [HACKERS] PL/pgSQL PERFORM with CTE

On 08/20/2013 05:48 AM, Merlin Moncure wrote: > On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule > wrote: >> >> >> >> 2013/8/20 Merlin Moncure >>> >>> On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund >>> I think the way forward is to remove the restriction such that data >>> returning queries must

Re: [HACKERS] System catalog vacuum issues

On Wed, Aug 21, 2013 at 2:33 PM, Jim Nasby wrote: >> That is the problem. Exactly what Jim was writing about. Autovacuum >> have no chance to clean dead tuples at the end of the table because >> they are created too intensively. In the latest versions autovacuum >> behaves so it would stop working

Re: [HACKERS] Does larger i/o size make sense?

Merlin Moncure writes: > On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai wrote: >> An idea that I'd like to investigate is, PostgreSQL allocates a set of >> continuous buffers to fit larger i/o size when block is referenced due to >> sequential scan, then invokes consolidated i/o request on the buf

Re: [HACKERS] Does larger i/o size make sense?

On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai wrote: > Hello, > > A few days before, I got a question as described in the subject line on > a discussion with my colleague. > > In general, larger i/o size per system call gives us wider bandwidth on > sequential read, than multiple system calls with

[HACKERS] Does larger i/o size make sense?

Hello, A few days before, I got a question as described in the subject line on a discussion with my colleague. In general, larger i/o size per system call gives us wider bandwidth on sequential read, than multiple system calls with smaller i/o size. Probably, people knows this heuristics. On the

Re: [HACKERS] PL/pgSQL, RAISE and error context

2013/8/22 Marko Tiikkaja > On 8/22/13 9:08 AM, Pavel Stehule wrote: > >> Probably we can introduce a new level of verbosity, but I am thinking so >> this behave is reasonable. Everybody who use a VERBOSE level expect lot of >> balast and it show expected info (context of error) >> >> Can be this

Re: [HACKERS] Allow child table to be missing nullable column from parent.

Jeff Janes writes: > Currently a child table has to have all the columns the parent table has: > create table foo1 (x integer, y text, z bool); > create table foo2 (x integer, y text, q text); > alter table foo2 inherit foo1 ; > ERROR: child table is missing column "z" > In theory it seems like

[HACKERS] Allow child table to be missing nullable column from parent.

Currently a child table has to have all the columns the parent table has: create table foo1 (x integer, y text, z bool); create table foo2 (x integer, y text, q text); alter table foo2 inherit foo1 ; ERROR: child table is missing column "z" In theory it seems like this could be allowed as long a

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 12:37:36 -0400, Tom Lane wrote: > Do we have a reliable way of generating a unique identifier for each slave > (independently of how that might be exposed)? I'd like one, but it's not easy. The best I can think of is to mash together: * system_identifier * mac address of primary inte

Re: [HACKERS] pg_system_identifier()

Andres Freund writes: > On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote: >> We could split the value; make sure that the first, way, 96 bits are >> identical in master and slaves (and change the code to only compare >> those bits); but the last 32 bits are system specific and cannot appear >> t

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-08-22 12:06:03 -0400, Tom Lane wrote: > > > > I agree that if we have a function named pg_system_identifier(), it ought > > > to return the same value that pg_controldata prints under that name. > > > But that d

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 12:18:41 -0400, Bruce Momjian wrote: > On Thu, Aug 22, 2013 at 06:18:39PM +0200, Andres Freund wrote: > > But essentially we already have something like that by the combination > > of system identifier and timeline id. Admittedly there's the weakness > > that the timelineid can increa

Re: [HACKERS] pg_system_identifier()

Andres Freund wrote: > On 2013-08-22 12:06:03 -0400, Tom Lane wrote: > > I agree that if we have a function named pg_system_identifier(), it ought > > to return the same value that pg_controldata prints under that name. > > But that doesn't really answer any questions about how that value is > > o

Re: [HACKERS] pg_system_identifier()

On Thu, Aug 22, 2013 at 06:18:39PM +0200, Andres Freund wrote: > But essentially we already have something like that by the combination > of system identifier and timeline id. Admittedly there's the weakness > that the timelineid can increase the same on several machines in the > cluster but that's

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 12:06:03 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-08-22 08:45:38 -0700, Josh Berkus wrote: > >> However, given that the value is the same for all servers in a > >> replication set, are we sure we want to call it system_identifier? Is > >> there a better name? > >

Re: [HACKERS] pg_system_identifier()

Andres Freund writes: > On 2013-08-22 08:45:38 -0700, Josh Berkus wrote: >> However, given that the value is the same for all servers in a >> replication set, are we sure we want to call it system_identifier? Is >> there a better name? > Given it's been named that and visible via pg_controldata

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Thu, Aug 22, 2013 at 08:36:37AM -0400, Stephen Frost wrote: > * Amit Kapila (amit.kapil...@gmail.com) wrote: > >This can resolve the problem of whether to read auto file rather > > cleanly, so the idea is: > > > > Enable/Disable reading of auto file > > -

Re: [HACKERS] pg_system_identifier()

Josh Berkus writes: > Vik's feature would be useful for detecting an accidental split in a > replication cluster. That is, it would be another tool for detecting if > you've made a mistake and created two masters. So +1 from me. We don't change the ID when promoting a slave to master, do we? So

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 08:45:38 -0700, Josh Berkus wrote: > All, > > Vik's feature would be useful for detecting an accidental split in a > replication cluster. That is, it would be another tool for detecting if > you've made a mistake and created two masters. So +1 from me. > > It will also be useful f

Re: [HACKERS] pg_system_identifier()

bricklen writes: > On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund wrote: >> FWIW I've wished for that function repeatedly. Mostly just to make sure >> I am actually connected to the same "network" of replicas and not some >> other. >> It's also useful if you're providing support for a limited numb

Re: [HACKERS] pg_system_identifier()

All, Vik's feature would be useful for detecting an accidental split in a replication cluster. That is, it would be another tool for detecting if you've made a mistake and created two masters. So +1 from me. It will also be useful for me for sharding. Right now, I'm doing a hackish version of

[HACKERS] Hstore: Query speedups with Gin index

Hey everyone, I'm looking for feedback on a contrib/hstore patch. We've been experiencing slow "@>" queries involving an hstore column that's covered by a Gin index. At the current postgresql git HEAD, the hstore <-> gin interface produces the following text items to be indexed: hstore: "'a'=>'1

Re: [HACKERS] pg_system_identifier()

On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund wrote: > > FWIW I've wished for that function repeatedly. Mostly just to make sure > I am actually connected to the same "network" of replicas and not some > other. > It's also useful if you're providing support for a limited number of > machines and

Re: [HACKERS] pg_system_identifier()

On 2013-08-22 21:51:22 +0900, Fujii Masao wrote: > On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote: > > After someone in IRC asked if there was an equivalent to MySQL's > > server_id, it was noted that we do have a system identifier but it's not > > very accessible. > > > > The attached patch i

Re: [HACKERS] PL/pgSQL, RAISE and error context

On 8/22/13 9:08 AM, Pavel Stehule wrote: Probably we can introduce a new level of verbosity, but I am thinking so this behave is reasonable. Everybody who use a VERBOSE level expect lot of balast and it show expected info (context of error) Can be this design good enough for you? I like the id

Re: [HACKERS] Backup throttling

On 2013-08-22 07:39:41 +0200, PostgreSQL - Hans-Jürgen Schönig wrote: > >> regarding the client side implementation: we have chosen this way because > >> it is less invasive. > >> i cannot see a reason to do this on the server side because we won't have > >> 10 > >> pg_basebackup-style tools ma

Re: [HACKERS] pg_system_identifier()

On 08/22/2013 03:21 PM, Fujii Masao wrote: >> > I don't know if that's justification enough, which is >> > why I didn't add it to the commitfest yet. > You can add the patch to CF, and then hear the opinions from other people > during CF. Added. -- Vik -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Backup throttling

On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig wrote: > what would be a reasonable scenario where limiting streaming would make > sense? i cannot think of any to be honest. I tend to agree. If anything we're likely to want the reverse - the ability to throttle WAL *generation* on the m

Re: [HACKERS] proposal: lob conversion functionality

+1 badly need the large object and bytea convert function. Once I have to use the ugly pg_read_file() to put some text to pg,I tried to use large object but find it is useless without function to convert large object to bytea. Jov blog: http:amutu.com/blog 2013/8/10 Pave

Re: [HACKERS] pg_system_identifier()

On Thu, Aug 22, 2013 at 9:53 PM, Vik Fearing wrote: > On 08/22/2013 02:51 PM, Fujii Masao wrote: >> On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote: >>> After someone in IRC asked if there was an equivalent to MySQL's >>> server_id, it was noted that we do have a system identifier but it's not

Re: [HACKERS] StrategyGetBuffer optimization, take 2

On Tue, Aug 20, 2013 at 1:57 AM, Andres Freund wrote: > On 2013-08-19 15:17:44 -0700, Jeff Janes wrote: >> On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure wrote: >> >> > I agree; at least then it's not unambiguously better. if you (in >> > effect) swap all contention on allocation from a lwlock to

Re: [HACKERS] pg_system_identifier()

On 08/22/2013 02:51 PM, Fujii Masao wrote: > On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote: >> After someone in IRC asked if there was an equivalent to MySQL's >> server_id, it was noted that we do have a system identifier but it's not >> very accessible. >> >> The attached patch implements a

Re: [HACKERS] pg_system_identifier()

On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote: > After someone in IRC asked if there was an equivalent to MySQL's > server_id, it was noted that we do have a system identifier but it's not > very accessible. > > The attached patch implements a pg_system_identifier() function that > exposes it

Re: [HACKERS] PL/pgSQL, RAISE and error context

On Thu, Aug 22, 2013 at 2:08 AM, Pavel Stehule wrote: > Probably we can introduce a new level of verbosity, but I am thinking so > this behave is reasonable. Everybody who use a VERBOSE level expect lot of > balast and it show expected info (context of error) > > Can be this design good enough for

Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit.kapil...@gmail.com) wrote: >This can resolve the problem of whether to read auto file rather > cleanly, so the idea is: > > Enable/Disable reading of auto file > - > a. Have a new include in postresql.conf > #include_a

Re: [HACKERS] docbook-xsl version for release builds

On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote: >>> Given that, I'm fine with just bumping the version on borka to that >>> version. Any objections? > >> This was not done for 9.3rc1, AFAICT. Let's please do

Re: [HACKERS] PL/pgSQL, RAISE and error context

Hello I played with this topic little bit If I understand, the main problem is in console (or pgAdmin) output. create or replace function foo() returns void as $$ begin for i in 1..5 loop raise notice '> *'; end loop; raise exception '***'; end; $$ language plpgsq