Hi,
I’m trying to connect ruby to postgres on ubuntu and the only link I found
that has the library is down. Does anyone have the postgres library for
ruby? Or direct me to it?
You would be better off searching for the drivers on rubyforge.org. Please
do not send non-Postgres-development
Greg Stark wrote:
On Sat, May 30, 2009 at 1:11 PM, Bruce Momjian br...@momjian.us wrote:
I have discovered a simpler solution using ALTER TABLE and calling a
conversion function:
? ? ? ?test= CREATE TABLE tsvector_test(x tsvector);
? ? ? ?CREATE TABLE
? ? ? ?test= ALTER TABLE
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have discovered a simpler solution using ALTER TABLE and calling a
conversion function:
test= CREATE TABLE tsvector_test(x tsvector);
CREATE TABLE
test= ALTER TABLE tsvector_test ALTER COLUMN x
On Sun, May 31, 2009 at 3:04 PM, Bruce Momjian br...@momjian.us wrote:
I think this is basically a large-caliber foot gun. You're going to
pretend that invalid data is valid, until the user gets around to fixing
it?
What choice do we have?
I think in this case the caliber is pretty small
Peter Eisentraut pete...@gmx.net writes:
On Friday 22 May 2009 18:27:01 Konstantin Izmailov wrote:
[ discussion of some details of information_schema results ]
Are we going to do anything about any of these issues?
In particular,
6. datetime_precision field, minor changes
Code around:
Dimitri Fontaine dfonta...@hi-media.com writes:
Dimitri Fontaine dfonta...@hi-media.com writes:
And currently calling SPI_connect() from _PG_init will crash the
backend. I'll try to obtain a gdb backtrace, I've just been told about
pre_auth_delay and post_auth_delay parameters.
Here we go:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is a patch to fix the bug. I added a parameter 'encode' to
map_sql_value_to_xml_value() and pass false for xml attributes.
One thing I was wondering about, which is sort of highlighted by your
patch, is why is there the special
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we could check for the existence of the
PG_VERSION file
* Andrew Dunstan (and...@dunslane.net) wrote:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we
Andrew Dunstan and...@dunslane.net writes:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup. Maybe we could
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I am in the middle of helping a customer recover from a situation where
a tablespace was missing when a machine was rebooted and postgres
restarted, and I'm wondering if we should not have some sort of check
for this on startup.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
... and do what?
In general, I think I'd probably prefer normal database startup to fail
if a tablespace is missing. That way I will know about it right then and
can remedy it. This is something that is much more likely to happen
Tom Lane wrote:
So what you're imagining is
* iterate through each symlink in $PGDATA/pg_tblspc
* check that PG_VERSION exists (and has the right contents??) in
each pointed-to directory
* fail if not
I guess this is reasonable, since we make a similar check for the core
data directory
Andrew Dunstan and...@dunslane.net writes:
I'm not sure about the initdb reference - there won't be any tablespaces
to check for during initdb, will there?
No, but I think pg_tblspc/ itself might not be there either. Just a
case to test your patch on ...
regards, tom
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I'm not sure about the initdb reference - there won't be any tablespaces
to check for during initdb, will there?
No, but I think pg_tblspc/ itself might not be there either. Just a
case to test your patch on ...
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace when missing?
and I'm wondering if we should not have some sort of check for this
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace went missing?
and I'm wondering if we should not have some sort of check for this
Tom Lane wrote:
It's hard to review it without any docs that say what it's supposed to do.
(And you'd need to patch the docs anyway, eh?)
Fair enough :-)
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
Andrew Chernow wrote:
Andrew Dunstan wrote:
I am in the middle of helping a customer recover from a situation
where a tablespace was missing when a machine was rebooted and
postgres restarted,
Have you uncovered why the tablespace went missing?
No. It's on a SAN, and I understand our
Hi,
First, thank you to have taken the time to see about the case.
Le 31 mai 09 à 18:21, Tom Lane a écrit :
The reason this doesn't work is that SPI can only be invoked inside a
transaction, and you're not inside one when a library is being
preloaded.
Makes sense. Still crashing with basic
Joshua Tolley eggyk...@gmail.com writes:
On Thu, May 28, 2009 at 06:28:14PM -0400, Tom Lane wrote:
Read 26.4.3 and .4. I don't know why they have this bizarre set of
conventions, but the single-hyphen version is the spelling
most visible to end users.
I thought it might be something like
Anyway, from this POV all we really need to know is that the device
hosting this tablespace failed to mount when the machine was rebooted,
and then postgres restarted.
Good to know postgresql had nothing to do with the missing data. I
wasn't sure if it was user error, config problem or
Greg,
What's the point of namespaces if not to implement visibility? The
interesting thing to do would be to hide all the internal foo
functions in a foo.* schema and only put the external api in public.
That is an interesting idea. However, what our real users are really
doing in the field
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have discovered a simpler solution using ALTER TABLE and calling a
conversion function:
test= CREATE TABLE tsvector_test(x tsvector);
CREATE TABLE
Sebastien FLAESCH s...@4js.com writes:
I would expect that an INTERVAL SECOND can store more that 59 seconds.
I took a look into the SQL spec and I think that we do indeed have a
spec compliance issue here. SQL99 section 4.7 saith
Within a value of type interval, the first field is
As I mentioned a bit ago
http://archives.postgresql.org/pgsql-hackers/2009-05/msg01505.php
there seems to be a definite problem still remaining with our handling
of interval literals. To wit, this behavior is absolutely not per spec:
regression=# select '999'::interval second;
interval
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus j...@agliodbs.com wrote:
This assumes that all users should have access to the same public APIs as
all other users. Real applications are more complex.
Well the goal is to make them simpler. I don't know any language that
has implemented what you
On May 31, 2009, at 3:47 PM, Greg Stark wrote:
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus j...@agliodbs.com
wrote:
This assumes that all users should have access to the same public
APIs as
all other users. Real applications are more complex.
Well the goal is to make them simpler. I
I wrote:
In a related example,
regression=# select interval '123 11' day;
interval
--
134 days
(1 row)
we seem to be adding the 123 and 11 together. This is, um,
surprising behavior ... I'd be inclined to think throwing an
error is more appropriate.
I looked into
Hi all,
I ran a few more tests changing the table blocksizes, similar to:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg01068.php
I did make one change, specifically enable autovacuum, which I had
disabled for the previous thread. The WAL blocksize here is using
16KB.
Here's the
Tom Lane wrote:
It's hard to review it without any docs that say what it's supposed to do.
(And you'd need to patch the docs anyway, eh?)
Here's a much simpler SQL/MED support patch for dblink.
This enforces security in the same manner for FOREIGN SERVER connections
as that worked out over
I just downloaded PostgreSQL 8.4 beta 2 and tried to restore my old database
from version 8.3. I created a new database with the same name as my old one.
Then when I tried to restore the old database I got the error posted below.
I'm running Windows 7 RC. I realize that probably isn't
pg_migrator needs hard link() capabiity on Win32 to support its --link
option. Can someone create that and hopefully add it to libpgport?
libpgport currently only has symlink capability for Win32.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Sun, May 31, 2009 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd prefer to avoid a catversion bump at this stage of the cycle,
but it looks like any changes here would merely involve the bodies of
some functions in information_schema.sql. I think we could just change
them without a
Robert Haas robertmh...@gmail.com writes:
Is this a regression relative to 8.3? If not, why not leave it for
8.5?
No. it's not a regression. What I was concerned about was mainly that
it seemed likely to drop off the radar screen without being addressed at
all, since most of the other things
Bruce Momjian br...@momjian.us writes:
pg_migrator needs hard link() capabiity on Win32 to support its --link
option. Can someone create that and hopefully add it to libpgport?
AFAIK hard links simply don't exist on Windows.
regards, tom lane
--
Sent via
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
pg_migrator needs hard link() capabiity on Win32 to support its --link
option. Can someone create that and hopefully add it to libpgport?
AFAIK hard links simply don't exist on Windows.
Magnus showed me this:
Bruce Momjian br...@momjian.us wrote:
pg_migrator needs hard link() capabiity on Win32 to support its --link
option. Can someone create that and hopefully add it to libpgport?
libpgport currently only has symlink capability for Win32.
Can we use CreateHardLink() ?
On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian br...@momjian.us wrote:
The way the restore works, you would have to call the data type
'tsvector', and then that oid is linked around in all sort of odd places
and you need to change them all, hence confusion.
In theory, I think it would be
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
AFAIK hard links simply don't exist on Windows.
Magnus showed me this:
http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
Hmm, interesting. Are we requiring our DBs to be on NTFS already?
What are the implications for
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
AFAIK hard links simply don't exist on Windows.
Magnus showed me this:
http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
Hmm, interesting. Are we requiring our DBs to be on NTFS already?
I think
Robert Haas wrote:
On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian br...@momjian.us wrote:
The way the restore works, you would have to call the data type
'tsvector', and then that oid is linked around in all sort of odd places
and you need to change them all, hence confusion.
In theory,
Robert Haas robertmh...@gmail.com writes:
(At the risk of beating a dead horse, note if we were upgrading the
catalog tables directly via SQL, this type of scenario could be
handled cleanly without hacking pg_dump; I repeat my earlier critique
that the pg_migrator approach consigns us to a
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Hmm, interesting. Are we requiring our DBs to be on NTFS already?
Oh, yea, we only support tablespaces on Win32 using NTFS.
Well, the important point there is that we fail gracefully if you try to
use tablespaces when not on NTFS. So
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Hmm, interesting. Are we requiring our DBs to be on NTFS already?
Oh, yea, we only support tablespaces on Win32 using NTFS.
Well, the important point there is that we fail gracefully if you try to
use tablespaces
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(Come to think of it, --link can fail on Unix too, if the user tries to
put the new database on a different filesystem. Have you got guards in
there to make sure this is discovered before the point of no return?)
Of course:
...
though
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
AFAIK hard links simply don't exist on Windows.
Magnus showed me this:
http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
Hmm, interesting. Are we requiring our DBs to be
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(Come to think of it, --link can fail on Unix too, if the user tries to
put the new database on a different filesystem. Have you got guards in
there to make sure this is discovered before the point of no return?)
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
(Come to think of it, --link can fail on Unix too, if the user tries to
put the new database on a different filesystem. Have you got guards in
there to make sure this is discovered before
Hi,
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
1) pg_standby creates the symlink to the archived file '102'
2) '102' is applied
3) the next file '103' doesn't exist and the trigger file is created
4) '102' is re-fetched
5) at the
50 matches
Mail list logo
