On Sat, Oct 16, 2010 at 12:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
But they cannot
detect the disconnection in some cases. So replication_timeout needs
to be introduced for sync rep.
When exactly don't the keepalives work?
The keepalives don't work at least on linux when the
On Thu, Oct 14, 2010 at 8:23 AM, fazool mein fazoolm...@gmail.com wrote:
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same time
Fujii Masao masao.fu...@gmail.com writes:
But, even though we will have done that, it should be noted that WAL in
A might be ahead of that in B. For example, A might crash right after
writing WAL to the disk and before sending it to B. So when we restart
the old master A as the standby after
(2010/10/14 1:52), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lanet...@sss.pgh.pa.us wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your end to create and
On Sun, Oct 17, 2010 at 5:18 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
Reading your proposal, I'm now +1 for BSON-like style. Especially JS
engine's capabilities to map external data to the language
representation are good news.
Hmm, we could store postgres' data types as-is with their
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer either the Oid of a custom type or an array of
Oid, Datum pairs - i.e.
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas robertmh...@gmail.com wrote:
No doubt. The problem is that we're going to end up with those bells
and whistles in two places: in to_char or other type-specific
formatting functions, and again in format.
If we decide to use C-like sprintf(), I think
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
- Bugs to fix
There's at least one where drop extension leaves things behind,
although it uses performDeletion(). The dependencies are fine enough
so that the leftover objects are not part of the dump done before to
drop, though.
2010/10/18 Itagaki Takahiro itagaki.takah...@gmail.com:
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas robertmh...@gmail.com wrote:
No doubt. The problem is that we're going to end up with those bells
and whistles in two places: in to_char or other type-specific
formatting functions, and again
On Mon, Oct 18, 2010 at 5:02 AM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
Just to give one example of what this patch misses (probably; as I said
I haven't read it lately), what about selectivity estimation? One of
the things we like to do when we have an otherwise-unknown function is
to try
On Mon, Oct 18, 2010 at 11:41:06AM +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer
On Sun, Oct 3, 2010 at 9:53 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
Whoops...seems there was some minor mangling when I applied the
original patch by:
pe...@linux-peter-home:~/postgresql patch --version
GNU patch 2.6.1.81-5b68
snip***
pe...@linux-peter-home:~/postgresql
I think that MERGE is supposed to trigger one rule for each row in the
source data. So:
On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith g...@2ndquadrant.com wrote:
MERGE INTO Stock t
USING (SELECT * FROM Stock WHERE item_id=10) AS s
ON s.item_id=t.item_id
WHEN MATCHED THEN UPDATE SET
On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
I've asked pgsql-general.
Unfortunately it seems that there is no better way to do it except
parsing PQerrorMessage(). Sadly.
Yeah, doesn't look like it. A quick glance at the code reveals that a
PGresult can store
On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
I've asked pgsql-general.
Unfortunately it seems that there is no better way to do it except
parsing PQerrorMessage(). Sadly.
Yeah, doesn't look like
On Mon, Oct 18, 2010 at 9:54 PM, Robert Haas robertmh...@gmail.com wrote:
I think that MERGE is supposed to trigger one rule for each row in the
source data. So:
On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith g...@2ndquadrant.com wrote:
MERGE INTO Stock t
USING (SELECT * FROM Stock WHERE
On 10/17/2010 03:56 PM, Tom Lane wrote:
[clever scheme to treat even numbered enum Oids as sorted]
The one problem I can see with this is that it's only partially
on-disk-compatible with existing enum types: it'll almost certainly
think that they require slow comparison, even when they
2010/10/17 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/10/15 22:04), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
However, it requires the plugin modules need to know everything;
such as what is visible/invisible. It seems to me too closely-
coupled interface.
I
On Mon, Oct 18, 2010 at 10:09 AM, Boxuan Zhai bxzhai2...@gmail.com wrote:
On Mon, Oct 18, 2010 at 9:54 PM, Robert Haas robertmh...@gmail.com wrote:
I think that MERGE is supposed to trigger one rule for each row in the
source data. So:
On Sun, Oct 17, 2010 at 8:20 PM, Greg Smith
On Mon, Oct 18, 2010 at 10:05 AM, David Fetter da...@fetter.org wrote:
On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
I've asked pgsql-general.
Unfortunately it seems that there is no better way to do it
On Mon, Oct 18, 2010 at 10:18:25AM -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 10:05 AM, David Fetter da...@fetter.org wrote:
On Mon, Oct 18, 2010 at 10:03:55AM -0400, Robert Haas wrote:
On Sun, Oct 17, 2010 at 2:03 AM, Dmitriy Igrishin dmit...@gmail.com
wrote:
I've asked
On Fri, Oct 15, 2010 at 3:49 PM, Josh Kupershmidt schmi...@gmail.com wrote:
[Moving to -hackers]
On Fri, Oct 15, 2010 at 3:43 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-10-11 at 09:41 -0400, Josh Kupershmidt wrote:
On Thu, Oct 7, 2010 at 7:43 PM, Josh Kupershmidt
On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas robertmh...@gmail.com wrote:
No doubt. The problem is that we're going to end up with those bells
and whistles in two places: in to_char or other type-specific
On Mon, Oct 18, 2010 at 10:27 AM, Robert Haas robertmh...@gmail.com wrote:
Please add this to
https://commitfest.postgresql.org/action/commitfest_view/open
I want to look at this at some point, but we still have over a dozen
patches from the current CF to deal with.
Added at
Andrew Dunstan and...@dunslane.net writes:
On 10/17/2010 03:56 PM, Tom Lane wrote:
[clever scheme to treat even numbered enum Oids as sorted]
The one problem I can see with this is that it's only partially
on-disk-compatible with existing enum types: it'll almost certainly
think that they
I may be in the minority here, but I'm inclined to just apply this and
move on. I agree with your concerns that this whole module is badly
designed and that the approach of hard-coding the list of ISBN ranges
is fundamentally unscalable, but unless we're going to rip it out or
rearchitect
David Fetter wrote:
For my vote, I'd prefer either the Oid of a custom type or an array
of Oid, Datum pairs - i.e. something we can extend in the future if
required.
This sounds a lot like a foreign key to another table. Are you not
proposing doing that because of performance considerations?
Peter Geoghegan peter.geoghega...@gmail.com writes:
I may be in the minority here, but I'm inclined to just apply this and
move on. I agree with your concerns that this whole module is badly
designed and that the approach of hard-coding the list of ISBN ranges
is fundamentally unscalable, but
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
postg...@db01:~ less /opt/pg/data/jnj_indexes/PG_VERSION
8.4
postg...@db01:~ /opt/pg91/bin/psql -p 5433
psql (9.0.1)
Type help for help.
postgres=# select version();
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
postg...@db01:~ less /opt/pg/data/jnj_indexes/PG_VERSION
8.4
postg...@db01:~
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
I suspect this behavior is partially intentional, because tablespace
creation now involves an extra level of subdirectory. However, it's
On Mon, Oct 18, 2010 at 11:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan peter.geoghega...@gmail.com writes:
I may be in the minority here, but I'm inclined to just apply this and
move on. I agree with your concerns that this whole module is badly
designed and that the approach of
On Mon, Oct 18, 2010 at 12:03 AM, Fujii Masao masao.fu...@gmail.com wrote:
The keepalives don't work at least on linux when the connection is terminated
after sending a packet and before receiving TCP-level ACK. You can confirm
this by unplugging the LAN cable from a client server while running
I like as simple design as we can accept. ISTM format, I/O interface,
simple get/set, mapping tuple from/to object, and indexing are minimum
requirement.
+1 to small start, but simple get/set are already debatable...
For example, text/json conversion:
A. SELECT 'json'::json;
B. SELECT
2010/10/18, Robert Haas robertmh...@gmail.com:
On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas robertmh...@gmail.com
wrote:
No doubt. The problem is that we're going to end up with those bells
and whistles in
On 18 October 2010 16:17, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I was hoping for some independent validation that the
proposed changes match current reality in ISN-land. But apparently
no one actually wants to repeat the research, so we might as well just
take the changes on faith.
Andrew Dunstan and...@dunslane.net writes:
On 10/17/2010 04:40 PM, Tom Lane wrote:
... That's assuming that we think there are
no users who are depending on float timestamps for functionality (they
have a wider range than int timestamps don't they?).
Yes, they do.
Maybe we need to look at
On 10/18/2010 10:52 AM, Tom Lane wrote:
We could possibly deal with enum types that follow the existing
convention if we made the cache entry hold a list of all the original,
known-to-be-sorted OIDs. (This could be reasonably compact and cheap to
probe if it were represented as a starting OID
On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
I suspect this behavior is partially intentional, because tablespace
Andrew Dunstan and...@dunslane.net writes:
On 10/18/2010 10:52 AM, Tom Lane wrote:
We could possibly deal with enum types that follow the existing
convention if we made the cache entry hold a list of all the original,
known-to-be-sorted OIDs. (This could be reasonably compact and cheap to
On 18 October 2010 15:52, Tom Lane t...@sss.pgh.pa.us wrote:
So I'm thinking the comparison procedure goes like this:
1. Both OIDs even?
If so, just compare them numerically, and we're done.
2. Lookup cache entry for enum type.
3. Both OIDs in list of known-sorted OIDs?
If
On Mon, Oct 18, 2010 at 1:07 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/10/18, Robert Haas robertmh...@gmail.com:
On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas robertmh...@gmail.com
wrote:
No doubt.
Dean Rasheed dean.a.rash...@gmail.com writes:
I think the hash map lookups could be made pretty quick, if we're
prepared to write a bit of dedicated code there rather than relying on
the more general-purpose caching code.
It's still going to be very significantly slower than what I'm
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible
On 10/18/2010 01:40 PM, Dean Rasheed wrote:
On 18 October 2010 15:52, Tom Lanet...@sss.pgh.pa.us wrote:
So I'm thinking the comparison procedure goes like this:
1. Both OIDs even?
If so, just compare them numerically, and we're done.
2. Lookup cache entry for enum type.
3. Both
Robert Haas robertmh...@gmail.com writes:
I may be in the minority here, but I'm inclined to just apply this and
move on.
FWIW, I agree with applying the code patch as-is, but I think we need to
consider the documentation. Specifically:
1. The first para of
I believe we should come up with a universal solution that will solve
potential future problems as well (for example, if in sync replication, we
decide to send writes to standbys in parallel to writing on local disk).
The ideal thing would be to have an id that is incremented on every failure,
2010/10/18 Bruce Momjian br...@momjian.us:
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
Yes, still probably something we partially visit with global temp
table thread from Robert Haas...
Having
Bruce Momjian br...@momjian.us writes:
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
Not unless you have some credible concept for how it might ever be
implemented. You can't create temp tables
On Mon, Oct 18, 2010 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IOW I don't think the range argument holds much water for keeping float
timestamps alive. The on-disk-compatibility argument does, though.
Right. I think your argument that we should do nothing upthread is
exactly right.
Andrew Dunstan and...@dunslane.net writes:
If you have want to work on it and prove it's going to be better, please
do. I'm not convinced it will do a whole lot better than a binary search
that in most cases will do no more than a handful of probes.
Yeah, that's a good point. There's a
Dave Cramer wrote:
On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
I suspect this behavior is partially
On Mon, Oct 18, 2010 at 1:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I may be in the minority here, but I'm inclined to just apply this and
move on.
FWIW, I agree with applying the code patch as-is, but I think we need to
consider the documentation.
On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian br...@momjian.us wrote:
Dave Cramer wrote:
On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than
Alvaro Herrera wrote:
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
postg...@db01:~ less /opt/pg/data/jnj_indexes/PG_VERSION
8.4
First off, thanks for the review! I know that it's a lot of work,
and I do appreciate it.
Jeff Davis pg...@j-davis.com wrote:
* Trivial stuff:
I get a compiler warning:
indexfsm.c: In function *RecordFreeIndexPage*:
indexfsm.c:55: warning: implicit declaration of function
Tom Lane wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
I suspect this behavior is partially intentional, because tablespace
creation now involves an extra level of
Robert Haas wrote:
On Mon, Oct 18, 2010 at 2:17 PM, Bruce Momjian br...@momjian.us wrote:
Dave Cramer wrote:
On Mon, Oct 18, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
On Mon, 2010-10-18 at 14:06 -0400, Robert Haas wrote:
Right. I think your argument that we should do nothing upthread is
exactly right.
OK.
A more interesting question is whether and how we can ease the
migration path from float timestamps to integer timestamps. Even
without range types,
On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
Dave Cramer wrote:
On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
as seen below create tablespace does not throw an error or appear to
do anything other than
On Mon, Oct 18, 2010 at 2:39 PM, Bruce Momjian br...@momjian.us wrote:
Dave Cramer wrote:
On Mon, Oct 18, 2010 at 2:20 PM, Bruce Momjian br...@momjian.us wrote:
Alvaro Herrera wrote:
Hi Dave,
Excerpts from Dave Cramer's message of lun oct 18 12:23:40 -0300 2010:
as seen below create
Robert Haas robertmh...@gmail.com writes:
A more interesting question is whether and how we can ease the
migration path from float timestamps to integer timestamps. Even
without range types, if someone does have a UNIQUE index on a
timestamp column, could they get an error if they dump from a
Dave Cramer wrote:
postgres=# select version();
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? version
---
?PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled
Dave Cramer wrote:
IIRC the reason this works is that the tablespace code now creates a
version-specific subdirectory inside the specified directory. ?This was
done to help binary upgrades.
Right, the directory is catalog-version named, which was done to allow
for pg_upgrade to
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I suspect this behavior is partially intentional, because tablespace
creation now involves an extra level of subdirectory. However, it's
not clear to me why CREATE TABLESPACE is still changing the permissions
on the parent directory.
On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis pg...@j-davis.com wrote:
A reasonable conversion path might be to offer integer timestamps using
a different type name (e.g. inttimestamp) that always means integer
timestamps. Then, they could convert using ALTER TABLE, then do an
in-place upgrade.
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than the documentation.
We can't fix the behavior because we have to allow an old cluster to
keep its tablespace files during a pg_upgrade. They are given a script
to delete those files
On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than the documentation.
We can't fix the behavior because we have to allow an old cluster to
keep its tablespace files
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I suspect this behavior is partially intentional, because tablespace
creation now involves an extra level of subdirectory. However, it's
not clear to me why CREATE TABLESPACE is still changing the permissions
on the
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than the documentation.
We can't fix the behavior because we have to allow an old cluster to
keep its tablespace files during a pg_upgrade. They are given a script
to
Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than the documentation.
We can't fix the behavior because we have to allow an old cluster to
keep
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than the documentation.
We
Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Perhaps we should fix the behavior rather than
On Monday 18 October 2010 20:06:01 Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
Not unless you have some credible concept for how it
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
I haven't yet been convinced we need or want to relax the rule about
the directory being empty.
Uh, how would pg_upgrade work then? It would require renaming
Andres Freund and...@anarazel.de writes:
On Monday 18 October 2010 20:06:01 Tom Lane wrote:
Not unless you have some credible concept for how it might ever be
implemented. You can't create temp tables because you can't modify
system catalogs, and if you did somehow create them you couldn't
On Mon, 2010-10-18 at 14:49 -0400, Tom Lane wrote:
whereas an int-timestamp build sees these inputs as all the same.
Thus, to get into trouble you'd need to have a unique index on data that
conflicts at the microsecond scale but not at the tenth-of-a-microsecond
scale. This seems implausible.
On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:05 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
I haven't yet been convinced we need or want to relax the rule about
the directory being
On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
On Monday 18 October 2010 20:06:01 Tom Lane wrote:
Not unless you have some credible concept for how it might ever be
implemented. You can't create temp tables because you can't modify
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy. As a general matter though, a bytea?
P
For my vote, I'd prefer
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive enough beast that just having 64-bits would make me
happy.
On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what kind of data structure would you like for a typmod?
I'm a primitive
On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 15:36 -0400, Robert Haas wrote:
On Mon, Oct 18, 2010 at 3:33 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-18 at 11:41 +0100, Mark Cave-Ayland wrote:
Paul Ramsey wrote:
So what
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the use of the version-numbered subdirectory, I see no real merit
in insisting that the parent directory be empty anyway. It'd be
precisely analogous to initdb -D /foo/bar/data
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
Hm. Wouldnt it be possible to use virtual xids for that purpose? They are
never seen outside of that session anyway...
Well, maybe, but then
Tom Lane wrote:
Yeah. We have gotten complaints in the past from people who tried to
specify a mount point as a tablespace, and it failed because of
lost+found or the mount dir being root-owned. We've told them to make a
subdirectory, but that always seemed like a workaround. With the new
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:40 PM, Peter Eisentraut pete...@gmx.net wrote:
Frankly, I have no idea what knngist has to do with any of this, as I
haven't followed that topic at all.
Me neither, except for the fact that the PostGIS guys are interested
in
On Mon, 2010-10-18 at 13:26 -0500, Kevin Grittner wrote:
2. I think there's a GiST bug (illustrating with PERIOD type):
My assumptions for GiST were that:
(1) A search for a matching value could bail out at any level in the
tree; there is no requirement for the search to proceed to the
On Mon, Oct 18, 2010 at 3:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@anarazel.de writes:
Hm. Wouldnt it be possible to use virtual xids for that purpose? They are
On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas robertmh...@gmail.com wrote:
It'd be kinda cool if we had it, but the work required to get there
seems far out of proportion to the benefits ...
I agree. I think that's backing into the problem from the wrong end.
The limiting factor here is that
Hi everyone! Did anyone had a chance to use PL/JS for sp development? Im
working on app that uses JS to work with data and was wandering whether PL/JS
can offer full data management functionality like PL/PgSLQ?
Thanks.
Greg.
Robert asked me to write this up, so here it is.
It is critical that we make replication easier to set up, administrate
and monitor than it currently is. In my conversations with people, this
is more important to our users and the adoption of PostgreSQL than
synchronous replication is.
Hackers,
What purpose is served, exactly, by max_wal_senders?
In order for a standby to connect, it must have a superuser login, and
replication connections must be enabled in pg_hba.conf. How is having
one more setting in one more file you have to enable on the master
benefitting anyone?
Is there a pl/js yet? I've not been able to find anything but was thinking
about putting something together based on v8 or spidermonkey.
Terry
Sent from my iPhone
On Oct 18, 2010, at 4:27 PM, Greg grigo...@yahoo.co.uk wrote:
Hi everyone! Did anyone had a chance to use PL/JS for sp
Excerpts from Terri Laurenzo's message of lun oct 18 21:04:36 -0300 2010:
Is there a pl/js yet? I've not been able to find anything but was thinking
about putting something together based on v8 or spidermonkey.
http://code.google.com/p/plv8js/
--
Álvaro Herrera alvhe...@commandprompt.com
On Tue, Oct 19, 2010 at 9:04 AM, Terri Laurenzo t...@laurenzo.org wrote:
Is there a pl/js yet? I've not been able to find anything
but was thinking about putting something together based on v8 or spidermonkey.
I'm working on PL/v8, that is one of PL/JS (PL/JavaScript)
implementation based on
bruce wrote:
Tom Lane wrote:
Dave Cramer p...@fastcrypt.com writes:
as seen below create tablespace does not throw an error or appear to
do anything other than register the tablespace.
I suspect this behavior is partially intentional, because tablespace
creation now involves an
Bruce Momjian br...@momjian.us writes:
Looking at the pg_upgrade code some more, I found that it was not
removing the PG_VERSION file when deleting = 8.4 tablespace files.
This might confuse administrators so the attached patch adds the removal
of PG_VERSION. I would like to apply this to
Euler Taveira de Oliveira wrote:
Hi,
Is there any reason the postmaster.pid and external_pid_file contents to be
different?
No, the external_pid_file option is only to create an additional pid
file in a new location.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
1 - 100 of 107 matches
Mail list logo
