Federico Di Gregorio wrote:
Even if tests and examples code aren't almost never distributed except
in the psycopg2 source package? A couple of other people contributed to
the tests: if you really feel like it is so important I'll contact them
and ask their permission to use the LGPL3 + exception
Jakub Ouhrabka wrote:
I've found similar reports but with older versions of postgres:
http://old.nabble.com/100--of-CPU-utilization-postgres-process-tt27302021.html
Those all looked like a FreeBSD issue, doubt it's related to yours.
The pgstat.stat is ~20MB. There are 650 databases, 140GB t
Hi,
sorry for repost but previous message didn't get through. So I'm trying
another list and sending without attachment which I can send privately
upon request (strace output mentioned below).
We've migrated some of our databases to 8.4 cluster (from 8.2 and older
versions).
These database
Here is a patch to support new syntax in psql tab completion
and fix bugs to complete after an open parenthesis.
Supported additonal syntax are:
- ALTER TABLE/INDEX/TABLESPACE SET/RESET with options
- ALTER TABLE ALTER COLUMN SET/RESET with options
- ALTER TABLE ALTER COLUMN SET STORAGE
-
I wrote:
> ...
> 3. It is possible for a backend's own self-notifies to not be delivered
> immediately after commit, if they are queued behind some other
> uncommitted transaction's messages. That wasn't possible before either.
> ... We could fix
> #3 by re-instituting the special code path that
On Fri, Feb 5, 2010 at 9:08 AM, Takahiro Itagaki
wrote:
>
> Fujii Masao wrote:
>
>> On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell wrote:
>> > An inconsistency exists between the segment name reported by
>> > pg_stop_backup() and the actual WAL file name.
>> >
>> > START WAL LOCATION: 10/FE1E2BAC
(2010/02/14 13:34), Robert Haas wrote:
> * Fix large object support in pg_dump. I think this is just waiting
> for a second opinion on whether the approach is correct. I've been
> meaning to look at it, but haven't gotten enough round tuits; maybe
> someone else would like to take a look? This i
libpq has a PQclientEncoding() function that takes a connection object.
However, the client encoding is, in some cases, a property of the result
object. For instance, if your client_encoding changes, but you keep the
result object around, you have no way to determine later what encoding
the resul
On Sun, 2010-02-14 at 20:43 +0100, Florian Weimer wrote:
> The downside is that passing strings up to the application may have
> distinctly worse performance characteristics than passing a number.
Yes, that is a good point. I tried to clarify this in the doc.
I think this would fall under the opt
M Z wrote:
> Looks like the contrib functions have not been added in.
The contrib features are not built or installed by default -- they
are optional modules. This should point you in the right direction:
http://www.postgresql.org/docs/8.3/interactive/contrib.html
-Kevin
--
Sent via pg
On Mon, Feb 15, 2010 at 6:44 PM, Greg Stark wrote:
> I did respond to it. The whole point is that the text output is for a
> human to read. It should be printed in human-readable units. Not some
> arbitrary internal unit of accounting that they then have to do
> arithmetic on to make sense of.
We
On Tue, Feb 16, 2010 at 1:33 AM, Magnus Hagander wrote:
> 2010/2/15 Tom Lane :
>> Magnus Hagander writes:
>>> I changed your patch to this, because I find it a lot simpler. The
>>> change is in the checking in pgwin32_recv - there is no need to ever
>>> call waitforsinglesocket, we can just exit
On Tue, Feb 16, 2010 at 1:18 AM, Robert Haas wrote:
>> I'm all for this as a 9.1 submission, but let's not commit to trying to
>> debug it now. I would like a green buildfarm for awhile before we wrap
>> alpha4, and this sort of untested "it can't hurt" patch is exactly what
>> is likely to make
Pavel Stehule wrote:
> The dictionary data could be shared or minimally dictionary could be
> preloaded like some PL language.
>
> What do you think about this?
Surely preloading is the most realistic approach, but I hope we would support
dynamic allocation of shared memory, and load dictionar
Greg Stark wrote:
We do *not* display raw block numbers anywhere else. Generally I think
we should have a policy of outputing human-readable standard units of
memory whenever displaying a memory quantity. Actually I thought we
already had that policy, hence things like...
The first counter e
On Mon, Feb 15, 2010 at 7:58 PM, Robert Haas wrote:
>>> To me, buffers seem like discrete (and unitless)
>>> entities, and we handle them that way elsewhere in the system (see,
>>> e.g. pg_stat_database, pg_statio_all_tables). I don't know that it's
>>> a good idea to display that same informati
Hi Hackers,
I posted this to the GENERAL list a while back, but got no repies.
Perhaps someone here can help...
I've been building ECPG (embedded SQL/C) programs on a system with
Pg version 8.0 installed. When I tried to run them recently on
version 8.4 I found that there was a libecpg libra
Hi
I am trying to build postgresql with contrib functions from source code
checked out from cvs version 8.3.8 but getting error:
==
conifer=# SELECT * FROM xpath_table('id', 't', 'xpath_test', '/doc/int',
'true') as t(id int4);
ERROR: function xpath_table(unknown, unknown, unknow
On Feb 15, 2010, at 2:42 PM, Tim Bunce wrote:
> I've not really looked the the DBD::Pg code much so this seemed like a
> good excuse... It looks like the default is to call PQprepare() with
> paramTypes Oid values of 0.
Yes, IIRC, 0 == unknown as far as the server is concerned. It just tells the
On Mon, Feb 15, 2010 at 11:52:01AM -0800, David E. Wheeler wrote:
> On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
>
> > The signature doesn't just qualify the selection of the function,
> > it also ensures appropriate interpretation of the arguments.
> >
> > I could allow call('foo', @args), whic
hello ...
i have come an interesting corner case this morning and i am not sure
if it is worth treating this as a bug or as just "bad luck".
imagine creating a directory along with a tablespace ...
hans-jurgen-schonigs-macbook:html hs$ mkdir /tmp/x
hans-jurgen-schonigs-macbook:html hs$ psql te
On Mon, 2010-02-15 at 13:53 -0500, Tom Lane wrote:
> You're assuming that the LISTEN was transmitted across the connection,
> and not for example executed by a pre-existing function.
Ok, good point.
> In practice, since encoding conversion failures could interfere with the
> results of almost any
On Sun, 2010-02-14 at 22:44 +, Simon Riggs wrote:
> * We also discussed the idea of having a NOTIFY command that would work
> from Primary to Standby. All this would need is some code to WAL log the
> NOTIFY if not in Hot Standby and for some recovery code to send the
> NOTIFY to any listeners
On Sun, Feb 14, 2010 at 03:15:30PM -0500, Tom Lane wrote:
> So the currently submitted patch is logically inconsistent. If we
> enforce a character set restriction on the payload for fear of
> being unable to convert it to the destination client_encoding, then
> we should logically do the same for
On 15/02/2010 20:12, Greg Smith wrote:
> Federico Di Gregorio wrote:
>> I just wanted all interested people know that psycopg2 2.0.14 to be
>> released in the next few days will be under the LGPL3 + OpenSSL
>> exception (example code and tests under the LGPL3 alone because they are
>> never linked
Robert Haas wrote:
> > 7. Why is there no option to do parameterized-queries which replan every
> > time?
> >
> > This just seems like an area that has been neglected, or maybe I am
> > missing something and our current setup is acceptable.
>
> No, our current setup is not acceptable, and your que
On Mon, Feb 15, 2010 at 2:11 PM, Bruce Momjian wrote:
> Pavel Stehule wrote:
>> > The problem that we face is that we don't have any very good way to tell
>> > whether a fresh planning attempt is likely to yield a plan significantly
>> > better than the generic plan. ?I can think of some heuristic
Joachim Wieland writes:
> We could probably fake this on the Hot Standby in the following way:
> We introduce a commit record for every notifying transaction and write
> it into the queue itself. So right before writing anything else, we
> write an entry which informs readers that the following r
On Mon, Feb 15, 2010 at 1:29 PM, Greg Stark wrote:
> On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas wrote:
>>> Well there was a 30+ message thread almost a week ago where there
>>> seemed to be some contention over the issue of whether the numbers
>>> should be averages or totals. But were there wa
On Feb 15, 2010, at 2:51 AM, Tim Bunce wrote:
> The signature doesn't just qualify the selection of the function,
> it also ensures appropriate interpretation of the arguments.
>
> I could allow call('foo', @args), which could be written call(foo => @args),
> but what should that mean in terms of
Tom Lane wrote:
Well, no, consider the situation where planning takes 50 ms, the generic
plan costs 100ms to execute, but a parameter-specific plan would take 1ms
to execute. Planning is very expensive compared to execution but it's
still a win to do it.
I think that's a fun and worthwhile pr
On Mon, Feb 15, 2010 at 1:48 PM, Simon Riggs wrote:
> On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
>> I have tested it already. The point where it currently fails is the
>> following line:
>>
>> qe->xid = GetCurrentTransactionId();
>
> That's a shame. So it will never work in Ho
Federico Di Gregorio wrote:
I just wanted all interested people know that psycopg2 2.0.14 to be
released in the next few days will be under the LGPL3 + OpenSSL
exception (example code and tests under the LGPL3 alone because they are
never linked to OpenSSL).
Great news and I look forward to
Pavel Stehule wrote:
> > The problem that we face is that we don't have any very good way to tell
> > whether a fresh planning attempt is likely to yield a plan significantly
> > better than the generic plan. ?I can think of some heuristics --- for
> > example if the query contains LIKE with a para
Jeff Davis writes:
> On Sun, 2010-02-14 at 15:15 -0500, Tom Lane wrote:
>> Most obviously, we could also get an encoding
>> conversion failure on the notify condition name --- but we've never
>> enforced a character set restriction on that, and nobody's ever
>> complained about it AFAIR.
> If the
On Sun, 2010-02-14 at 15:15 -0500, Tom Lane wrote:
> Most obviously, we could also get an encoding
> conversion failure on the notify condition name --- but we've never
> enforced a character set restriction on that, and nobody's ever
> complained about it AFAIR.
If the client successfully execute
On Mon, Feb 15, 2010 at 6:05 PM, Robert Haas wrote:
>> Well there was a 30+ message thread almost a week ago where there
>> seemed to be some contention over the issue of whether the numbers
>> should be averages or totals. But were there was no dispute over the
>> idea of printing in memory units
Ciao Federico,
Federico Di Gregorio ha scritto:
I just wanted all interested people know that psycopg2 2.0.14 to be
released in the next few days will be under the LGPL3 + OpenSSL
exception (example code and tests under the LGPL3 alone because they are
never linked to OpenSSL).
Thank you so
On Mon, Feb 15, 2010 at 9:55 AM, Greg Stark wrote:
> On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas wrote:
>>> a) Changed the line description to "Total Buffer Usage" which at least
>>> hints that it's something more akin to the "Total runtime" listed at
>>> the bottom than the "actual time".
>>>
>
Greg Stark wrote:
We can always continue tweak the details of the format such as adding
spaces before the units to make it similar to the pg_size_pretty().
I'm not sure I like the idea of making it exactly equivalent because
pg_size_pretty() doesn't print any decimals so it's pretty imprecise
for
Joachim Wieland writes:
> One question regarding #2: Is a client application able to tell
> whether or not it has received all notifications from one batch? i.e.
> does PQnotifies() return NULL only when the backend has sent over the
> complete batch of notifications or could it also return NULL w
* Magnus Hagander (mag...@hagander.net) wrote:
> IIRC Stephen had some other reason, but I'll leave it to him to
> fill that in :-)
I was really looking for multi-server support as well, and support
for a config-file format that's commonly used for RADIUS. I'll
take a whack at doing that this eve
Magnus Hagander wrote:
Attached is the "last step" of the RADIUS authenticaiton as I promised
Stephen - which allows the reading of the RAIDUS secret from a file
instead of hardcoded in pg_hba.conf. One reason being you don't want
the secret in your config file that may be in a shared repository
2010/2/15 Tom Lane :
> Magnus Hagander writes:
>> I changed your patch to this, because I find it a lot simpler. The
>> change is in the checking in pgwin32_recv - there is no need to ever
>> call waitforsinglesocket, we can just exit out early.
>
>> Do you see any issue with that?
>
> This defini
Attached is the "last step" of the RADIUS authenticaiton as I promised
Stephen - which allows the reading of the RAIDUS secret from a file
instead of hardcoded in pg_hba.conf. One reason being you don't want
the secret in your config file that may be in a shared repository or
such. IIRC Stephen had
Magnus Hagander writes:
> I changed your patch to this, because I find it a lot simpler. The
> change is in the checking in pgwin32_recv - there is no need to ever
> call waitforsinglesocket, we can just exit out early.
> Do you see any issue with that?
This definitely looks cleaner, but is ther
On Mon, Feb 15, 2010 at 11:15 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane wrote:
>>> If this were actually a low-risk patch I might think it was okay to try
>>> to shoehorn it in now; but IME nothing involving making new use of
>>> system-dependent API
Robert Haas writes:
> On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane wrote:
>> If this were actually a low-risk patch I might think it was okay to try
>> to shoehorn it in now; but IME nothing involving making new use of
>> system-dependent APIs is ever low-risk. Look at Greg's current
>> embarrassm
2010/2/15 Robert Haas :
> On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane wrote:
>> Euler Taveira de Oliveira writes:
>>> Magnus Hagander escreveu:
If we want to do this, I'd be inclined to say we sneak this into 9.0..
It's small enough ;)
>>> I'm afraid Robert will say a big NO. ;) I'm
On Mon, Feb 15, 2010 at 11:00 AM, Tom Lane wrote:
> Euler Taveira de Oliveira writes:
>> Magnus Hagander escreveu:
>>> If we want to do this, I'd be inclined to say we sneak this into 9.0..
>>> It's small enough ;)
>>>
>> I'm afraid Robert will say a big NO. ;) I'm not against your idea; so if
>>
Robert Haas writes:
> On Mon, Feb 15, 2010 at 10:02 AM, Alvaro Herrera
> wrote:
>> I notice that the new plperl error messages are somewhat out of line of
>> our usual style:
>>
>> ereport(ERROR,
>> (errcode(ERRCODE_INTERNAL_ERROR),
>> errmsg(
Euler Taveira de Oliveira writes:
> Magnus Hagander escreveu:
>> If we want to do this, I'd be inclined to say we sneak this into 9.0..
>> It's small enough ;)
>>
> I'm afraid Robert will say a big NO. ;) I'm not against your idea; so if
> nobody objects go for it *now*.
If Robert doesn't I will
2010/2/15 Fujii Masao :
> On Sun, Feb 14, 2010 at 11:52 PM, Magnus Hagander wrote:
>> Remember that the win32 code *always* puts the socket in non-blocking
>> mode. So we can't just "teach the layer about it". We need some way to
>> pass the information down that this is actually something we want
Robert Haas writes:
> On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote:
>> When do we cut the alpha? If I look at it at about 10-11pm EST is that too
>> late?
> It looks like it's going to take Andrew until tomorrow to commit the
> last perl patch, so I think we should plan to cut the alpha on
hudson...@aol.com writes:
> I need to get a copy of PostGres source for version 7.2.8. In particular I
> need to build PostGres for now unsupported BeOS. I don't see V 7.2.8 on the
> download mirror. Can someone please provide info on accessing an older
> version?
AFAICT from the CVS history, B
Greg Stark writes:
> In looking through the build farm wreckage caused by fsyncing
> directories I noticed this interesting failure on pika:
> + ERROR: role "clstr_user" cannot be dropped because some objects depend on
> it
> + DETAIL: owner of table pg_temp_9.clstr_temp
That was fixed ages a
With the libpq fixes, I get further (more on that fix later, btw), but
now I get stuck in this. When I do something on the master that
generates WAL, such as insert a record, and then try to query this on
the slave, the walreceiver process crashes with:
PANIC: XX000: could not write to log file 0
Magnus Hagander escreveu:
> If we want to do this, I'd be inclined to say we sneak this into 9.0..
> It's small enough ;)
>
I'm afraid Robert will say a big NO. ;) I'm not against your idea; so if
nobody objects go for it *now*.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent
Peter Eisentraut writes:
> Since we ran out of time/ideas on this, I would propose just committing
> the part that breaks ties based on the number of arguments, which
> already solves a large part of the problem (at least in a pre-default
> values world) and would very likely be a part of any poss
On Mon, Feb 15, 2010 at 10:02 AM, Alvaro Herrera
wrote:
> I notice that the new plperl error messages are somewhat out of line of
> our usual style:
>
> ereport(ERROR,
> (errcode(ERRCODE_INTERNAL_ERROR),
> errmsg("while executing utf8fix"),
>
On Mon, Feb 15, 2010 at 9:52 AM, Magnus Hagander wrote:
> 2010/2/15 Euler Taveira de Oliveira :
>> Fujii Masao escreveu:
>>> Here is the patch which provides those three parameters as conninfo
>>> options. Should this patch be added into the first CommitFest for v9.1?
>>>
>> Go ahead.
>
> If we wa
Hi,
I notice that the new plperl error messages are somewhat out of line of
our usual style:
ereport(ERROR,
(errcode(ERRCODE_INTERNAL_ERROR),
errmsg("while executing utf8fix"),
errdetail("%s", strip_trailing_ws(SvPV_n
On Mon, Feb 15, 2010 at 2:22 PM, Robert Haas wrote:
>> a) Changed the line description to "Total Buffer Usage" which at least
>> hints that it's something more akin to the "Total runtime" listed at
>> the bottom than the "actual time".
>>
>> b) Used units of memory -- I formatted them with 3 signi
2010/2/15 Euler Taveira de Oliveira :
> Fujii Masao escreveu:
>> Here is the patch which provides those three parameters as conninfo
>> options. Should this patch be added into the first CommitFest for v9.1?
>>
> Go ahead.
If we want to do this, I'd be inclined to say we sneak this into 9.0..
It's
Robert Haas escribió:
> On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote:
> > When do we cut the alpha? If I look at it at about 10-11pm EST is that too
> > late?
>
> It looks like it's going to take Andrew until tomorrow to commit the
> last perl patch, so I think we should plan to cut the alp
On tis, 2010-01-12 at 16:35 +0200, Peter Eisentraut wrote:
> Um, that tag is the "name", and if you change that, the name in CREATE
> FUNCTION also changes. I was initially thinking in that direction, but
> it seems it won't be feasible without significant refactoring.
>
> In the mean time, hacki
Fujii Masao escreveu:
> Here is the patch which provides those three parameters as conninfo
> options. Should this patch be added into the first CommitFest for v9.1?
>
Go ahead.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Hello,
Czech users reports a slow first fulltext queries. It is based on
using ispell dictionary.
The dictionary data could be shared or minimally dictionary could be
preloaded like some PL language.
What do you think about this?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (p
On ons, 2010-02-10 at 18:25 -0200, Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > The general idea seems sensible to me. I can't comment on the
> > specifics.
> >
> +1. A lot of other programs have this summary at the end of configure
> execution. The problem is that PostgreSQL h
On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote:
> When do we cut the alpha? If I look at it at about 10-11pm EST is that too
> late?
It looks like it's going to take Andrew until tomorrow to commit the
last perl patch, so I think we should plan to cut the alpha on
Wednesday if nothing comes u
On Sun, Feb 14, 2010 at 8:25 PM, Greg Stark wrote:
> So this is what I did about my two complaints earlier about the
> explain buffer patch.
>
> a) Changed the line description to "Total Buffer Usage" which at least
> hints that it's something more akin to the "Total runtime" listed at
> the botto
2010/2/15 Greg Stark :
> On Mon, Feb 15, 2010 at 11:34 AM, marcin mank wrote:
>> LOG: could not link file "pg_xlog/xlogtemp.2367" to
>> "pg_xlog/0001" (initialization of log file 0,
>>
>
> This is not related -- it seems your filesystem doesn't support hard
> links. I thought
Greg Smith wrote:
> I can't seem to build the PDF version of the documentation on any of
> my Ubuntu 9.04 systems, and wonder if there's anything that
> can/should should get done about it.
Yeah, I'm seeing the same problem here. The strange thing is that 8.4
docs seem to build just fine.
--
Al
On Monday 15 February 2010 14:50:03 marcin mank wrote:
> Yes, the issue with initdb failing is unrelated (and I have no problem
> about the fs being unsupported). But fsync still DOES fail on
> directories from the mount.
>
> >> But I would not be that sure that eg. NFS or something like that won`
Yes, the issue with initdb failing is unrelated (and I have no problem
about the fs being unsupported). But fsync still DOES fail on
directories from the mount.
>> But I would not be that sure that eg. NFS or something like that won`t
>> complain.
> It does not.
>
What if someone mounts a NFS sha
On Sun, 2010-02-14 at 23:09 -0500, hudson...@aol.com wrote:
> I need to get a copy of PostGres source for version 7.2.8.
ftp://ftp-archives.postgresql.org/pub/source/v7.2.8/
Regards,
--
Devrim GÜNDÜZ, RHCE
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
devrim~gunduz.org, devrim~Pos
Dear Folks,
I need to get a copy of PostGres source for version 7.2.8. In particular I need
to build PostGres for now unsupported BeOS. I don't see V 7.2.8 on the download
mirror. Can someone please provide info on accessing an older version?
Many thanks,
Andrew
On Mon, Feb 15, 2010 at 10:51:14AM +, Tim Bunce wrote:
> On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> > On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
> >
> > > I've appended the POD documentation and attached the (rough but working)
> > > test script.
> > >
> > > I plan
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
> On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs wrote:
> > Next set of questions
> >
> > * Will this work during Hot Standby now? The barrier was that it wrote
> > to a table and so we could not allow that. ISTM this new version can and
> >
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
> > * I think it's confusing that pg_notify is both a data structure and
> a
> > function. Suggest changing one of those to avoid issues in
> > understanding. "Use pg_notify" might be confused by a DBA.
>
> You are talking about the libpq d
Le 15 févr. 2010 à 12:52, Greg Stark a écrit :
In looking through the build farm wreckage caused by fsyncing
directories I noticed this interesting failure on pika:
== pgsql.13659/src/test/regress/regression.diffs
===
*** /home/pgbuildfarm/workdir/HEAD/pgsql.136
On Mon, Feb 15, 2010 at 10:42:15AM +, Richard Huxton wrote:
> On 15/02/10 10:32, Tim Bunce wrote:
> >On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
> >>
> >>Is there any value in having a two-stage interface?
> >>
> >>$seq_fn = get_call('nextval(regclass)');
> >>$foo1
On Monday 15 February 2010 12:55:36 Greg Stark wrote:
> On Mon, Feb 15, 2010 at 11:50 AM, Andres Freund wrote:
> > If I understood him correctly marcin seems to mount a windows share on
> > linux via some vbox-proprietary pseudo filesystem. That wont get
> > detected and thus no junctions will be
On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs wrote:
> Next set of questions
>
> * Will this work during Hot Standby now? The barrier was that it wrote
> to a table and so we could not allow that. ISTM this new version can and
> should work with Hot Standby. Can you test that and if so, remove the
On Mon, Feb 15, 2010 at 11:50 AM, Andres Freund wrote:
> If I understood him correctly marcin seems to mount a windows share on linux
> via some vbox-proprietary pseudo filesystem. That wont get detected and thus
> no junctions will be used... (I have doubts you even can create them via
> vboxfs
In looking through the build farm wreckage caused by fsyncing
directories I noticed this interesting failure on pika:
== pgsql.13659/src/test/regress/regression.diffs
===
***
/home/pgbuildfarm/workdir/HEAD/pgsql.13659/src/test/regress/expected/cluster.out
Wed
F
On Monday 15 February 2010 12:45:39 Greg Stark wrote:
> On Mon, Feb 15, 2010 at 11:34 AM, marcin mank wrote:
> > LOG: could not link file "pg_xlog/xlogtemp.2367" to
> > "pg_xlog/0001" (initialization of log file 0,
>
> This is not related -- it seems your filesystem doesn't s
On Monday 15 February 2010 12:34:44 marcin mank wrote:
> On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund wrote:
> > Hi Marcin,
> >
> > Sounds rather unlikely to me. Its likely handled at an upper layer (vfs
> > in linux' case) and only overloaded when an optimized implementation is
> > available.
On Mon, Feb 15, 2010 at 11:34 AM, marcin mank wrote:
> LOG: could not link file "pg_xlog/xlogtemp.2367" to
> "pg_xlog/0001" (initialization of log file 0,
>
This is not related -- it seems your filesystem doesn't support hard
links. I thought we used "junctions" on versions o
On Mon, Feb 15, 2010 at 3:31 AM, Tom Lane wrote:
> I'm not sure how probable it is that applications might be coded in a
> way that relies on the properties lost according to point #2 or #3.
Your observations are all correct as far as I can tell.
One question regarding #2: Is a client applicatio
On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund wrote:
> Hi Marcin,
>
> Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in
> linux' case) and only overloaded when an optimized implementation is
> available.
> Which os do you see implementing that only on a part of the fil
Andrew Dunstan píše v po 08. 02. 2010 v 20:07 -0500:
>
> Our Solaris *moth members seem to have stopped building. Have we lost them?
Hi Andrew,
The answer is not simple. Yes, we lost Solaris 8 and 9 machines which
was reinstalled and now they are used for different purpose. It was
planned befor
On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
>
> Robert Haas wrote:
> >We're down to 5 patches remaining, and 1 day remaining, so it's time
> >to try to wrap things up.
> >
> >* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
> >is taking care of this one, I
On Mon, Feb 15, 2010 at 10:02 AM, Andres Freund wrote:
> Hi Marcin,
>
> Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in
> linux' case) and only overloaded when an optimized implementation is
> available.
> Which os do you see implementing that only on a part of the fil
On Sat, Feb 13, 2010 at 02:25:48PM -0800, David E. Wheeler wrote:
> On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
>
> > I've appended the POD documentation and attached the (rough but working)
> > test script.
> >
> > I plan to release the module to CPAN in the next week or so.
> >
> > I'd great
On Monday 15 February 2010 09:47:09 Simon Riggs wrote:
> On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > On a related note I would also like to get rid of the restriction that
> > a normal query cancellation will only be done if no subtransactions
> > are stacked.
> > But I guess its to
On 15/02/10 10:32, Tim Bunce wrote:
On Mon, Feb 15, 2010 at 07:31:14AM +, Richard Huxton wrote:
Is there any value in having a two-stage interface?
$seq_fn = get_call('nextval(regclass)');
$foo1 = $seq_fn->($seq1);
$foo2 = $seq_fn->($seq2);
I don't think there
On Monday 15 February 2010 09:50:08 Simon Riggs wrote:
> On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> > The first patch adds the capability to add a flag to ereport like:
> > ereport(ERROR | LOG_NO_CLIENT)
> > Tom earlier suggested using COMERROR but thats just a version of LOG
> > whi
On Sun, 2010-02-14 at 17:22 +0100, Joachim Wieland wrote:
> New patch attached, thanks for the review.
Next set of questions
* Will this work during Hot Standby now? The barrier was that it wrote
to a table and so we could not allow that. ISTM this new version can and
should work with Hot Standb
On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> The first patch adds the capability to add a flag to ereport like:
> ereport(ERROR | LOG_NO_CLIENT)
> Tom earlier suggested using COMERROR but thats just a version of LOG
> which doesnt report to the client. The patch makes that to be a
> sy
1 - 100 of 113 matches
Mail list logo
