Heikki Linnakangas writes:
> On 10.05.2012 00:34, Tom Lane wrote:
>> After further study of the bgwriter hibernation patch (commit
>> 6d90eaaa89a007e0d365f49d6436f35d2392cfeb), I think that my worries about
>> race conditions in the use of the bgwriter's latch are really the least
>> of its proble
On 10.05.2012 00:34, Tom Lane wrote:
After further study of the bgwriter hibernation patch (commit
6d90eaaa89a007e0d365f49d6436f35d2392cfeb), I think that my worries about
race conditions in the use of the bgwriter's latch are really the least
of its problems. BgBufferSync embodies a rather care
Alvaro Herrera writes:
> I noticed while doing some tests that the checkpointer process does not
> recover very nicely after a backend crashes under postmaster -T (after
> all processes have been kill -CONTd, of course, and postmaster told to
> shutdown via Ctrl-C on its console). For some reason
On Wed, May 9, 2012 at 2:17 PM, Peter Eisentraut wrote:
> postgresql://user:password@/dbname
>
> In libpq, this is parsed as host='/dbname', no database.
That is flat wrong.
> - Requiring percent escapes
And this is, IMHO, the right fix.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
On Wed, May 9, 2012 at 11:11 PM, Bruce Momjian wrote:
> I have completed my draft of the 9.2 release notes, and committed it to
> git.
Extra parens:
Remove the spclocation field from pg_tablespace (Magnus Hagander, Tom Lane))
Reduce overhead of creating virtual transaction id locks ((Robert
Haas,
Bruce Momjian writes:
> The docs finally built 90 minutes after my commit, and the URL above is
> now working. (Does it always take this long to update?)
I believe the new implementation of that stuff is that the devel docs
are built whenever the buildfarm member guaibasaurus runs for HEAD,
whic
On Thu, May 10, 2012 06:33, Bruce Momjian wrote:
> On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-2.html
>
To "E.1.2.5. Monitoring" should be added:
"Rename pg_stat_activity.current_query to query (Magnus Hagande
On 05/09/2012 10:01 PM, Tom Lane wrote:
> Joe Conway writes:
>> The attached one-liner seems to plug up the majority (although not quite
>> all) of the leakage.
>
> Looks sane to me. Are you planning to look for the remaining leakage?
Actually, now I'm not so sure there really are any other lea
Hi all,
I think psql's \dO command is missing the server version check which
similar commands such as \dx use. Right now \dO errors out with:
test=# \dO
ERROR: relation "pg_catalog.pg_collation" does not exist
when talking to servers older than 9.1, which don't have pg_collation.
Simple patch f
On Thu, May 10, 2012 at 07:02:43AM +0200, Stefan Kaltenbrunner wrote:
> On 05/10/2012 06:33 AM, Bruce Momjian wrote:
> > On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
> >> (Why is there no time zone shown in the date/time at the top?) I think
> >> it will eventually show up here:
On 05/10/2012 06:33 AM, Bruce Momjian wrote:
> On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
>> (Why is there no time zone shown in the date/time at the top?) I think
>> it will eventually show up here:
>>
>> http://www.postgresql.org/docs/devel/static/release-9-2.html
>
>
Joe Conway writes:
> The attached one-liner seems to plug up the majority (although not quite
> all) of the leakage.
Looks sane to me. Are you planning to look for the remaining leakage?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
> I expect to revisit config directories before the first 9.3 CF, it will
> help multiple things I'd like to see happen. Then we can circle back to
> the main unification job with a fairly clear path forward from there.
Yeah, let's discuss this next week. "Easier configuration" is one
demand I'
On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
> (Why is there no time zone shown in the date/time at the top?) I think
> it will eventually show up here:
>
> http://www.postgresql.org/docs/devel/static/release-9-2.html
The docs finally built 90 minutes after my commit, an
On 05/09/2012 11:15 PM, Bruce Momjian wrote:
On Wed, May 09, 2012 at 08:07:52PM -0700, Josh Berkus wrote:
All,
I'll point out that this patch got sandbagged to death, and never made
it into 9.2. So, for 9.2 replication is just as hard to configure and
manage as it was in 9.1. Are we going to
On Wed, May 09, 2012 at 08:07:52PM -0700, Josh Berkus wrote:
> All,
>
> I'll point out that this patch got sandbagged to death, and never made
> it into 9.2. So, for 9.2 replication is just as hard to configure and
> manage as it was in 9.1. Are we going to fix it in 9.3, or not?
Greg Smith was
I have completed my draft of the 9.2 release notes, and committed it to
git. I am waiting for our development docs to build, but after 40
minutes, I am still waiting:
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&dt=latest&stg=make-doc
(Why is there no time z
All,
I'll point out that this patch got sandbagged to death, and never made
it into 9.2. So, for 9.2 replication is just as hard to configure and
manage as it was in 9.1. Are we going to fix it in 9.3, or not?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hack
On 05/09/2012 05:06 PM, Joe Conway wrote:
> OK, new script. This more faithfully represents the real life scenario,
> and reproduces the issue on HEAD with out-of-the-box config settings,
> versus 8.1 which completes the query having never exceeded a very modest
> memory usage:
>
> ---
On Wed, May 9, 2012 at 8:43 AM, Robert Haas wrote:
> On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian wrote:
>>> It does provide an additional guarantee, but I accept you personally
>>> may not find that useful.
>>
>> The guarantee is that if Postgres crashes, we don't lose any data, but
>> not if
On 05/09/2012 03:36 PM, Joe Conway wrote:
> Good call -- of course that just means my contrived example fails to
> duplicate the real issue :-(
> In the real example, even with work_mem = 1 MB I see the same behavior
> on 9.1.
OK, new script. This more faithfully represents the real life scenario,
> If so, we should also rename the column "write_location" in
> pg_stat_replication?
Now that you bring it up, probably. Although not necessarily for 9.2.
> I named "remote_write (originally write)" after that column. And, in
> "remote_write",
> internally the master waits for replication unti
On Thu, May 10, 2012 at 8:18 AM, Euler Taveira wrote:
> On 09-05-2012 19:17, MauMau wrote:
>> Then, does it make sense to remove "#define KEEPONLYALNUM" in 9.1.4? Would it
>> cause any problems? If no, I wish that, because it eliminates the need to do
>> the removal every time the users applies mi
On Thu, May 10, 2012 at 6:23 AM, Josh Berkus wrote:
>
>> The naming is not arbitrary. -1 to changing it as suggested.
>>
>> It is as Aidan says, a state between receive and fsync, normally
>> referred to as write.
>>
>> Plus the word remote denotes it is on the standby, not the local master.
>>
>>
On 09-05-2012 19:17, MauMau wrote:
> Then, does it make sense to remove "#define KEEPONLYALNUM" in 9.1.4? Would it
> cause any problems? If no, I wish that, because it eliminates the need to do
> the removal every time the users applies minor releases.
>
If you do so, you'll break minor versions.
On 05/09/2012 03:08 PM, Tom Lane wrote:
> I see no memory leak at all in this example, either in HEAD or 9.1
> branch tip. Perhaps whatever you're seeing is an already-fixed bug?
>
> Another likely theory is that you've changed settings from the 8.1
> installation. I would expect this example to
From: "Fujii Masao"
On Wed, May 9, 2012 at 9:10 PM, MauMau wrote:
This question may be appropriate for pgsql-general, but let me ask here
because the only relevant discussion seems to have been done on
pgsql-hackers:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00169.php
Can pg_tr
Joe Conway writes:
> I'm working on an upgrade of PostgreSQL embedded in a product from
> version 8.1.x to 9.1.x. One particular PL/pgSQL function is giving us an
> issue as there seems to be a rather severe regression in memory usage --
> a query that finishes in 8.1 causes an out of memory excep
On Wed, May 09, 2012 at 05:37:09PM -0400, Bruce Momjian wrote:
> On Wed, May 09, 2012 at 02:23:30PM -0700, Josh Berkus wrote:
> >
> > > The naming is not arbitrary. -1 to changing it as suggested.
> > >
> > > It is as Aidan says, a state between receive and fsync, normally
> > > referred to as wr
On Wed, May 09, 2012 at 02:23:30PM -0700, Josh Berkus wrote:
>
> > The naming is not arbitrary. -1 to changing it as suggested.
> >
> > It is as Aidan says, a state between receive and fsync, normally
> > referred to as write.
> >
> > Plus the word remote denotes it is on the standby, not the lo
I wrote:
> I believe the bgwriter code needs to be fixed similarly to the way
> I changed the walwriter patch, namely that there needs to be a separate
> flag (not the latch's isSet state) advertising whether the bgwriter is
> currently in hibernation mode.
After further study of the bgwriter hibe
> The naming is not arbitrary. -1 to changing it as suggested.
>
> It is as Aidan says, a state between receive and fsync, normally
> referred to as write.
>
> Plus the word remote denotes it is on the standby, not the local master.
>
> So both words have specific meaning, and IMHO clear meanin
I'm working on an upgrade of PostgreSQL embedded in a product from
version 8.1.x to 9.1.x. One particular PL/pgSQL function is giving us an
issue as there seems to be a rather severe regression in memory usage --
a query that finishes in 8.1 causes an out of memory exception on 9.1.
Using the same
I see one potential difference between your results and mine.
When I rebuild the tablespace, I wind up with the same filename/OID as
before, I'm not sure you do.
--
Mike Nolan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Excerpts from Peter Eisentraut's message of mié may 09 13:54:53 -0400 2012:
> Split contrib documentation into extensions and programs
>
> Create separate appendixes for contrib extensions and other server
> plugins on the one hand, and utility programs on the other. Recast
> the documentation o
On 5/9/12, Albe Laurenz wrote:
> I cannot reproduce this on 9.1.3:
Odd, I've tried it another two times, with similar results to my initial post.
Here's what I get starting with the point where I deleted the files in
the tablespace:
mytest=# select * from mytable;
select * from mytable;
ERROR:
I have been reviewing how our new libpq URL syntax compares against
existing implementations of URL syntaxes in other drivers or
higher-level access libraries. In the case of SQLAlchemy, there is an
incompatibility regarding how Unix-domain sockets are specified.
First, here is the documentation
On Wed, May 9, 2012 at 9:10 PM, MauMau wrote:
> Hello,
>
> This question may be appropriate for pgsql-general, but let me ask here
> because the only relevant discussion seems to have been done on
> pgsql-hackers:
>
> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00169.php
>
> Can pg_trg
On Thu, May 10, 2012 at 1:42 AM, Robert Haas wrote:
> On Wed, May 9, 2012 at 10:02 AM, Simon Riggs wrote:
>>> Another thing I've been wondering is whether, perhaps, we ought to
>>> keep synchronous_commit tri-valued: on/local/off, and have a separate
>>> GUC for synchronous_replication_mode. It'
On Wed, May 9, 2012 at 10:02 AM, Simon Riggs wrote:
>> Another thing I've been wondering is whether, perhaps, we ought to
>> keep synchronous_commit tri-valued: on/local/off, and have a separate
>> GUC for synchronous_replication_mode. It's a bit arbitrary that "on"
>> happens to mean remote fsyn
On 9 May 2012 15:34, Tom Lane wrote:
> Simon Riggs writes:
>>> We should just use MyPgXact->xid
>>> rather than add more to the transaction path
>>>
>>> I'll simplify the patch and commit.
>
>> Committed, but forgot to give appropriate credit. Sorry about that.
>
> This patch didn't fix things, i
On Wed, May 9, 2012 at 10:34 AM, Bruce Momjian wrote:
>> It does provide an additional guarantee, but I accept you personally
>> may not find that useful.
>
> The guarantee is that if Postgres crashes, we don't lose any data, but
> not if the OS crashes (right?) because that isn't clear now.
True
Simon Riggs writes:
>> We should just use MyPgXact->xid
>> rather than add more to the transaction path
>>
>> I'll simplify the patch and commit.
> Committed, but forgot to give appropriate credit. Sorry about that.
This patch didn't fix things, it broke things. The former guarantee
that age's
fOn Wed, May 09, 2012 at 03:02:23PM +0100, Simon Riggs wrote:
> On 9 May 2012 13:48, Robert Haas wrote:
> > On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian wrote:
> >> Let me point out that our documentation says nothing about it being
> >> written to the kernel --- it just says "has received the c
Last night I changed the stats collector process to use
WaitLatchOrSocket instead of a periodic forced wakeup to see whether
the postmaster has died. This morning I observe that several Windows
buildfarm members are showing regression test failures caused by
unexpected "pgstat wait timeout" warnin
On 9 May 2012 13:48, Robert Haas wrote:
> On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian wrote:
>> Let me point out that our documentation says nothing about it being
>> written to the kernel --- it just says "has received the commit record
>> of the transaction to memory."
>
> Maybe remote_receiv
On 9 May 2012 00:55, Simon Riggs wrote:
> On 8 May 2012 20:01, Peter Eisentraut wrote:
>> On ons, 2012-01-18 at 14:55 -0500, Tom Lane wrote:
>>> BTW, it strikes me that maybe the coding should work about like this:
>>>
>>> if (!TransactionIdIsValid(age_reference_xid))
>>> {
>>>
On Wed, May 9, 2012 at 7:29 AM, Bruce Momjian wrote:
> Let me point out that our documentation says nothing about it being
> written to the kernel --- it just says "has received the commit record
> of the transaction to memory."
Maybe remote_receive would be better. If we're actually writing it
Hello,
This question may be appropriate for pgsql-general, but let me ask here
because the only relevant discussion seems to have been done on
pgsql-hackers:
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00169.php
Can pg_trgm support non-alphanumeric characters by undefining KEEPON
On Wed, May 09, 2012 at 08:52:40AM +0100, Simon Riggs wrote:
> >> Well, yes, but in the sequence of:
> >> >> remote_accept
> >> >> remote_write
> >> >> remote_sync
> >>
> >> it is much more clear...
> >>
> >> With a single "remote_write", you can't tell just by itself it that is
> >> intended
On 9 May 2012 03:52, Bruce Momjian wrote:
> On Tue, May 08, 2012 at 10:29:31PM -0400, Aidan Van Dyk wrote:
>> On Tue, May 8, 2012 at 10:09 PM, Bruce Momjian wrote:
>>
>> >> And then, I could envision (if it continues down this road):
>> >> off
>> >> local
>> >> remote_accept
>> >> remote_
Michael Nolan wrote:
> While researching a problem reported on the -general list by a user
who lost a disk containing his
> index tablespace, I ran into something, but I'm not sure is a serious
bug or just an inconsistency in
> how \d shows tables.
>
> Here are the steps I took.
>
> 1. Create a
52 matches
Mail list logo
