On Tue, Nov 11, 2008 at 02:59:01PM +0100, Magnus Hagander wrote:
> Gianni Ciolli wrote:
> > WARNING: detected write past chunk end in Postmaster 0x9b13650
>
> Yes, that's a stupid bug:
(...)
> Attached is an updated version of the patch that fixes this.
Hi Magnus,
please find below the re
2008/11/25 Hitoshi Harada <[EMAIL PROTECTED]>:
> 2008/11/25 Heikki Linnakangas <[EMAIL PROTECTED]>:
>> Here's an updated patch, where the rows are fetched on-demand.
>
> Good! And I like the fetching args by number better. Let me take more
> time to look in detail...
I read more, and your spooling
Hi.
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
P.S)
日本語になっていましたです:-)
Regards,
Hiroshi Saito
- Original Message -
From: "Hiroshi Inoue" <[EMAIL PROTECTED]>
井上です。
ITAGAKI Takahir
井上です。
ITAGAKI Takahiro wrote:
> "Hiroshi Saito" <[EMAIL PROTECTED]> wrote:
>
>> Um, It was not supported.
>> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
>
> Hmm... the implementation of wcsftime() in msvcrt seems to be
> completely broken.
>
> I ran the atta
Zdenek -
I am a bit murky on where we stand with upgrade-in-place in terms of
reviewing. Initially, you had submitted four patches for this
commitfest:
1. htup and bufpage API clean up
2. HeapTuple version extension + code cleanup
3. In-place online upgrade
4. Extending pg_class info + more flex
Bernd,
Do you intend to submit an updated version of this patch for this commitfest?
If not, I will move this to "Returned with feedback".
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
2008/11/26 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>> 2008/11/20 David Rowley <[EMAIL PROTECTED]>:
>> > -- The following query gives incorrect results on the
>> > -- maxhighbid column
>> >
>> > SELECT auctionid,
>> > category,
>> > description,
>> > highestbid,
>
On Tue, Nov 25, 2008 at 9:18 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
>> After some thought, it seems pretty clear, at least to me, that the
>> third (hypothetical) command should not change the result of "SELECT *
>> FROM tricky" (the contrary conclusion gives rise to a lot of problems,
>> es
"Hiroshi Saito" <[EMAIL PROTECTED]> wrote:
> Um, It was not supported.
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
Hmm... the implementation of wcsftime() in msvcrt seems to be
completely broken.
I ran the attached test (localetest.c) and got the following
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 25, 2008 5:33 PM
> To: Dann Corbit
> Cc: Gregory Stark; Decibel!; Robert Haas; Bruce Momjian; Mark Wong;
> Heikki Linnakangas; Josh Berkus; Greg Smith; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [HACKER
Robert Haas escribió:
> After some thought, it seems pretty clear, at least to me, that the
> third (hypothetical) command should not change the result of "SELECT *
> FROM tricky" (the contrary conclusion gives rise to a lot of problems,
> especially if there are other views depending on it). But
> The ultimate conclusion was that a three-way split (identity, logical
> position, physical position) could work because most of the code only
> cares about column identity; the places where logical or physical
> positions are important are pretty narrowly circumscribed, or could
> be made so.
I
On Tue, Nov 25, 2008 at 8:38 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> I don't this is not empirical but really, 150 is very reasonable. Let's
> just set it to that by default and be done with it. It won't hurt
> anything and if they need more than that, they are already investigating
> eith
On Tue, 2008-11-25 at 20:33 -0500, Tom Lane wrote:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > I also do not believe that there is any value that will be the right
> > answer. But a table of data might be useful both for people who want to
> > toy with altering the values and also for those wh
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> I also do not believe that there is any value that will be the right
> answer. But a table of data might be useful both for people who want to
> toy with altering the values and also for those who want to set the
> defaults. I guess that at one time suc
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 24, 2008 at 10:25 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
>> IOW, DISCARD ALL should be functionally equivalent to backend exit.
> Having done a lot of work with advisory locks, I support this change.
> Advisory locks are essentially se
> -Original Message-
> From: Greg Stark [mailto:[EMAIL PROTECTED] On Behalf Of
> Gregory Stark
> Sent: Tuesday, November 25, 2008 5:06 PM
> To: Decibel!
> Cc: Tom Lane; Dann Corbit; Robert Haas; Bruce Momjian; Mark Wong;
> Heikki Linnakangas; Josh Berkus; Greg Smith; pgsql-
> [EMAIL PROTECT
Decibel! <[EMAIL PROTECTED]> writes:
> Is there even a good way to find out what planning time was? Is there a way
> to
> gather that stat for every query a session runs?
\timing
explain select ...
> The thought occurs to me that we're looking at this from the wrong side of
> the
> coin. I'
Simon Riggs wrote:
> On Mon, 2008-11-24 at 22:09 +0900, KaiGai Kohei wrote:
>
>> I removed the two hooks at the r1244 patch set.
>> As you said, it is fundamentally danger to load uncertain binary modules.
>> Thus, what we should do is checks on module loading.
>>
>> The default security policy re
Decibel! <[EMAIL PROTECTED]> writes:
> The thought occurs to me that we're looking at this from the wrong
> side of the coin. I've never, ever seen query plan time pose a
> problem with Postgres, even without using prepared statements.
That tells more about the type of queries you tend to run
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
>> IIRC the community did come to a consensus on allowing for a
>> different logical ordering from physical ordering, it was an issue of
>> actually doing the work. If this is an itch
On Mon, 2008-11-24 at 22:09 +0900, KaiGai Kohei wrote:
> I removed the two hooks at the r1244 patch set.
> As you said, it is fundamentally danger to load uncertain binary modules.
> Thus, what we should do is checks on module loading.
>
> The default security policy requires loadable modules to
On Nov 23, 2008, at 3:18 PM, Tom Lane wrote:
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
visibility bits set.
That makes the idea of not writing out hint bit updates unless the
page is already dirty a l
On Nov 19, 2008, at 11:51 PM, Tom Lane wrote:
"Dann Corbit" <[EMAIL PROTECTED]> writes:
I think the idea that there IS a magic number is the problem.
No amount of testing is ever going to refute the argument that,
under
some other workload, a different value might better.
But that doesn't a
Hitoshi Harada wrote:
> 2008/11/20 David Rowley <[EMAIL PROTECTED]>:
> > -- The following query gives incorrect results on the
> > -- maxhighbid column
> >
> > SELECT auctionid,
> > category,
> > description,
> > highestbid,
> > reserve,
> > MAX(highestbid) OVER (ORDER
It appears that the mingw faction of the buildfarm doesn't like this
patch:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00289.php
The failures look like the regression tests are being run with
intervalstyle = iso (the default) rather than postgres_verbose
as they ought to be. Which
On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
> IIRC the community did come to a consensus on allowing for a
> different logical ordering from physical ordering, it was an issue of
> actually doing the work. If this is an itch you want to scratch, you
> might look into fixing that
On Tue, Nov 25, 2008 at 11:46 AM, Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote:
> (I'm still downloading Fedora-10)
>
> Even though Tom is subscribed to the list below, I thought I should
> forward this e-mail to this list:
Why?
Unless I'm missing something, there's far too little information here
to
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> What do you dear readers think about the "extension" vocabulary?
+1 ... we should stay away from "package" unless we are going to
implement an Oracle-compatible facility. Which I don't particularly
wish to do, but we should leave it open for the futu
On Nov 14, 2008, at 12:12 PM, Tom Lane wrote:
"hernan gonzalez" <[EMAIL PROTECTED]> writes:
I've added an option to pg_dump to reorder
columns in the ouput "CREATE TABLE" dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your da
OK thanks for the advice.
What I'm trying to overcome is where we've got a long report running and the
process that is taking data from the main database cannot complete because
of the drop table. I believe a DELETE (and possibly TRUNCATE?) doesn't need
an exclusive lock on the table and therefore
Alvaro,
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
> I had a look at aclchk.c and didn't like your change to
> objectNamesToOids; seems rather baroque. I changed it per the attached
> patch.
I've incorporated this change.
> Moreover I didn't very much like the way aclcheck_error_col is dealing
"Rob Kirkbride" <[EMAIL PROTECTED]> writes:
> Once I'm happy with it (I'm a bit rusty at C!), do I post the patch here?
I would say you should post *before* you have a patch you're happy with. As
soon as you have a specific plan of what you want to do it's best to post an
outline of it. That way
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 25 nov. 08 à 20:29, Ron Mayer a écrit :
psql=# install module sampledb;
Downloading sampledb from pgfoundry...
Installing sampledb
Connecting to sampledb
sampledb=#
This could be part of an installer for PostgreSQL extensions. See
Dave,
Ok thanks. Yes, we've got over 1/2 billion rows in one of our tables which
is interesting!
Will post back soon.
Rob
2008/11/25 Dave Page <[EMAIL PROTECTED]>
> On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > I'm very new to hacking postgresql bu
On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm very new to hacking postgresql but am using on a very big site
> (http://ojp.nationalrail.co.uk). One of the issues that we have is moving
> data from a live database to a reports one. I've hacked an extra optio
Hi,
I'm very new to hacking postgresql but am using on a very big site (
http://ojp.nationalrail.co.uk). One of the issues that we have is moving
data from a live database to a reports one. I've hacked an extra option to
pg_dump to delete from tables rather than dropping them.
Once I'm happy with
Pavan Deolasee escribió:
> Following test case gives a warning of snapshot not destroyed at commit
> time.
>
> CREATE TABLE test (a int);
> INSERT INTO test VALUES (1);
> BEGIN;
> DECLARE c CURSOR FOR SELECT * FROM test FOR update;
> SAVEPOINT A;
> FETCH -2 FROM c;
> ROLLBACK TO SAVEPOINT A;
> COM
Dear Tom,
The issue is that when one does (in pg 8.3.5)
ALTER TABLE foo ADD CONSTRAINT xxx UNIQUE ON (...);
this results in a constraint *and* an index, but when one does only the
corresponding:
CREATE UNIQUE INDEX foo(...);
then the index is created but there is no constraint.
Fabien COELHO <[EMAIL PROTECTED]> writes:
> The issue is that when one does (in pg 8.3.5)
> ALTER TABLE foo ADD CONSTRAINT xxx UNIQUE ON (...);
> this results in a constraint *and* an index, but when one does only the
> corresponding:
> CREATE UNIQUE INDEX foo(...);
> then the index is
Dear PostgreSQL developers,
1
I stumbled upon an obscure bug (or undesirable feature:-) in the schema
metadata accessible through the information_schema, and possibly
pg_catalog as well. As it was mixed in a bug in some in my code, it was
hard for me to identify it.
The issue is that
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
>> ! putenv("PGOPTIONS=--intervalstyle=postgres_verbose");
>> So I guess the real question is what is the
>> use case for having pg_regress talk to older servers?
> There is no use. I was j
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> Hmm, that's a bit problematic because resowner.c doesn't have any global
>> notion of what resource owners exist. I think you still need to have
>> snapmgr.c maintain a list of all known snapshots. resowner.c can only
>> help you
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > After the patch we don't have any way to detect whether resowner.c has
> > any snapshot still linked to. I assume there's no objection to adding a
> > new entry point in resowner.c for this.
>
> Hmm, that's a bit problematic beca
Stephen R. van den Berg wrote:
... it would be orders of magnitude more difficult for
a novice to create the sample database from contrib or anywhere else.
It seems to me that *this* is the more serious problem that
we should fix instead.
If, from the psql command prompt I could type:
psql=#
On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
> --- 716,722
> */
> putenv("PGTZ=PST8PDT");
> putenv("PGDATESTYLE=Postgres, MDY");
> ! putenv("PGOPTIONS=--intervalstyle=postgres_verbose");
>
> if (temp_install)
> {
>
> when it struck me that
On Tuesday 25 November 2008 15:09:37 Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > While hacking on parser/gram.y just now I noticed in passing that the
> > automatically generated ecpg parser had 402 shift/reduce conflicts.
> > (Don't panic, the parser in CVS is fine.) If you
On Mon, Nov 24, 2008 at 10:25 AM, Marko Kreen <[EMAIL PROTECTED]> wrote:
> On 11/24/08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Marko Kreen" <[EMAIL PROTECTED]> writes:
>> > It was brought to my attention that DISCARD ALL
>> > does not release advisory locks:
>>
>> What is the argument that it sh
On Tue, 2008-11-25 at 19:02 +0530, Pavan Deolasee wrote:
> On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Huh? The "read only" transaction mode is not hard read-only
> anyway,
> so if that's the only step being taken, it's entirely useless.
>
Alvaro Herrera wrote:
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> After the patch we don't have any way to detect whether resowner.c has
> any snapshot still linked to. I assume there's no objection to adding a
> new entry point in resowner.c for this.
Hmm, that's a bit problematic because resowner.c doesn't have any
Alvaro Herrera escribió:
> The only thing I'm now missing is SnapshotResetXmin(). It currently
> looks like this:
> After the patch we don't have any way to detect whether resowner.c has
> any snapshot still linked to. I assume there's no objection to adding a
> new entry point in resowner.c f
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribió:
> >> I think the fundamental bug here is that you tried to skip using the
> >> ResourceOwner mechanism for snapshot references. That's basically
> >> not gonna work.
>
> > Right :-( I'll see how to go about th
>>> Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Additional processing information as discussed later in the thread
can
> now be added easily, but I think there was no consensus on what
exactly
> to print.
Since I use CLUSTER almost exclusively to eliminate bloat, I'd like to
see the before a
(I'm still downloading Fedora-10)
Even though Tom is subscribed to the list below, I thought I should
forward this e-mail to this list:
Forwarded Message
> From: Itamar - IspBrasil <[EMAIL PROTECTED]>
> Reply-To: Development discussions related to Fedora
> <[EMAIL PROTECTED]>
>
On Wed, Nov 26, 2008 at 12:23 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Fujii Masao escribió:
>> On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
>> <[EMAIL PROTECTED]> wrote:
>> > Dickson S. Guedes escribió:
>> >> Fujii Masao escreveu:
>> >>> (...)
>> Even if we need to have the databas
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One thing we should do is have pg_regress.c, not the Makefile,
>> select the default port to use. The concatenate-5 behavior is
>> just not intelligent enough.
> How about something like this, constructing a port number from the
>
I've been chewing on the problem described here:
http://archives.postgresql.org/pgsql-general/2008-11/msg01220.php
It's not particularly easy to fix without making annoyingly large
changes to the API for PQExpBuffer. The best idea I have come up
with so far goes like this:
* Upon failure to mall
Peter Eisentraut wrote:
> Tom Lane wrote:
>> One thing we should do is have pg_regress.c, not the Makefile,
>> select the default port to use. The concatenate-5 behavior is
>> just not intelligent enough.
>
> How about something like this, constructing a port number from the
> version and a time
Fujii Masao escribió:
> On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
> > Dickson S. Guedes escribió:
> >> Fujii Masao escreveu:
> >>> (...)
> Even if we need to have the database in real, I'd like to use another
> name for it. The name 'walsender' seems to
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Dickson S. Guedes escribió:
>> Fujii Masao escreveu:
>>> (...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but
Tom Lane wrote:
One thing we should do is have pg_regress.c, not the Makefile,
select the default port to use. The concatenate-5 behavior is
just not intelligent enough.
How about something like this, constructing a port number from the
version and a timestamp? We could also take 2 more bits
Hi,
In current pg_standby, the presence of the trigger file causes
recovery to end whether or not the next WAL file is available.
Thereby, some transactions in the available WAL files will be
lost. So, we cannot use this trigger file to promote the standby
to the primary.
I'd like to add new trig
I wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> (What is the use case for this variable anyway? Is it there just
>> because PGDATESTYLE was there previously?)
> Pretty much. I'd be fine with taking it out entirely.
Actually ... I started to take this out and replace
*** pgsql/src/t
Tom Lane wrote:
Better to provide the sample database in a
form in which it can be easily dropped/reloaded. I'm envisioning that
there's a source file in $sharedir and we tell people
createdb example
psql -f $sharedir/example.sql example
This is
On Tue, Nov 25, 2008 at 8:23 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>> I'm in favour of including it by default (at initdb), so it's there
>> for new users to play with on any fresh install - however, there is
>> only a point to that if all the documentati
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I played around a little with signal handling to collect the dying
> postmaster and report and error; see attached rough patch. I'm not
> exactly understanding how this works though. I would expect lots of
> psql zombies for example, because those
Dickson S. Guedes escribió:
> Fujii Masao escreveu:
>> (...)
>>> Even if we need to have the database in real, I'd like to use another
>>> name for it. The name 'walsender' seems to be an internal module name
>>> but it should be a feature name (ex. 'replication').
>>>
>>
>> Agreed. The name '
Peter Eisentraut wrote:
== removing existing temp installation==
== creating temporary installation==
== initializing database system ==
== starting postmaster
On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
>
> Huh? The "read only" transaction mode is not hard read-only anyway,
> so if that's the only step being taken, it's entirely useless.
>
>
I think there are explicit checks for some utility statements (like VACUUM),
but I ha
On Tue, Nov 25, 2008 at 1:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>> I'm in favour of including it by default (at initdb), so it's there
>> for new users to play with on any fresh install - however, there is
>> only a point to that if all the documentati
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Exporting PGINTERVALSTYLE causes errors of the following kind when
> connecting to an older server version:
> psql: FATAL: unrecognized configuration parameter "intervalstyle"
Ooops.
> (What is the use case for this variable anyway? Is it there j
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I think we should disallow starting a read-write transaction during
> recovery. The patch attempts to do that by setting transaction mode to
> read-only, but not enough to prevent somebody to explicitly mark the
> transaction as read-write.
Huh? The
"Dave Page" <[EMAIL PROTECTED]> writes:
> I'm in favour of including it by default (at initdb), so it's there
> for new users to play with on any fresh install - however, there is
> only a point to that if all the documentation examples are based on
> that database to allow copy-paste-play.
You wo
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> While hacking on parser/gram.y just now I noticed in passing that the
> automatically generated ecpg parser had 402 shift/reduce conflicts.
> (Don't panic, the parser in CVS is fine.) If you don't pay very close
> attention, it is easy to miss this
Hi ITAGAKI-san.
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
The test of my various past is reproduced. Then, I proposed the management
regarded as best in them. and, to Magnus-san.
Does the reason for persisting in wsftime exceed
Magnus Hagander wrote:
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Log Message:
---
Silence compiler warning about ignored return value. Our comment already
clearly stated that we are aware that we're ignoring it.
I think the usual way is to call the function like:
(void) functi
Exporting PGINTERVALSTYLE causes errors of the following kind when
connecting to an older server version:
psql: FATAL: unrecognized configuration parameter "intervalstyle"
Should the processing of this variable be made conditional upon the
server version?
(What is the use case for this vari
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but it should be a feature name (ex. 'replication').
Agreed. The name 'replication' is more suitable, I also think.
Any o
On Tue, Nov 25, 2008 at 7:31 PM, Dave Page <[EMAIL PROTECTED]> wrote:
> I'm in favour of including it by default (at initdb), so it's there
> for new users to play with on any fresh install ...
Could we perhaps punt on the issue of whether to install the
"sampledb" by default. It could be control
Peter Eisentraut wrote:
Here is an implementation of distinct types,
I'm withdrawing this patch from the current commit fest for further
work. For the record, I have attached the current patch, including the
documentation work by Jeff Davis.
Index: doc/src/sgml/ref/create_domain.sgml
===
Peter Eisentraut wrote:
> Looks very good, please continue.
>
Thanks, will do :)
> On your wiki page, you have this example:
>
> CREATE SERVER userdb TYPE 'plproxy_cluster'
> FOREIGN DATA WRAPPER plproxy
> OPTIONS (
> server='dbname=userdb_p0 host=127.0.0.1 port=6000',
>
While hacking on parser/gram.y just now I noticed in passing that the
automatically generated ecpg parser had 402 shift/reduce conflicts.
(Don't panic, the parser in CVS is fine.) If you don't pay very close
attention, it is easy to miss this. Considering also that we frequently
have to educa
The following sequence of commands causes server crash.
postgres=# BEGIN TRANSACTION READ WRITE ;
BEGIN
postgres=# SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during recovery
STATEMENT: SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during reco
Dave Page wrote:
>On Tue, Nov 25, 2008 at 1:42 AM, Robert Treat
><[EMAIL PROTECTED]> wrote:
>> We actually have such a database on pgfoundry already
>> (http://pgfoundry.org/frs/download.php/1719/pagila-0.10.1.zip), which i think
>> devrim may have packaged into an rpm; it wouldn't hurt to add it
On Tue, Nov 25, 2008 at 11:42 AM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> "Fujii Masao" <[EMAIL PROTECTED]> wrote:
>> On Fri, Nov 14, 2008 at 7:15 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
>> > Attached is the latest version of Synch Rep patch. Sorry for my late
>> > posting.
>> > I fixed s
"Hiroshi Saito" <[EMAIL PROTECTED]> wrote:
> Umm, format operand seems to be a wide character sequence.
Here is a patch to work around the wide character format string.
The hack is the following line:
+#define strftime(a,b,c,d) strftime_win32(a,b,L##c,d)
We use only literals in the format s
On Tue, Nov 25, 2008 at 1:42 AM, Robert Treat
<[EMAIL PROTECTED]> wrote:
>
> We actually have such a database on pgfoundry already
> (http://pgfoundry.org/frs/download.php/1719/pagila-0.10.1.zip), which i think
> devrim may have packaged into an rpm; it wouldn't hurt to add it to the win32
> instal
88 matches
Mail list logo
