On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao wrote:
> On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs wrote:
>> The WALSender deliberately does *not* wake waiting users if the standby
>> disconnects. Doing so would break the whole reason for having sync rep
>> in the first place. What we do is allow
On Fri, Mar 4, 2011 at 12:02 AM, Fujii Masao wrote:
> Though I've not read whole of the patch yet, here is the current comment:
Here are another comments:
+#replication_timeout_client = 120 # 0 means wait forever
Typo: s/replication_timeout_client/sync_replication_timeout
+
On Wed, Mar 02, 2011 at 12:25:16PM -0800, Joe Conway wrote:
> I'm working with a client on an application upgrade script which
> executes a function to conditionally do an:
>
> ALTER TABLE foo ALTER COLUMN bar SET DATA TYPE baz
>
> If this is run while the application is concurrently doing inse
On Fri, Mar 4, 2011 at 04:00, Robert Treat wrote:
> I have a server where I wanted to do some reporting on a standby, and
> wanted to set the max standby delay to 1 hour. upon doing that, i get
> this in the logs:
>
> 2011-03-03 21:20:08 EST () [2656]: [2-1] user=,db=LOG: received
> SIGHUP, reloa
On Fri, 2011-03-04 at 13:35 +0900, Fujii Masao wrote:
> On Fri, Mar 4, 2011 at 1:27 PM, Fujii Masao wrote:
> > On Fri, Mar 4, 2011 at 7:01 AM, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> Anyway, this is code in the interrupt handler and only gets executed
> >>> when we receive SIGTERM for a f
On Fri, Mar 4, 2011 at 1:27 PM, Fujii Masao wrote:
> On Fri, Mar 4, 2011 at 7:01 AM, Tom Lane wrote:
>> Simon Riggs writes:
>>> Anyway, this is code in the interrupt handler and only gets executed
>>> when we receive SIGTERM for a fast shutdown.
>>
>> I trust it's not getting *directly* executed
On Fri, Mar 4, 2011 at 7:01 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Anyway, this is code in the interrupt handler and only gets executed
>> when we receive SIGTERM for a fast shutdown.
>
> I trust it's not getting *directly* executed from the interrupt handler,
> at least not without Immedia
I have a server where I wanted to do some reporting on a standby, and
wanted to set the max standby delay to 1 hour. upon doing that, i get
this in the logs:
2011-03-03 21:20:08 EST () [2656]: [2-1] user=,db=LOG: received
SIGHUP, reloading configuration files
2011-03-03 21:20:08 EST () [2656]: [3
On Mar 3, 2011, at 6:26 PM, Joe Conway wrote:
> On 03/03/2011 03:49 PM, Jim Nasby wrote:
>> On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
>>> On 03/02/2011 12:41 PM, Tom Lane wrote:
Looks like the process trying to do the ALTER has already got some
lower-level lock on the table. It evide
On 03/03/2011 03:49 PM, Jim Nasby wrote:
> On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
>> On 03/02/2011 12:41 PM, Tom Lane wrote:
>>> Looks like the process trying to do the ALTER has already got some
>>> lower-level lock on the table. It evidently hasn't got
>>> AccessExclusiveLock, but nonethe
Robert Haas writes:
> On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane wrote:
>> Comments?
> My only real concern about this is that someone might get confused
> about whether they are supposed to issue CREATE EXTENSION or CREATE
> LANGUAGE.
It wouldn't really matter, up till the point when they tried
On Mar 1, 2011, at 10:54 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Dumb question: Is this something that could be solved by having the
>> postmaster track this information in it's local memory and make it available
>> via a variable-sized IPC mechanism, such as a port or socket? That would
>>
On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
> On 03/02/2011 12:41 PM, Tom Lane wrote:
>> Looks like the process trying to do the ALTER has already got some
>> lower-level lock on the table. It evidently hasn't got
>> AccessExclusiveLock, but nonetheless has something strong enough to
>> block an
On Thu, Mar 3, 2011 at 4:31 PM, Tom Lane wrote:
> Comments?
My only real concern about this is that someone might get confused
about whether they are supposed to issue CREATE EXTENSION or CREATE
LANGUAGE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"David E. Wheeler" writes:
> On Mar 3, 2011, at 2:16 PM, Tom Lane wrote:
>> Extensions yes, but not managed with those commands. You'd have to
>> switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE
>> commands themselves would now only occur within those extension
>> scripts
Lee Duynslager writes:
> Hi I am trying to recover a postgres database from a ext3 partition
> that the filesystem has become corrupt and lost files. Can anybody
> tell me what are the file signatures for the files that comprise a
> postgres database?
Look at PageHeaderIsValid in bufpage.c. Tho
On Mar 3, 2011, at 2:16 PM, Tom Lane wrote:
> Extensions yes, but not managed with those commands. You'd have to
> switch over to saying "CREATE/DROP EXTENSION plpgsql", etc. The LANGUAGE
> commands themselves would now only occur within those extension
> scripts.
Ah, I see. So if someone insta
Hi I am trying to recover a postgres database from a ext3 partition
that the filesystem has become corrupt and lost files. Can anybody
tell me what are the file signatures for the files that comprise a
postgres database?
Anybody know of any tools that can detect and recover postgres files
from an
"David E. Wheeler" writes:
> On Mar 3, 2011, at 1:31 PM, Tom Lane wrote:
>> This looks like it would be at most a few hours' work to change,
>> and it would enable creation of extensions for the built-in languages
>> that can be loaded with the same permissions as before.
> Would that time includ
Simon Riggs writes:
> Anyway, this is code in the interrupt handler and only gets executed
> when we receive SIGTERM for a fast shutdown.
I trust it's not getting *directly* executed from the interrupt handler,
at least not without ImmediateInterruptOK.
regards, tom lane
Tom Lane wrote:
> what if we allow non-superusers to create an extension if all the
> commands in the script are ones they could execute anyway?
+1
The supporting detail all made sense to me. To put it another way,
why would you want to *bar* someone from executing a set of
statements they
On Mar 3, 2011, at 1:31 PM, Tom Lane wrote:
> However, it does strike me that there is one simple case we could
> support without a great deal of sweat. Namely, what if we allow
> non-superusers to create an extension if all the commands in the script
> are ones they could execute anyway? In par
On Thu, 2011-03-03 at 22:27 +0100, Yeb Havinga wrote:
> On 2011-03-03 11:53, Simon Riggs wrote:
> > Latest version of Sync Rep, which includes substantial internal changes
> > and simplifications from previous version. (25-30 changes).
> >
> > Includes all outstanding technical comments, typos and
Dimitri Fontaine writes:
> Tom Lane writes:
>> On the whole I'd rather spend time trying to fix the real problem, which
>> is allowing CREATE EXTENSION to non-superusers. The general case of
>> that looks quite hard to me, but maybe we could get something that works
>> for the single case of an
On 2011-03-03 11:53, Simon Riggs wrote:
Latest version of Sync Rep, which includes substantial internal changes
and simplifications from previous version. (25-30 changes).
Includes all outstanding technical comments, typos and docs. I will
continue to work on self review and test myself, though
On Thu, Mar 03, 2011 at 09:27:58PM +0200, Heikki Linnakangas wrote:
> Yes, we use David Olson's tz database. According to this proposal, David
> Olson is retiring, and they propose that IETF takes over maintainership
> of the tz database.
Yeah, I guess I ought to have summarized. That is inde
Dimitri Fontaine writes:
> Tom Lane writes:
>> On the whole I'd rather spend time trying to fix the real problem, which
>> is allowing CREATE EXTENSION to non-superusers. The general case of
>> that looks quite hard to me, but maybe we could get something that works
>> for the single case of an
On 03.03.2011 20:45, Andrew Sullivan wrote:
Today on the ietf-applications list, I saw this:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02301.html
If there are particular issues with respect to the time zone database
stuff that you all have struggled with and want highlighted,
On Fri, 2011-03-04 at 00:02 +0900, Fujii Masao wrote:
> + else if (WaitingForSyncRep)
> + {
> + /*
> +* This must NOT be a FATAL message. We want
> the state of the
> +* transaction being aborted to be
On Mar 3, 2011, at 11:09 AM, Tom Lane wrote:
> That's not a design, that's just a very arbitrary kluge. And it doesn't
> solve anything at all that we need to solve today, because you can
> already assume that you're running on >= 9.1 just by the fact that
> you're writing an extension. Having a
"David E. Wheeler" writes:
> On Mar 3, 2011, at 10:54 AM, Tom Lane wrote:
>> I basically agree with Robert that "requires = 9.1" is entirely useless.
> I'm saying that
> core_requires = 9.1.0, libxml, plpgsql
> Means >= 9.1.0.
That's not a design, that's just a very arbitrary kluge. And i
On Mar 3, 2011, at 10:54 AM, Tom Lane wrote:
>> Which is why my suggestion is pretty much free from any design. Just a list
>> of dependencies, with only a server version number. No other syntax at all.
>> It can be added later.
>
> I basically agree with Robert that "requires = 9.1" is entirel
"David E. Wheeler" writes:
> On Mar 3, 2011, at 10:32 AM, Robert Haas wrote:
>>> Who said anything about full generality? I'm interested in a 90% (or even
>>> 99%) solution.
>>
>> It's pretty important that we don't design ourselves into a corner her
> Which is why my suggestion is pretty much
On Mar 3, 2011, at 10:49 AM, Kevin Grittner wrote:
>> Which is why my suggestion is pretty much free from any design
>
> Now you're scaring me. I read that as "the proposed design is free
> from the influence of any design effort."
No. Just as simple as possible.
> That's precisely how you
> c
"David E. Wheeler" wrote:
> On Mar 3, 2011, at 10:32 AM, Robert Haas wrote:
>> It's pretty important that we don't design ourselves into a
>> corner her
>
> Which is why my suggestion is pretty much free from any design
Now you're scaring me. I read that as "the proposed design is free
from
Hackers,
Today on the ietf-applications list, I saw this:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02301.html
If there are particular issues with respect to the time zone database
stuff that you all have struggled with and want highlighted, feel free
to send them to me and I'
On Mar 3, 2011, at 10:32 AM, Robert Haas wrote:
>> Who said anything about full generality? I'm interested in a 90% (or even
>> 99%) solution.
>
> It's pretty important that we don't design ourselves into a corner her
Which is why my suggestion is pretty much free from any design. Just a list o
On Thu, Mar 3, 2011 at 1:30 PM, David E. Wheeler wrote:
> On Mar 3, 2011, at 10:22 AM, Robert Haas wrote:
>
>> Requires: package
>> Requires: package >= minversion
>> Requires: package <= maxversion
>> Requires: package = exactversion
>>
>> The usefulness of the first two should be obvious, but th
On Mar 3, 2011, at 10:22 AM, Robert Haas wrote:
> Requires: package
> Requires: package >= minversion
> Requires: package <= maxversion
> Requires: package = exactversion
>
> The usefulness of the first two should be obvious, but the third and
> fourth are needed as well.
In the long term, perha
On Thu, Mar 3, 2011 at 1:14 PM, Simon Riggs wrote:
> On Thu, 2011-03-03 at 18:51 +0100, Dimitri Fontaine wrote:
>> Simon Riggs writes:
>> > On Fri, 2011-03-04 at 00:02 +0900, Fujii Masao wrote:
>> >> > * synchronous_standby_names = "*" matches all standby names
>> >>
>> >> Using '*' as the defaul
On Thu, Mar 3, 2011 at 12:56 PM, David E. Wheeler wrote:
> More simply, I think there are two kinds of dependencies:
>
> * Other extensions
> * Core features
>
> Notwithstanding that PLs might be extensions, now or in the future, the
> necessity to require other stuff from core, like libxml suppo
On Thu, 2011-03-03 at 18:51 +0100, Dimitri Fontaine wrote:
> Simon Riggs writes:
> > On Fri, 2011-03-04 at 00:02 +0900, Fujii Masao wrote:
> >> > * synchronous_standby_names = "*" matches all standby names
> >>
> >> Using '*' as the default seems to lead the performance degradation by
> >> being
On Mar 3, 2011, at 10:12 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> core_requires = 9.0, plpgsql, libxml
>
> As soon as you get there you need an or operator to be able to say 9.0 |
> 9.1, or maybe some comparison operators to say >= 9.0. Remember that
> about all extensions w
"David E. Wheeler" writes:
> core_requires = 9.0, plpgsql, libxml
As soon as you get there you need an or operator to be able to say 9.0 |
9.1, or maybe some comparison operators to say >= 9.0. Remember that
about all extensions we have are source-compatible with many different
releases of Pos
On Mar 3, 2011, at 9:55 AM, Dimitri Fontaine wrote:
> Then those should be marked "System" and only get displayed with \dxS,
> or this will completely bloat the extension listings. Also if we get
> there, what about listing all the SQL Standard Features (optional only
> maybe) that are provided b
On Mar 3, 2011, at 9:47 AM, Dimitri Fontaine wrote:
> Then, what about a control file property to cover that?
>
> pl_language = plpgsql
>
> Then when running the script any object attached to the extension that
> is not a 'pg_catalog.pg_language'::regclass is an ERROR. And only when
> the pl_l
Heikki Linnakangas writes:
> We've been talking about PLs, but what about the other thing David asked:
> could we have extension entries for compile-time options like SSL or libxml,
> so that you could define a dependency on them?
Then those should be marked "System" and only get displayed with \
Simon Riggs writes:
> On Fri, 2011-03-04 at 00:02 +0900, Fujii Masao wrote:
>> > * synchronous_standby_names = "*" matches all standby names
>>
>> Using '*' as the default seems to lead the performance degradation by
>> being connected from unexpected synchronous standby.
>
> You can configure i
Tom Lane writes:
> On the whole I'd rather spend time trying to fix the real problem, which
> is allowing CREATE EXTENSION to non-superusers. The general case of
> that looks quite hard to me, but maybe we could get something that works
> for the single case of an extension containing just a lang
I wrote:
> Robert Haas writes:
>> "Deprecated, use instead"?
Everybody seems happy with that part of the proposal, so I'll make it
happen.
>> I think the chances that future patches will follow the more complex
>> coding rule are near zero, absent some type of automated enforcement
>> mechanism
On Fri, 2011-03-04 at 00:02 +0900, Fujii Masao wrote:
> > * synchronous_standby_names = "*" matches all standby names
>
> Using '*' as the default seems to lead the performance degradation by
> being connected from unexpected synchronous standby.
You can configure it however you wish. It seemed
da...@kineticode.com ("David E. Wheeler") writes:
> You should blog this.
He just did, using the SMTP protocol...
--
select 'cbbrowne' || '@' || 'acm.org';
http://linuxdatabases.info/info/postgresql.html
Where do you want to Tell Microsoft To Go Today?
--
Sent via pgsql-hackers mailing list (pg
On Thu, Mar 3, 2011 at 4:30 PM, Robert Haas wrote:
> So what? AFAIK the extension patch hasn't broken anything here that
> used to work. People can still install languages the way they always
> have. What we're talking about here is a way of installing languages
> that is arguably nicer than w
On Thu, Mar 3, 2011 at 11:39 AM, Aidan Van Dyk wrote:
> No, what is being talked about isn't intended as a "way of installing
> languages that is ... nicer". What is being talked about is allowing
> an "Extension" that is being installed know that it's going to blow up
> because it's required lan
On 03.03.2011 18:30, Robert Haas wrote:
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane wrote:
Robert Haas writes:
I think that it's not a good idea to devote too much energy to this
problem right now, anyway. [ we need to get to beta ASAP, instead ]
I hear you, but once we get to beta, or even
On Thu, Mar 3, 2011 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> I think that it's not a good idea to devote too much energy to this
>> problem right now, anyway. [ we need to get to beta ASAP, instead ]
>
> I hear you, but once we get to beta, or even the last alpha, it's going
> to be
Tom Lane writes:
> Not sure it's that easy. I think DROP LANGUAGE can't assume that the
> language it's been told to drop is extension-ified. (Even if we do this
If CREATE LANGUAGE creates an extension of the same name, then DROP
LANGUAGE can assume that there's an extension of the same name, r
On 03.03.2011 16:46, hom wrote:
Hi,
I'm debug Postgresql with Eclipse under Redhat and I met a problem.
when I step in then function parse_analyze(), Eclipse opened file
src/backend/commands/analyze.c.
But actually, function parse_analyze() should match the file
src/backend/parser/analyze.c.
Robert Haas writes:
> I think that it's not a good idea to devote too much energy to this
> problem right now, anyway. [ we need to get to beta ASAP, instead ]
I hear you, but once we get to beta, or even the last alpha, it's going
to be very hard to make changes that would interfere with people
Sorry so much!
I thought I replied to the question already, but not yet.
> $ find /usr/share/selinux -name '*ake*'
> /usr/share/selinux/default/include/Makefile
> /usr/share/selinux/ubuntu/include/Makefile
> /usr/share/selinux/mls/include/Makefile
>
> Not sure which of these would be the right on
On Thu, Mar 3, 2011 at 3:13 PM, Tom Lane wrote:
> 1. Do people like the idea of marking obsolete operator names this
> way? If so, exactly how to mark them? We could try to add
> "(deprecated, ...)" at the end of the existing description, or just
> replace the description completely. In some of
[ slightly more awake now ... ]
I wrote:
> Not sure it's that easy. I think DROP LANGUAGE can't assume that the
> language it's been told to drop is extension-ified. (Even if we do this
> for all the core ones, there are a dozen non-core ones that might not
> all get with the program right away.
On Thu, Mar 3, 2011 at 10:31 AM, Tom Lane wrote:
> It may all work pretty easily, but I'm still caffeine-deprived so I'm
> not sure ...
I think that it's not a good idea to devote too much energy to this
problem right now, anyway. We have crammed a gigantic pile of code
into the source tree in t
On Thu, Mar 3, 2011 at 5:38 AM, Kohei Kaigai wrote:
> BTW, it seems to me the base version of selinux-policy-* package in Ubuntu
> is forked from an older snapshot (20091117), so it does not have enough rules
> to run SE-PostgreSQL.
>
> Right now, Fedora 13/14 is the easiest way.
Yeah. I think t
Robert Haas writes:
> On Thu, Mar 3, 2011 at 10:13 AM, Tom Lane wrote:
>> 2. Given that we do #1, is it really a good idea to generate the
>> boilerplate comments automatically? The argument I can see against it
>> is that right now there's a pretty simple coding rule "every pg_proc.h
>> entry s
On Thu, Mar 3, 2011 at 10:13 AM, Tom Lane wrote:
> I finally got around to completing the function-comments cleanup
> proposed here:
> http://archives.postgresql.org/pgsql-docs/2010-10/msg00041.php
>
> There are now a heck of a lot of boilerplate comments like
> DESCR("implementation of + o
On Thu, Mar 3, 2011 at 10:16 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue mar 03 11:18:38 -0300 2011:
>> On Thu, Mar 3, 2011 at 9:15 AM, Alvaro Herrera
>> wrote:
>> > Excerpts from Fujii Masao's message of mié mar 02 22:44:45 -0300 2011:
>> >> On Thu, Mar 3, 2011 at 3:22
Alvaro Herrera writes:
> I admit I have no idea why these guys seem to run into wraparound
> problems so much.
> On the other hand, I'm not sure that it would work to try to checkpoint
> "during" vacuum, because the backend is in a transaction. Maybe it
> would work to force a checkpoint after e
Dimitri Fontaine writes:
> Tom Lane writes:
>> You'd need to work out how the CREATE OR REPLACE and DROP cases would
>> work.
> Maybe the fever ain't gone far enough, but I'd just do nothing in the
> first case and internally cascade to the extension in the second case.
> In fact internally the
Tom Lane writes:
>> Meanwhile, is it possible to have CREATE LANGUAGE internally register an
>> extension? It's a kludge but I somehow though I'd mention it.
>
> Hmmm ... it definitely is a kluge, but ...
>
> You'd need to work out how the CREATE OR REPLACE and DROP cases would
> work.
Maybe the
Excerpts from Robert Haas's message of jue mar 03 11:18:38 -0300 2011:
> On Thu, Mar 3, 2011 at 9:15 AM, Alvaro Herrera
> wrote:
> > Excerpts from Fujii Masao's message of mié mar 02 22:44:45 -0300 2011:
> >> On Thu, Mar 3, 2011 at 3:22 AM, Alvaro Herrera
> >> wrote:
> >> > I noticed that in sta
I finally got around to completing the function-comments cleanup
proposed here:
http://archives.postgresql.org/pgsql-docs/2010-10/msg00041.php
There are now a heck of a lot of boilerplate comments like
DESCR("implementation of + operator");
in pg_proc.h (about 700 of 'em to be exact). My
On Thu, Mar 3, 2011 at 2:16 AM, Heikki Linnakangas
wrote:
> On 03.03.2011 09:12, daveg wrote:
>>
>> Question: what would be the consequence of simply patching out the setting
>> of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
>> problem (big assumption perhaps) then simpl
On Thu, Mar 3, 2011 at 7:53 PM, Simon Riggs wrote:
> Latest version of Sync Rep, which includes substantial internal changes
> and simplifications from previous version. (25-30 changes).
>
> Includes all outstanding technical comments, typos and docs. I will
> continue to work on self review and t
Hi,
I'm debug Postgresql with Eclipse under Redhat and I met a problem.
when I step in then function parse_analyze(), Eclipse opened file
src/backend/commands/analyze.c.
But actually, function parse_analyze() should match the file
src/backend/parser/analyze.c.
So I found the execute order didn
Itagaki Takahiro writes:
> We have window function version of first_value(),
> but aggregate version looks useful to write queries something like:
> =# CREATE TABLE obj (id integer, pos point);
> =# SELECT X.id,
> first_value(Y.id ORDER BY X.pos <-> Y.pos) AS neighbor
>FROM obj X, o
Dimitri Fontaine writes:
> Tom Lane writes:
>> Probably in future the standard PLs will be packaged as extensions, and
>> then it will work. The main reason that it won't happen for 9.1 is that
>> right now we require superuser privilege to install an extension, which
>> would be a regression co
On Thu, Mar 3, 2011 at 9:15 AM, Alvaro Herrera
wrote:
> Excerpts from Fujii Masao's message of mié mar 02 22:44:45 -0300 2011:
>> On Thu, Mar 3, 2011 at 3:22 AM, Alvaro Herrera
>> wrote:
>> > I noticed that in standalone mode, WAL segments don't seem to be
>> > recycled. This could get problema
Excerpts from Fujii Masao's message of mié mar 02 22:44:45 -0300 2011:
> On Thu, Mar 3, 2011 at 3:22 AM, Alvaro Herrera
> wrote:
> > I noticed that in standalone mode, WAL segments don't seem to be
> > recycled. This could get problematic if you're forced to vacuum large
> > tables in that mode
>> I see that all these issues have been fixed and committed by Tom via
>> git commitid: 281a724d on 6th June, 2008. Was wondering why this fix
>> is not in these supported branches like 8.3.13 for example. Kinda
>> confused..
>
> We don't usually back-patch such large changes.
Oh ok. Thanks.
Reg
On Thu, Mar 3, 2011 at 6:09 AM, Nikhil Sontakke
wrote:
> I see that all these issues have been fixed and committed by Tom via
> git commitid: 281a724d on 6th June, 2008. Was wondering why this fix
> is not in these supported branches like 8.3.13 for example. Kinda
> confused..
We don't usually ba
On Wed, Mar 2, 2011 at 5:10 PM, Yeb Havinga wrote:
> On 2011-03-02 21:26, Kevin Grittner wrote:
>>
>> I think including "synchronous" is OK as long as it's properly
>> qualified. Off-hand thoughts in no particular order:
>>
>> semi-synchronous
>> conditionally synchronous
>> synchronous with auto
On Wed, Mar 02, 2011 at 01:33:35PM -0600, Andy Colson wrote:
> I thought Kris was going to work on this, but saw no progress, and I
> was bored the other day, so I started working on it.
>
> Here is a parse.pl, with some major refactoring.
>
> I named it with a 2 so I could run it beside the orig
On Wednesday 2. of March 2011 20:18:08 Peter Eisentraut wrote:
> On ons, 2011-03-02 at 09:10 +0100, Rumko wrote:
> > What about this patch (
> > http://www.rumko.net/0001-DragonFly-BSD-support-linked-nbsd.patch )?
> > instead of linking to freebsd, it's linked to netbsd and It still
> > compiles du
Hi,
Am referring to the following conversation:
http://archives.postgresql.org/pgsql-bugs/2007-12/msg00190.php
To summarize, in 8.3.x due to improper locking and concurrency issues
in the DROP OBJECT codepath, for example if one tries to drop an index
while dropping the table from another sessio
Thanks, Tom !
Oleg
On Wed, 2 Mar 2011, Tom Lane wrote:
Teodor Sigaev writes:
[ builtin_knngist_contrib_btree_gist-0.12 patch ]
Applied with some corrections --- mostly, that the upgrade script was
all wet. I added some documentation too.
regards, tom lane
On Thu, Mar 03, 2011 at 10:16:29AM +0200, Heikki Linnakangas wrote:
> On 03.03.2011 09:12, daveg wrote:
> >Question: what would be the consequence of simply patching out the setting
> >of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
> >problem (big assumption perhaps) then
We have window function version of first_value(),
but aggregate version looks useful to write queries something like:
=# CREATE TABLE obj (id integer, pos point);
=# SELECT X.id,
first_value(Y.id ORDER BY X.pos <-> Y.pos) AS neighbor
FROM obj X, obj Y
GROUP BY X.id;
Is it reasonab
Tom Lane writes:
> Probably in future the standard PLs will be packaged as extensions, and
> then it will work. The main reason that it won't happen for 9.1 is that
> right now we require superuser privilege to install an extension, which
> would be a regression compared to the privilege requirem
Robert Haas writes:
> I don't understand how synchronous replication with
> allow_standalone_primary=on gives you ANY extra nines. AFAICS, the
> only point of having synchronous replication is that you wait to
> acknowledge the commit to the client until the commit record has been
> replicated.
On Thu, 2011-03-03 at 02:14 -0500, Tom Lane wrote:
> Fujii Masao writes:
> > On Thu, Mar 3, 2011 at 12:11 AM, Heikki Linnakangas
> > wrote:
> >> To achieve the effect Fujii is looking for, we would have to silently drop
> >> the connection. That would correctly leave the client not knowing whethe
On 03.03.2011 09:12, daveg wrote:
Question: what would be the consequence of simply patching out the setting
of this flag? Assuming that the incorrect PD_ALL_VISIBLE flag is the only
problem (big assumption perhaps) then simply never setting it would at least
avoid the possibility of returning wr
92 matches
Mail list logo
