Oops! [EMAIL PROTECTED] ("J. Andrew Rogers") was seen spray-painting on a wall:
> I may be completely missing the point here, but it looks to me as
> though the PITR archival mechanism is also most of a native
> replication facility. Is there anyone reason this couldn't be
> extended to replicatio
[EMAIL PROTECTED] ("Marc G. Fournier") writes:
> On Thu, 1 Apr 2004, Christopher Kings-Lynne wrote:
>> > Is your timeline based on the assumption of doing all the work
>> > yourself? If so, how about farming out some of it? I'd be
>> > willing to contribute some effort to PITR. (It's been made c
On Fri, 2004-04-02 at 16:52, Magnus Hagander wrote:
> Hi!
>
> When debugging on win32, I've created myself a little function that I
> feel should be added to the "backend proper". While it adds a lot of
> vlaue on win32, I think it adds quite a bit of value on non-win32
> platforms as well...
>
>
ignore it
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> Having to recompile initdb.c is probably not an option.
>
>initdb is just a shell script in existing releases.
Yes, you are right. By sheer habit I typed in cd ~/pgsql/src/bin.
> My bet is that they ate all available shmem, leaving none for
I am having some trouble interfacing the 7.5 server built with MINGW
with tools generated using other compilers.
I suspect that the issue is one of default structure packing. In the
old version we were using, we built PostgreSQL using Intel C++ or MS
VC++ and the same for the libpq and other inte
Jeff wrote:
On Apr 5, 2004, at 12:35 PM, Bruce Momjian wrote:
For me, /contrib is for things closely tied to the backend code, like
GIST stuff, and for key tools, like conversion programs.
something that would be useful (and perhaps may be part of that
pgfoundry or whatever its called movement) w
> say "Silly, thats on gborg!" and they look at me strangely
Sure. The "gborg" name does not strike as being related to postgresql.
--
Fabien Coelho - [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choos
On Apr 5, 2004, at 12:35 PM, Bruce Momjian wrote:
For me, /contrib is for things closely tied to the backend code, like
GIST stuff, and for key tools, like conversion programs.
something that would be useful (and perhaps may be part of that
pgfoundry or whatever its called movement) would be makin
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> This testcase works in 7.3 but not in 7.4:
> create table t1 (a int);
> create table t2 (b int);
> select * from t1, (select b as a from t2 group by a) as foo;
> ERROR: column "t2.b" must appear in the GROUP BY clause or be used in an
> aggregate f
> > Is it better in /contrib or gborg?
>
> Gborg imho. I thought we were trying to move all non-core code there
> now. Isn't that why psqlodbc etc. were moved?
The argument was that it can be devopped and released independently?
Features in "contrib/" have a premium over external add-ons.
--
F
It's rumoured that Bruce Momjian once said:
>
> Is it better in /contrib or gborg?
>
Gborg imho. I thought we were trying to move all non-core code there now.
Isn't that why psqlodbc etc. were moved?
Regards, Dave
---(end of broadcast)---
TIP 3:
Hans-Jürgen Schönig wrote:
> >
> > Is it better in /contrib or gborg?
> >
>
>
> I have learned (please correct me if I am wrong) that people tend to
> look in contrib before they look at gborg.
> Also, when people ask for training most of them ask for stuff in
> contrib. It is people's mind t
Is it better in /contrib or gborg?
I have learned (please correct me if I am wrong) that people tend to
look in contrib before they look at gborg.
Also, when people ask for training most of them ask for stuff in
contrib. It is people's mind that contrib is somehow a source of
additional, smal
Hans-Jürgen Schönig wrote:
> Tom Lane wrote:
> > =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> >
> >>Nested transactions: I don't think nested transactions will really help
> >>to resolve the core problem. Committing a subtransaction will most
> >>likely not imply that a
I would be FOR it if the README states the dangers
Bob Henkel 651-738-5085
Mutual Funds I/T Woodbury
Hartford Life
500 Bielenberg Drive
Woodbury, MN 55125
|-+>
| | Hans-Jürgen |
| | Schönig |
|
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
Nested transactions: I don't think nested transactions will really help
to resolve the core problem. Committing a subtransaction will most
likely not imply that a parent transaction can be committed as well.
A
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> Nested transactions: I don't think nested transactions will really help
> to resolve the core problem. Committing a subtransaction will most
> likely not imply that a parent transaction can be committed as well.
Agreed.
> As
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
People asked me to put a simple extension for PostgreSQL Open Source.
The attached package contains a simple functions whichs tells a remote
TCP socket that somebody is about to modify a certain table.
Doesn't
"Doesn't this encourage violation of the basic notion of a transaction?
The message will be sent immediately, whether or not the sending
transaction actually commits."
Any postgresql C coders out there that can help us out with nested
transactions?
This pretty much comes down to having neste
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Having to recompile initdb.c is probably not an option.
initdb is just a shell script in existing releases.
> Sybase and Oracle both installed properly without having to change shmmax.
My bet is that they ate all available shmem, leaving none f
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> People asked me to put a simple extension for PostgreSQL Open Source.
> The attached package contains a simple functions whichs tells a remote
> TCP socket that somebody is about to modify a certain table.
Doesn't this encoura
SRA America is sponsoring an evening event with me in NYC. If folks
want to go, the details are on our web site under "Events".
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Ro
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>>> In this case, SIGINT (query cancel) will not help, because
>>> all locks held by the transaction will still be held.
>>
>> Wrong.
> Really?
[ experiments... ] My apologies --- you are correct about the present
behavior. If a SIGINT arrives wh
Greg Sabino Mullane said:
>
>
> Having to recompile initdb.c is probably not an option.
Which version of PostreSQL are you installing on this production machine?
initdb is not a C program in any released version - in 7.4.2 it is a shell
script which you could trivially modify. Of course, in the ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> [ raises eyebrow... ] So you're installing a test database server on a
> production machine? That's not preferred admin practice anywhere that
> I know of. If it's really going to be a production server, I won't have
> a lot of sympathy for the
Community,
People asked me to put a simple extension for PostgreSQL Open Source.
The attached package contains a simple functions whichs tells a remote
TCP socket that somebody is about to modify a certain table.
Why would anybody do that?
Currently PostgreSQL provides a nice LISTEN / NOTIFY mec
Am Freitag, 2. April 2004 07:21 schrieb BARTKO, Zoltan:
> just wanted to mention that the first part of the slovak translation of Pg
> is available - the psql strings - at the following address:
>
> http://de.geocities.com/bartkozo/psql-sk.po.gz
Installed in 7.5 branch.
-
> > In this case, SIGINT (query cancel) will not help, because
> all locks
> > held by the transaction will still be held.
>
> Wrong.
Really?
Please point out where I am wrong in this:
SESSION A: BEGIN TRANSACTION
SESSION A: LOCK TABLE foo IN ACCESS EXCLUSIVE MODE
S
29 matches
Mail list logo