On 29.09.2012 22:13, Jeff Janes wrote:
The default value for shared_buffers was recently increased from 32MB
to 128MB, but the docs were not updated.
Thanks, applied.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 09/29/2012 10:29 PM, Andrew Dunstan wrote:
On 09/29/2012 05:01 PM, Hannu Krosing wrote:
On 09/29/2012 05:40 PM, Andrew Dunstan wrote:
I still think Tom's suggestion is the best and simplest way to do that.
which Toms suggestion you mean here ?
The 3. mentioned above was for making
Here is 64-bit API for large object version 3 patch.
I checked this patch. It looks good, but here are still some points to be
discussed.
* I have a question. What is the meaning of INT64_IS_BUSTED?
It seems to me a marker to indicate a platform without 64bit support.
However, the
On 27.09.2012 23:58, Pavel Stehule wrote:
Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned rows, but we should to
get number of processed rows too. A users
2012/10/1 Heikki Linnakangas hlinnakan...@vmware.com:
On 27.09.2012 23:58, Pavel Stehule wrote:
Hello
I reduced this patch as just plpgsql (SPI) problem solution.
Correct generic solution needs a discussion about enhancing our libpq
interface - we can take a number of returned rows, but we
Hi,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Same for 9.2, attached. master needs yet another patch because of the
recent headers reorg, it seems, that's for another day though.
No, just remove the RELKIND_UNCATALOGUED case in that switch.
Oh. As in the attached? :)
Regards,
--
Can we please expose the internal hash id of the statements in
pg_stat_statements?
I know there was discussions about it earlier, and it wasn't done with
an argument of it not being stable between releases (IIRC). I think we
can live with that drawback, assuming of course that we document this
On 21.09.2012 14:18, Amit kapila wrote:
On Tuesday, September 18, 2012 6:02 PM Fujii Masao wrote:
On Mon, Sep 17, 2012 at 4:03 PM, Amit Kapilaamit.kap...@huawei.com wrote:
Approach-2 :
Provide a variable wal_send_status_interval, such that if this is 0, then
the current behavior would prevail
On 1 October 2012 08:57, Magnus Hagander mag...@hagander.net wrote:
I know there was discussions about it earlier, and it wasn't done with
an argument of it not being stable between releases (IIRC). I think we
can live with that drawback, assuming of course that we document this
properly.
On 9/28/12 10:35 AM, Alvaro Herrera wrote:
Now there is one more problem in this area which is that the patch
defined a new type pg_int64 for frontend code (postgres_ext.h). This
seems a bad idea to me. We already have int64 defined in c.h. Should
we expose int64 to postgres_ext.h somehow?
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning d...@kavod.com wrote:
Another good reason to reject it might be because the only way to disable
the CTE fence is to disable it by default. If that were the case, then I
would imagine that it would break backwards compatibility, especially in the
On 1 October 2012 14:05, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning d...@kavod.com wrote:
I'm wondering if there are any technical/standards constraints that
are behind the fencing behavior. If there aren't any, maybe an opt-in
keyword might do
On 9/30/12 5:42 PM, Andres Freund wrote:
I thought msvc supported _Static_assert as well, but after a short search it
seems I misremembered and it only supports static_assert from C++11 (which is
plausible, because I've worked on a C++11 project which was ported to windows
). I don't know
Merlin Moncure mmonc...@gmail.com writes:
I'm wondering if there are any technical/standards constraints that
are behind the fencing behavior. If there aren't any, maybe an opt-in
The fencing is per standard, and very useful when used in wCTEs.
keyword might do the trick -- WITH UNBOXED foo
Datum_to_json
SELECT 'a=1'::hstore, 'a1/a'::xml, '{a:1}'
(Please note that last column is unknown – datatype)
Now, what is the main goal? to get:
1)
{
hstore: \a\=\1\,
xml: a1/a,
?column?: {\a\:1}
}
or:
2)
{
hstore: {
a: 1
},
xml: {
a:
Per
http://archives.postgresql.org/pgsql-general/2012-10/msg00013.php
we have got a problem with the pg_malloc() interface functions that
were recently added to pg_dump and a lot of other frontend code.
Namely, that on platforms where malloc(0) returns NULL instead of
a pointer to a zero-size
On 09/29/2012 02:28:40 AM, Karl O. Pinc wrote:
On 09/29/2012 01:16:51 AM, Karl O. Pinc wrote:
The attached documentation patch further describes the
additive nature of the permission system.
Attached a second patch, applied after the
first, to extend the discussion
further regards
Merlin Moncure mmonc...@gmail.com writes:
I'm wondering if there are any technical/standards constraints that
are behind the fencing behavior.
I think the key reason is that we don't want partial execution of DML
operations (ie, INSERT/UPDATE/DELETE inside a WITH). The fencing
behavior was put
On Thu, Sep 27, 2012 at 04:02:45PM -0400, Robert Haas wrote:
On Thu, Sep 27, 2012 at 2:34 PM, Magnus Hagander mag...@hagander.net wrote:
I'm not sure that's a way we really want to go down. How do we define which
third party vendors would get to reserve oids? And how many? And under what
Magnus Hagander mag...@hagander.net writes:
Can we please expose the internal hash id of the statements in
pg_stat_statements?
I know there was discussions about it earlier, and it wasn't done with
an argument of it not being stable between releases (IIRC).
Worse than that: it could change
On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Can we please expose the internal hash id of the statements in
pg_stat_statements?
I know there was discussions about it earlier, and it wasn't done with
an argument of it not being
john knightley john.knight...@gmail.com writes:
On Mon, Oct 1, 2012 at 11:58 AM, Dan Scott deni...@gmail.com wrote:
So... perhaps LC_CTYPE=C is a possible workaround for you?
LC_CTYPE would not be a work around - this database needs to be in
utf8 , the full text search is to be used for a
On 1 October 2012 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
1. Teach pg_malloc not to complain if result == NULL and size == 0.
+1 to that proposal.
2. Before the malloc call, have it replace size == 0 with size = 1.
I don't like that proposal on purely aesthetic grounds.
--
Peter Geoghegan
On Sun, Sep 30, 2012 at 07:09:20PM -0700, Jeff Davis wrote:
On Fri, 2012-09-14 at 17:58 -0700, Jeff Davis wrote:
This is just a rebased version of the patch by Simon here:
I just noticed the following note in the docs for this patch:
The default is literaloff/ for backwards
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Namely, that on platforms where malloc(0) returns NULL instead of
a pointer to a zero-size block, pg_malloc thinks it's a failure
and aborts the program.
What's the use case for malloc(0) anyway?
See
On Mon, Oct 1, 2012 at 10:07:01AM -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
I'm wondering if there are any technical/standards constraints that
are behind the fencing behavior.
I think the key reason is that we don't want partial execution of DML
operations (ie,
Peter Geoghegan pe...@2ndquadrant.com writes:
On 1 October 2012 15:00, Tom Lane t...@sss.pgh.pa.us wrote:
1. Teach pg_malloc not to complain if result == NULL and size == 0.
+1 to that proposal.
2. Before the malloc call, have it replace size == 0 with size = 1.
I don't like that proposal
On Mon, Oct 1, 2012 at 6:38 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm, I think we need to step back a bit. I've never liked the way
replication_timeout works, where it's the user's responsibility to set
wal_receiver_status_interval replication_timeout. It's not very
Tom Lane t...@sss.pgh.pa.us writes:
Namely, that on platforms where malloc(0) returns NULL instead of
a pointer to a zero-size block, pg_malloc thinks it's a failure
and aborts the program.
What's the use case for malloc(0) anyway?
1. Teach pg_malloc not to complain if result == NULL and
On 01-10-2012 11:22, Magnus Hagander wrote:
As long as we *tell* them under what conditions it might change, I
think it's perfectly fine. Particularly those who are likely to use
this functionality should certainly be capable of understanding that.
Even if we do that it is too much work for
On 1 October 2012 15:22, Magnus Hagander mag...@hagander.net wrote:
On Mon, Oct 1, 2012 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Worse than that: it could change across a minor version update. These
are internal data structures we're hashing, and we've been known to
have to change them
Andres Freund and...@2ndquadrant.com writes:
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
I'm still pretty desperately unhappy with your insistence on circularly
linked dlists. Not only does that make initialization problematic,
but now it's not even consistent with slists.
We
Tatsuo Ishii is...@postgresql.org writes:
The right thing to use if you're trying to interleave portal executions
like that is Flush, not Sync. Sync mainly adds a protocol
resynchronization point --- it's needed in case portal execution fails
partway through. (In which case you'll have lost
* Bruce Momjian (br...@momjian.us) wrote:
If we wanted to relax the fencing, we might need to do it via an SQL
keyword on the SELECT, to avoid the confusion caused by GUCs.
I like the idea of providing a way for users to request non-fencing,
perhaps only allowed for SELECT CTEs. I don't like
Peter, all,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
Well, I'll point out once again that the argument about its stability
is invalid, because we serialise the entries to disk. If a point
release changes the representation of the query tree such that the
hash values won't match, then
On 1 October 2012 17:12, Stephen Frost sfr...@snowman.net wrote:
Peter, all,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
Well, I'll point out once again that the argument about its stability
is invalid, because we serialise the entries to disk. If a point
release changes the
On Mon, 2012-10-01 at 10:43 -0400, Bruce Momjian wrote:
The default is literaloff/ for backwards compatibility and
to allow upgrade. The recommended setting is literalon/ though
this should not be enabled until upgrade is successfully complete
with full set of new backups.
I
On Mon, Oct 1, 2012 at 09:25:43AM -0700, Jeff Davis wrote:
On Mon, 2012-10-01 at 10:43 -0400, Bruce Momjian wrote:
The default is literaloff/ for backwards compatibility and
to allow upgrade. The recommended setting is literalon/ though
this should not be enabled until upgrade is
On Mon, Oct 1, 2012 at 7:38 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm, I think we need to step back a bit. I've never liked the way
replication_timeout works, where it's the user's responsibility to set
wal_receiver_status_interval replication_timeout. It's not very
On Mon, 2012-10-01 at 12:35 -0400, Bruce Momjian wrote:
The heap/index files are copied unmodified from the old cluster, so
there are no checksums on the pages.
That's fine though, the patch still reads the old format the same way,
and the pages are treated as though they have no checksum. How
On Monday, October 01, 2012 05:33:01 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Sunday, September 30, 2012 10:33:28 PM Tom Lane wrote:
I'm still pretty desperately unhappy with your insistence on circularly
linked dlists. Not only does that make initialization
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
That won't really help matters. There'd still be duplicate entries,
from before and after the change, even if we make it immediately
obvious which is which. The only reasonable solution in that scenario
is to bump PGSS_FILE_HEADER, which
On Fri, 2012-09-14 at 17:58 -0700, Jeff Davis wrote:
This is just a rebased version of the patch by Simon here:
http://archives.postgresql.org/message-id/CA
+u5nmkw_gbs6qq_y8-rjgl1v7mvw2hwbhartb8lojhnpfx...@mail.gmail.com
Another thing I noticed about the design of this patch:
It looks like
On Mon, Oct 1, 2012 at 10:04:09AM -0700, Jeff Davis wrote:
On Mon, 2012-10-01 at 12:35 -0400, Bruce Momjian wrote:
The heap/index files are copied unmodified from the old cluster, so
there are no checksums on the pages.
That's fine though, the patch still reads the old format the same
I think that's OK, because it's still protected by the WAL CRC, and
there's no expectation that the checksum is correct in shared buffers,
and the correct checksum should be set on the next checkpoint. Just an
observation.
We'd need to document that emphatically. Otherwise folks running on
On 1 October 2012 18:04, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-10-01 at 12:35 -0400, Bruce Momjian wrote:
The heap/index files are copied unmodified from the old cluster, so
there are no checksums on the pages.
That's fine though, the patch still reads the old format the same way,
On Mon, 2012-10-01 at 18:14 +0100, Simon Riggs wrote:
You are missing large parts of the previous thread, giving various
opinions on what the UI should look like for enabling checksums.
I read through all of the discussion that I could find. There was quite
a lot, so perhaps I have forgotten
Hello.
I need install the function in postgres to read xml.
The function is xpath I do not find the guide of installation procedure
of the function.
Need to get something?
Explain to me how to it the instalation.
Thanks.
There is a new release of the PostgreSQL buildfarm client available, It
can be downloaded at
https://github.com/downloads/PGBuildFarm/client-code/build-farm-4_8.tgz
Apart from some bug fixes, changes of note include:
* A new --only-steps command line option, requested by Stephen Frost
Hi,
This patch eliminates the #include of psqlscan.c
at the bottom of mainloop.c.
The attached patch uses the %top{} flex feature
introduced in flex 2.5.30 released 2003-4-1.
(See the NEWS file for flex.)
The good news is that config/programs.m4
requires flex = 2.5.31. The bad news
is that
Argh! Marti Raudsepp has pointed out that the change in the sample
config file to support upgrade testing didn't make it. If you need this
(really probably only if you're setting up a new animal) the fixed
tarball is at
On Fri, Sep 28, 2012 at 7:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
Example:
create temporary table foo (a int);
insert into foo values (1);
alter role peter set temp_buffers = 120;
ERROR: 22023: invalid value for parameter temp_buffers: 120
DETAIL:
Selena Deckelmann sel...@chesnok.com writes:
The check_temp_buffers() problem seems like a regression and blocks us
from upgrading to 9.2. The use case are functions that set
temp_buffers and occasionally are called in a series from a parent
session. The work around is... a lot of work.
Uh
Uh ... how is that a regression? AFAIK it's been that way right along.
No, it hasn't. I currently have an application whose functions, each of
which sets temp_buffers, works fine under 9.0 and ERRORs out under 9.2.
It's blocking an upgrade.
This is new.
--
Josh Berkus
PostgreSQL Experts
Nothing like replying to a 3 year old post, but I would like to confirm
whether this is possible. I have a 8.4 postgres database that was originally
designed (not by me) to store a lot of BLOBS and CLOBS. We're well past the
point of doing a VACUUM FULL given the 400GB size of the thing, and are
On Mon, Oct 1, 2012 at 3:08 PM, scc sc...@corscadden.ca wrote:
Nothing like replying to a 3 year old post, but I would like to confirm
whether this is possible.
I haven't tried this in a long time but AFAIR this is possible by
shutting down the server, start in standalone mode with change in
On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Selena Deckelmann sel...@chesnok.com writes:
The check_temp_buffers() problem seems like a regression and blocks us
from upgrading to 9.2. The use case are functions that set
temp_buffers and occasionally are called in a series
Thanks so much - sounds like I have a backup option if plan A fails.
Do you or any others here foresee any issues with me doing a database stop
(i.e., pg_ctl stop -D data) followed by one more rsync -aP to true up
the directory on the external drive, with finally a pg_ctl -D
On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann sel...@chesnok.com wrote:
On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Selena Deckelmann sel...@chesnok.com writes:
The check_temp_buffers() problem seems like a regression and blocks us
from upgrading to 9.2. The use case
It seems date_in() has a risk of buffer overrun. If the input is '.',
it sets field[0] to the beginning of workbuf and goes into
DecodeDate(). This function checks null-termination of the head of
string, but it can go beyond the end of string inside the first loop
and replace some bytes with
On Mon, Oct 1, 2012 at 3:30 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
lower address than field.
Ugh, s/lower/higher/
--
Hitoshi Harada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
I believe many users are basically familiar with TCP keepalives and how to
specify it. So I think that this approach would be intuitive to users.
My experience is that many users are unfamiliar with TCP keepalives
and
I'm proposing to make the attached change to some LDAP error messages.
Aside from fixing a pluralization issue, I want to separate fact (search
resulted in != 1 result) from interpretation (LDAP user does not exist,
and that's a problem).
diff --git a/src/backend/libpq/auth.c
On Tue, 2012-08-14 at 18:52 -0400, Bruce Momjian wrote:
I assume we didn't feel any action was necessary on this issue.
I propose the attached patch to reduce the redundant code as discussed.
---
On Thu, Aug 11, 2011
Never mind - the stop/rsync/change -D/restart completely worked. Whew.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/moving-system-catalogs-to-another-tablespace-tp2014761p5726241.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent
Excerpts from Robert Haas's message of lun oct 01 21:02:54 -0300 2012:
On Mon, Oct 1, 2012 at 12:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
I believe many users are basically familiar with TCP keepalives and how to
specify it. So I think that this approach would be intuitive to users.
66 matches
Mail list logo
