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 e
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 t
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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
Bruce Momjian 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 you ha
Tom Lane wrote:
> Bruce Momjian 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 whe
Bruce Momjian 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 you're going
Robert Haas 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 never-ending series o
Robert Haas wrote:
> On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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 we re
Bruce Momjian 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 Cygwin?
On Sat, May 30, 2009 at 11:58 PM, Bruce Momjian 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 possible to hack a
Bruce Momjian 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() ?
http://msdn.microsoft.com/en-us/library
Tom Lane wrote:
> Bruce Momjian 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:
http://msdn.microsoft.co
Bruce Momjian 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 pgsql-hackers mailing list
Robert Haas 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 Konstantin complaine
On Sun, May 31, 2009 at 11:41 AM, Tom Lane 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 catversion bump.
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 http://momjian.us
EnterpriseDB http://en
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 suppor
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 ti
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 data
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
On May 31, 2009, at 3:47 PM, Greg Stark wrote:
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus
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 langua
On Sun, May 31, 2009 at 9:12 PM, Josh Berkus 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 describe. Either y
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
Sebastien FLAESCH 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 constrained
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > I have discovered a simpler solution using ALTER TABLE and calling a
> > > > conversion function:
> > >
> > > > test=> CREATE TABLE tsvector_test(x tsvector);
> > > > CREATE TABLE
>
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 fiel
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 hard
Joshua Tolley 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 that. I've be
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 na
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 ha
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:
http://archives.po
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 o
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 o
Tom Lane wrote:
Andrew Dunstan 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 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 lane
--
Sent via
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 itse
Andrew Dunstan 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 than
> an arbi
Tom Lane wrote:
Andrew Dunstan 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 check
Andrew Dunstan 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 check for the existe
* 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 c
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 or
Itagaki Takahiro 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 exception for XML type in the
exist
Dimitri Fontaine writes:
> Dimitri Fontaine 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:
The reason this doesn't work is that
Peter Eisentraut 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: change valu
On Sun, May 31, 2009 at 3:04 PM, Bruce Momjian 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 and
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 COL
Greg Stark wrote:
> On Sat, May 30, 2009 at 1:11 PM, Bruce Momjian 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 tsvector_t
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-developm
50 matches
Mail list logo
