On 08/21/2013 10:06 PM, Noah Misch wrote:
I concur, but our field experience doing it this way lessens my concern.
I see this change has hit master. I've pulled in the new patch for the
Fedora MinGW package.
Thanks,
Michael
--
Sent via pgsql-hackers mailing list
rebased
Regards
Pavel
2013/8/22 Peter Eisentraut pete...@gmx.net
On Wed, 2013-03-27 at 23:25 +0100, Pavel Stehule wrote:
I redesigned output from plpgsql_check_function. Now, it returns table
everytime.
Litlle bit code simplification.
This patch is in the 2013-09 commitfest but needs
On 8/12/13 1:08 PM, Pavel Stehule wrote:
IF (bytes != LENGTH($1)) THEN
RAISE EXCEPTION 'Not all data copied to blob';
END IF;
PERFORM lo_close(fd);
FWIW, it's probably better to close before raising the exception...
--
Jim C. Nasby, Data Architect
On 8/19/13 7:23 PM, Sergey Konoplev wrote:
On Thu, Aug 15, 2013 at 7:03 PM, Vlad Arkhipovarhi...@dc.baikal.ru wrote:
Do you have some processes that intensively create tables or columns
and then delete them or create them in transaction and rollback the
transaction?
There are many processes
On 8/5/13 10:18 PM, Craig Ringer wrote:
The main issue with the test is that it's a dirty hack. What I really
want is a way to block a statement at a certain point - to say block
after a snapshot is acquired for example - and release that at a time
of my choosing.
...
Opinions? Is this
On 7/26/13 7:32 AM, Tom Lane wrote:
Greg Smith g...@2ndquadrant.com writes:
On 7/26/13 5:59 AM, Hannu Krosing wrote:
Well, SSD disks do it in the way proposed by didier (AFAIK), by putting
random
fs pages on one large disk page and having an extra index layer for
resolving
random-to-sequential
Peter Eisentraut pete...@gmx.net 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 it for the next
release builds.
Um ...
2013/8/21 Jim Nasby j...@nasby.net
On 8/12/13 1:08 PM, Pavel Stehule wrote:
IF (bytes != LENGTH($1)) THEN
RAISE EXCEPTION 'Not all data copied to blob';
END IF;
PERFORM lo_close(fd);
FWIW, it's probably better to close before raising the exception...
it should to be done
Noah Misch n...@leadboat.com writes:
On Wed, Aug 21, 2013 at 10:13:15AM -0400, Tom Lane wrote:
The reason for that is you'd get randomly different results on another
installation. In this particular application, I think David doesn't
really care about what values he gets as long as they're
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 plpgsql;
On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net 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,
* 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
On Thu, Aug 22, 2013 at 2:08 AM, Pavel Stehule pavel.steh...@gmail.com 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
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On 08/22/2013 02:51 PM, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On Tue, Aug 20, 2013 at 1:57 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-08-19 15:17:44 -0700, Jeff Janes wrote:
On Wed, Aug 7, 2013 at 7:40 AM, Merlin Moncure mmonc...@gmail.com wrote:
I agree; at least then it's not unambiguously better. if you (in
effect) swap all contention
On Thu, Aug 22, 2013 at 9:53 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 08/22/2013 02:51 PM, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com wrote:
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do
+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 http://amutu.com/blog
2013/8/10 Pavel
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
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
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 making use of
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
On 2013-08-22 21:51:22 +0900, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund and...@2ndquadrant.comwrote:
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
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'='1234',
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
bricklen brick...@gmail.com writes:
On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund and...@2ndquadrant.comwrote:
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
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 for me
Josh Berkus j...@agliodbs.com 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
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
Andres Freund and...@2ndquadrant.com 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
On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 a
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
obtained.
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 increase the
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 doesn't
Andres Freund and...@2ndquadrant.com 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
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
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 as
Jeff Janes jeff.ja...@gmail.com 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
2013/8/22 Marko Tiikkaja ma...@joh.to
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
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
On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, Aug 21, 2013 at 2:33 PM, Jim Nasby j...@nasby.net 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
On 08/20/2013 05:48 AM, Merlin Moncure wrote:
On Tue, Aug 20, 2013 at 7:44 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2013/8/20 Merlin Moncure mmonc...@gmail.com
On Tue, Aug 20, 2013 at 7:25 AM, Andres Freund and...@2ndquadrant.com
I think the way forward is to remove the
Josh Berkus j...@agliodbs.com 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
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
2013/8/23 Josh Berkus j...@agliodbs.com
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
On Thu, Aug 22, 2013 at 6:06 PM, Stephen Frost sfr...@snowman.net 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
On Thu, Aug 22, 2013 at 9:34 PM, Bruce Momjian br...@momjian.us 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
2013/8/23 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Aug 22, 2013 at 2:53 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
52 matches
Mail list logo
