Hi,
I have encountered strange errors while testing PostgreSQL 8.4 beta2.
SELECT msg_sid FROM msginfo WHERE plainto_tsquery(E'test') @@
body_index;
or
SELECT msg_sid FROM msginfo WHERE to_tsquery(E'test') @@ body_index;
produces following errors:
ERROR: tuple offset out of range: 0
(occasional
Hi,
On Tue, Jun 2, 2009 at 3:40 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane wrote:
>>>
>>> Fujii Masao writes:
Yes, the old xlog itself is not used again. But, the *old file* might
be recycled and used later. The case that I'
On 6/1/09, Markus Wanner wrote:
> a newish conversion with cvs2git is available to check here:
>
> git://www.bluegap.ch/
>
> (it's not incremental and will only stay for a few days)
+1 for the idea of replacing CVS usernames with full names.
The knowledge about CVS usernames will be increasi
Fujii Masao wrote:
On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane wrote:
Fujii Masao writes:
Yes, the old xlog itself is not used again. But, the *old file* might
be recycled and used later. The case that I'm looking at is that the
symlink to a temporary area is recycled. Am I missing something?
On Mon, 1 Jun 2009, Robert Haas wrote:
Regarding this item:
* Consider reverting preventing regular users from base type creation
You raise this point:
tgl says: whether or not we think PL/Java is bulletproof, there are
other problems, for instance this one
http://archives.postgresql.org/me
Currently, I'm seeing the psecure_{red,write} functions being invoked
when connecting to postgres via a unix domain socket. psecure_write
seems to alter the signal mask of the process to disable sigpipe
reporting. psecure_read only does this when the connection is using SSL.
When using a multithre
If the connection isn't over SSL, there's no need to do the disable.
This effectively halves the number of syscalls performed by libpq when
SSL is not in use.
Signed-off-by: Jeremy Kerr
---
src/interfaces/libpq/fe-secure.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff -
On Mon, Jun 1, 2009 at 12:32 PM, Tom Lane wrote:
> As of today we are three months behind the original plan for 8.4.0 release.
> In a one-year release cycle that's already pretty bad slip; but there now
> seems no chance of a release happening in less than a month, and if we
> continue to let thin
On Mon, Jun 1, 2009 at 3:34 PM, Selena Deckelmann wrote:
> In the spirit of helping wrap-up 8.4 todo items...
> Robert Haas wrote:
>> For 8.4, I'd be happy to just improve the documentation. I think this
>> sentence could just be deleted from the section on
>> from_collapse_limit:
> My vote would
Euler Taveira de Oliveira wrote:
> Robert Haas escreveu:
>> ...EXPLAIN ANALYZE reports the number of rows as an integer... Any
>> chance we could reconsider this decision? I often find myself wanting
>> to know the value that is here called ntuples, but rounding
>> ntuples/nloops off to the neare
Tom Lane wrote:
Joe Conway writes:
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
http://archives.postgresql.org/message-id/28719.1230996...@sss.pgh.pa.us
This looks sane to me in a quick once-over, though I've not test
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Tom Lane wrote:
>>> I think what this suggests is that there probably needs to be some
>>> encoding conversion logic near the places we examine localeconv()
>>> output.
>
>> Attached is a patch to the current CVS.
>> It uses a similar way like LC_TIME st
Hi,
On Tue, Jun 2, 2009 at 10:21 AM, Tom Lane wrote:
> Fujii Masao writes:
>> Yes, the old xlog itself is not used again. But, the *old file* might
>> be recycled and used later. The case that I'm looking at is that the
>> symlink to a temporary area is recycled. Am I missing something?
>
> Actu
"Joshua D. Drake" writes:
> On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
>> # adjust information_schema precision and scale fields?
>> -- save for 8.5
> I read this thread. It seems for the changes we can make we should just
> make them. The actual amount of change is actually very nomi
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
>> Actually I'm hoping that Kevin Grittner will have something to
>> report on that one soon
> So far, I haven't found any performance regressions in the
Sushant Sinha wrote:
> I think that dot should be considered by as a word delimiter because
> when dot is not followed by a space, most of the time it is an error
> in typing. Beside they are not many valid english words that have
> dot in between.
It's not treating it as an English word, but
Fujii Masao writes:
> Yes, the old xlog itself is not used again. But, the *old file* might
> be recycled and used later. The case that I'm looking at is that the
> symlink to a temporary area is recycled. Am I missing something?
Actually, I think the right fix for that would be to add defenses t
Joe Conway writes:
> 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 time for other dblink connections. Essentially,
> the FOREIGN SERVER and associated user MAPPING provides the needed
Hi,
On Tue, Jun 2, 2009 at 10:00 AM, Tom Lane wrote:
> Fujii Masao writes:
>> If so, it might be deleted after triggering the warm-standby. But, we cannot
>> remove it because the latest xlog file which is required for normal recovery
>> might exist in it. This is another undesirable scenario. I
Joe Conway writes:
> Probably better if I break this up in logical chunks too. This patch
> only addresses the refactoring you requested here:
> http://archives.postgresql.org/message-id/28719.1230996...@sss.pgh.pa.us
This looks sane to me in a quick once-over, though I've not tested it.
A smal
Fujii Masao writes:
> If so, it might be deleted after triggering the warm-standby. But, we cannot
> remove it because the latest xlog file which is required for normal recovery
> might exist in it. This is another undesirable scenario. Is this problem?
What recovery? In the problem case you're
Robert Haas writes:
> More to the point, it's also what 8.3.7 does:
Well, no, because the cases at issue are where an
is specified. 8.3 did this:
regression=# select '99 seconds'::interval second;
interval
--
00:00:39
(1 row)
and even more amusingly,
regression=# select interval '
On Mon, Jun 1, 2009 at 8:04 PM, Tom Lane wrote:
> I wrote:
>> Sam Mason writes:
>>> On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
There is some case to be made that we should throw error here,
which we could do by putting error tests where the attached patch
has comment
Hi,
On Mon, Jun 1, 2009 at 11:41 PM, Tom Lane wrote:
> Fujii Masao writes:
>> pg_standby can use ln command to restore an archived file,
>> which might destroy the archived file as follows.
>
> Does it matter? pg_standby's source area wouldn't normally be an
> "archive" in the real sense of the
Greg Stark wrote:
> Just as carefully written SQL code can be written to avoid deadlocks
> I would expect to be able to look at SQL code and know it's safe
> from serialization failures, or at least know where they might
> occur.
This is the crux of our disagreement, I guess. I consider exist
I wrote:
> Sam Mason writes:
>> On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
>>> There is some case to be made that we should throw error here,
>>> which we could do by putting error tests where the attached patch
>>> has comments suggesting an error test.
>> With things as they are
On Mon, Jun 1, 2009 at 11:07 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> No, I'm not. I'm questioning whether a serializable transaction
>> isolation level that makes no guarantee that it won't fire
>> spuriously is useful.
>
> Well, the technique I'm advocating virtually guarantees that t
Tom Lane wrote:
> Josh Berkus writes:
>> cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
> Actually I'm hoping that Kevin Grittner will have something to
> report on that one soon
So far, I haven't found any performance regressions in the beta2
release compared to the sna
Josh Berkus writes:
>> Yeah, this has been discussed before; I think it's even in the TODO
>> list.
> I couldn't find it. At least, not under data types, and also not with
> the keyword "typemod". Anyone see it?
It's the last item under ALTER:
* Don't require table rewrite on ALTER TABLE ...
Josh Berkus writes:
> yeah, you're right .. that would give us a short list of conversions
> which don't require a rewrite.However, as Tom points out, that
> doesn't mean that they might not need a reindex (as well as OID, there's
> also XML).
Um. I had actually forgotten about the reinde
Josh Berkus wrote:
> So, at least theoretically, anyone who had a traffic mix similar to
> TPCE would benefit. Particularly, some long-running serializable
> transactions thrown into a mix of Read Committed and Repeatable
> Read transactions, for a stored procedure driven application.
A belat
Jeff Davis wrote:
> On Mon, 2009-06-01 at 22:12 +0100, Greg Stark wrote:
>> No, I'm not. I'm questioning whether a serializable transaction
>> isolation level that makes no guarantee that it won't fire
>> spuriously is useful.
>
> I am also concerned (depending on implementation, of course) that
Jeff,
I observe that the casts (VARCHAR -> TEXT and TEXT -> VARCHAR) are
marked WITHOUT FUNCTION. If that's the case, can't we use that to say
that no heap rebuild is required? Perhaps we'll need to combine this
with the typmod checks to see if we need to check the heap.
yeah, you're right .
Greg Stark wrote:
> On Mon, Jun 1, 2009 at 9:24 PM, Kevin Grittner
> wrote:
>>> I'm concerned with whether you can be sure that the 999th time you
>>> run it the database won't randomly decide to declare a
>>> serialization failure for reasons you couldn't predict were
>>> possible.
>>
>> Now yo
On Mon, 2009-06-01 at 14:39 -0700, Josh Berkus wrote:
> Note that this doesn't deal with the special case of VARCHAR-->TEXT, but
> just with changing typemods. Are there other cases of data *type*
> conversions where no check or rebuild is required? Otherwise we might
> just special case VARCH
Yeah, this has been discussed before; I think it's even in the TODO
list.
I couldn't find it. At least, not under data types, and also not with
the keyword "typemod". Anyone see it?
The stumbling block has been to identify a reasonably clean way
of determining which datatype changes don'
On Mon, Jun 1, 2009 at 10:40 PM, Tom Lane wrote:
> We could certainly put in a quick hack that just covered a few of the
> cases for built-in types, but it's not very pleasing ...
Jonah proposed a patch for that a long time ago.
See http://archives.postgresql.org/pgsql-patches/2006-10/msg00154.p
On Mon, 2009-06-01 at 22:12 +0100, Greg Stark wrote:
> No, I'm not. I'm questioning whether a serializable transaction
> isolation level that makes no guarantee that it won't fire spuriously
> is useful.
I am also concerned (depending on implementation, of course) that
certain situations can make
On Mon, Jun 1, 2009 at 9:49 PM, Jeff Davis wrote:
>
>
> NUMERIC(x, y) comes to mind, although that might be a more dangerous
> case. If you turn a NUMERIC(5,0) into a NUMERIC(5,1), then '1.2' may be
> stored as either '1' or '1.2' depending on whether you did the insert
> before or after the chang
On Mon, Jun 1, 2009 at 9:24 PM, Kevin Grittner
wrote:
>> I'm concerned with whether you can be sure that the 999th time you
>> run it the database won't randomly decide to declare a serialization
>> failure for reasons you couldn't predict were possible.
>
> Now you're questioning whether SERIALIZ
On Mon, 2009-06-01 at 13:26 -0700, Josh Berkus wrote:
> All,
>
> I just realized that even if you do this:
>
> table foo (
> id serial,
> bar varchar(200)
> )
>
> ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
>
> ... it triggers a heap & index rebuild, even though it'
Josh Berkus wrote:
> This approach allowed MSSQL to "clean up" on TPCE; to date their
> performance on that benchmark is so much better than anyone else
> nobody else wants to publish.
Since they use a "compatibility level" setting to control whether a
request for a serializable transaction g
Tom Lane píše v po 01. 06. 2009 v 16:09 -0400:
> Zdenek Kotala writes:
> What is , and why is it being imported by the Perl headers?
It seems that problem is with Perl. It includes sys/mode.h. The new
change for gcc 4.2 is that mode.h includes vnode.h and it finally
sys/list.h which is generic
Josh Berkus writes:
> I just realized that even if you do this:
> ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
> ... it triggers a heap & index rebuild, even though it's completely
> unnecessary.
Yeah, this has been discussed before; I think it's even in the TODO
list. The stumbling bloc
Magnus Hagander writes:
> Tom Lane wrote:
>>> # instrument the Windows shared memory reattachment problem?
>>
>> Yeah. That was put on the list a month ago, when there was still plenty
>> of time to do something about it; but since we missed getting it into
>> beta2 I think it will have to wait.
All,
I just realized that even if you do this:
table foo (
id serial,
bar varchar(200)
)
ALTER TABLE foo ALTER COLUMN bar TYPE VARCHAR(1000)
... it triggers a heap & index rebuild, even though it's completely
unnecessary. Is this a special case of VARCHAR, or are the
Robert Haas píše v po 01. 06. 2009 v 16:03 -0400:
> On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala wrote:
> > During integration gcc4.2 into Solaris. My colleague hit a following
> > problem with PostgreSQL compilation:
> >
> > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
> >
Greg Stark wrote:
> On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
> wrote:
>> You can be sure you've written your transaction safely just as soon
>> as your COMMIT returns without error.
>
> I think we have different definitions of "safely". You only know
> that you got away with it *this tim
On Mon, Jun 1, 2009 at 4:08 PM, Greg Stark wrote:
> On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
> wrote:
>>
>> Whoa! I just noticed this phrase on a re-read. I think there might
>> be some misunderstanding here.
>>
>> You can be sure you've written your transaction safely just as soon as
>>
Tom Lane wrote:
> Josh Berkus writes:
>> # instrument the Windows shared memory reattachment problem?
>> -- as much as I'd like to do this, the solution could be as bad as the
>> problem; we'd need more testing time for new instrumentation. Will have
>> to deal with via testing patched versions
Zdenek Kotala writes:
> My idea is to rename list_head to pg_list_head (and other functions
> analogously) to avoid name conflict.
There is zero chance of that happening. We have thousands of references
to those functions in the core code, and who knows how many more in
third-party code we don'
On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
wrote:
>
> Whoa! I just noticed this phrase on a re-read. I think there might
> be some misunderstanding here.
>
> You can be sure you've written your transaction safely just as soon as
> your COMMIT returns without error.
I think we have different
On Mon, Jun 1, 2009 at 3:57 PM, Zdenek Kotala wrote:
> During integration gcc4.2 into Solaris. My colleague hit a following
> problem with PostgreSQL compilation:
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
>
> cd
> /builds/sfw-fixes/usr/src/cmd/postgres/postgresql-8.2/
During integration gcc4.2 into Solaris. My colleague hit a following
problem with PostgreSQL compilation:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6845982
cd
/builds/sfw-fixes/usr/src/cmd/postgres/postgresql-8.2/postgresql-8.2.13/src/pl/plperl
+ /ws/onnv-tools/SUNWspro/SS12/bin
Greg Stark wrote:
> If you can never know for sure that you've written your transaction
> safely
Whoa! I just noticed this phrase on a re-read. I think there might
be some misunderstanding here.
You can be sure you've written your transaction safely just as soon as
your COMMIT returns with
In the spirit of helping wrap-up 8.4 todo items...
Robert Haas wrote:
On Mon, May 25, 2009 at 6:15 PM, Tom Lane wrote:
Now I'm still not exactly happy with GEQO, but it's surely a lot better
than it was in the fall of 2000. So on the whole it does seem that the
current relationships between f
On Mon, Jun 1, 2009 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> I recommend we create
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
>> bumping things that can't be completed for 8.4.
>
> Why not just the regular TODO list?
>
> Stuff that has plausible patches att
Robert Haas writes:
> I recommend we create
> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
> bumping things that can't be completed for 8.4.
Why not just the regular TODO list?
Stuff that has plausible patches attached can go directly to the
CommitFest_2009-First page, but
On Mon, Jun 1, 2009 at 3:27 PM, Sam Mason wrote:
> On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote:
>> As I said earlier I doubt "pop" or "delete" is ever going to actually
>> be what you want. I suspect you're far more likely to want to restore
>> it to what it was before you started a
On Mon, Jun 1, 2009 at 2:09 PM, Josh Berkus wrote:
> Tom,
>
> Let me start this out by voting the things I think we can drop until 8.5:
>
> * gettext plurals patch needs some polishing
> -- revert patch, save for 8.5
>
> # adjust information_schema precision and scale fields?
> -- save for 8.5
>
Josh Berkus writes:
> Let me start this out by voting the things I think we can drop until 8.5:
> * gettext plurals patch needs some polishing
> -- revert patch, save for 8.5
Peter might think differently about that ;-). My problem with it is
that we don't seem to have a polished API for how co
On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote:
> As I said earlier I doubt "pop" or "delete" is ever going to actually
> be what you want. I suspect you're far more likely to want to restore
> it to what it was before you started altering it.
>
> As support I'll point out this is what
Heikki Linnakangas writes:
> I wonder if we should just remove the symlink option from pg_standby.
I was considering suggesting that too...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
htt
On May 29, 12:43 pm, Kevin Field wrote:
> On May 29, 11:48 am, Kevin Field wrote:
>
>
>
> > On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
> > > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > > wrote:
> > > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wro
Aidan Van Dyk wrote:
* Heikki Linnakangas [090601 10:56]:
Tom Lane wrote:
Fujii Masao writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
"archive" in the real
Tom Lane escribió:
> An
> alternative was to not have BEGIN/END but instead a GUC variable that
> you can SET to the name of the extension currently being added to.
> (The main advantage of that is that the state isn't hidden, but easily
> checkable via existing commands.)
With the CREATE EXTENSI
On Mon, Jun 1, 2009 at 7:57 PM, Alvaro Herrera
wrote:
> Josh Berkus wrote:
>
>>> Well I don't mind push but I still think pop is an error. What you
>>> really want to do is restore it to the value you started with. You
>>> don't want to remove the last element since that may not be the
>>> element
Josh Berkus wrote:
>> Well I don't mind push but I still think pop is an error. What you
>> really want to do is restore it to the value you started with. You
>> don't want to remove the last element since that may not be the
>> element you added. Some function you called may have added an extra
>
On Mon, Jun 1, 2009 at 7:24 PM, Josh Berkus wrote:
>> Since some (like MS SQL Server) allow users to choose
>> snapshot isolation or blocking-based serializable transactions in
>> their MVCC implementation
>
> This approach allowed MSSQL to "clean up" on TPCE; to date their performance
> on that
Alvaro Herrera writes:
> Tom Lane wrote:
>> I suppose this must be Dennis Björklund, but I didn't realize he
>> used to be a committer.
> IIRC he was given commit privs for translation files.
Ah, right, that does ring a bell now.
BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
Tom Lane wrote:
> Markus Wanner writes:
> > 'dennis' : ('Dennis??', ''),
>
> I suppose this must be Dennis Bj�rklund, but I didn't realize he
> used to be a committer.
IIRC he was given commit privs for translation files.
--
Alvaro Herrerahttp://www.Command
Kevin,
I'm not sure it's without value to the project; I just don't know that
it would be worth using for us. It seems to be accepted in some other
DBMS products. Since some (like MS SQL Server) allow users to choose
snapshot isolation or blocking-based serializable transactions in
their MVCC
Josh Berkus writes:
> # cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
> * tgl says: I think this is mostly dealt with but it could use
> performance testing.
> Mark? Jignesh? Can you test this?
Actually I'm hoping that Kevin Grittner will have something to report
o
On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
> Tom,
> # adjust information_schema precision and scale fields?
> -- save for 8.5
I read this thread. It seems for the changes we can make we should just
make them. The actual amount of change is actually very nominal.
Joshua D. Drake
--
Greg Stark wrote:
> But it's certainly insufficient in an OLAP or DSS environment where
> transactions can take hours. If you can never know for sure that
> you've written your transaction safely and it might randomly fail
> and need to be retried any given day due to internal implementation
>
"Kevin Grittner" writes:
> Robert Haas wrote:
>> But at least it doesn't seem like anyone is seriously arguing that
>> true serializability wouldn't be a nice feature, if hypothetically
>> we had an agreed-upon implementation and a high-level developer with
>> a lot of time on their hands.
> I
Tom,
Let me start this out by voting the things I think we can drop until 8.5:
* gettext plurals patch needs some polishing
-- revert patch, save for 8.5
# adjust information_schema precision and scale fields?
-- save for 8.5
# instrument the Windows shared memory reattachment problem?
-- as
Markus Wanner writes:
> I'm missing the names and email addresses for these committers:
> 'barry' : ('barry??', ''),
Barry Lind, formerly one of the JDBC bunch, been inactive for awhile
> 'dennis' : ('Dennis??', ''),
I suppose this must be Dennis Björklund, but I didn't realize he
used
On Mon, Jun 1, 2009 at 6:27 PM, Markus Wanner wrote:
> I'm not that eager on the "justifiable by simple inspection" requirement
> above. I don't think a DBA is commonly doing these inspections at all.
>
> I think a tool to measure abort rates per transaction (type) would serve
> the DBA better. Of
Robert Haas wrote:
> But at least it doesn't seem like anyone is seriously arguing that
> true serializability wouldn't be a nice feature, if hypothetically
> we had an agreed-upon implementation and a high-level developer with
> a lot of time on their hands.
If that's true, I think it repres
Hi,
a newish conversion with cvs2git is available to check here:
git://www.bluegap.ch/
(it's not incremental and will only stay for a few days)
For everybody interested, please check the committer names and emails.
I'm missing the names and email addresses for these committers:
'barry'
Tom Lane writes:
> [...]
>> See http://blog.endpoint.com/2009/05/postgresql-with-systemtap.html for
>> details. Perhaps it's worth noting in the documentation that SystemTap users
>> will need to use the double-underscore version?
>
> I think a better solution is to persuade the Systemtap guys th
Hi,
Kevin Grittner wrote:
> Greg Stark wrote:
>> I would want any serialization failure to be
>> justifiable by simple inspection of the two transactions.
>
> BTW, there are often three (or more) transaction involved in creating
> a serialization failure, where any two of them alone would not f
Greg,
Well the goal is to make them simpler. I don't know any language that
has implemented what you describe. Either you have access to the
internal methods of a class or you don't and you only have access to
the public api. That seems to work for much more sophisticated
languages than ours jus
On Mon, 2009-06-01 at 12:23 -0400, Alvaro Herrera wrote:
> Dimitri Fontaine wrote:
>
> > Le 31 mai 09 à 18:21, Tom Lane a écrit :
>
> >> You could maybe make this work by executing your own transaction
> >> to do it, but I really have to wonder if it's a good idea. One
> >> point to think about
On May 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field writes:
> > default:
> >elog(ERROR, "unrecognized raise option: %d",
> > opt->opt_type);
> > Should this be changed to:
> > default:
> >ereport(ERROR, (errmsg_internal("u
As of today we are three months behind the original plan for 8.4.0 release.
In a one-year release cycle that's already pretty bad slip; but there now
seems no chance of a release happening in less than a month, and if we
continue to let things drift it could easily stretch to five or six
months' sl
Dimitri Fontaine wrote:
> Le 31 mai 09 à 18:21, Tom Lane a écrit :
>> You could maybe make this work by executing your own transaction
>> to do it, but I really have to wonder if it's a good idea. One
>> point to think about is that elog(ERROR) still means elog(FATAL)
>> at this point, so any br
Greg Stark wrote:
> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas wrote:
> > On Sun, May 31, 2009 at 11:49 PM, Tom Lane wrote:
> >> "Updating the catalog tables directly via SQL"? ?Good luck making that
> >> work. ?If you ever get it to work at all, it'll require a pile of hacks
> >> that will make
Robert Haas wrote:
> > It's certainly the case that there is a lot more work to do before
> > pg_migrator could support everything that we reasonably want to be
> > able to do in a version update. ?As I see it, the reason it's getting
> > revived now is that 8.3->8.4 happens to be an update where m
On Mon, Jun 1, 2009 at 11:18 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas wrote:
>>> We really need to figure out an approach that lets us keep the old
>>> datatypes around under a different name while making the original name
>>> be the new version of
On Mon, Jun 1, 2009 at 11:10 AM, Greg Stark wrote:
> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas wrote:
>> On Sun, May 31, 2009 at 11:49 PM, Tom Lane wrote:
>>> "Updating the catalog tables directly via SQL"? Good luck making that
>>> work. If you ever get it to work at all, it'll require a pi
* Heikki Linnakangas [090601 10:56]:
> Tom Lane wrote:
>> Fujii Masao writes:
>>> pg_standby can use ln command to restore an archived file,
>>> which might destroy the archived file as follows.
>>
>> Does it matter? pg_standby's source area wouldn't normally be an
>> "archive" in the real sense
Greg Stark writes:
> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas wrote:
>> We really need to figure out an approach that lets us keep the old
>> datatypes around under a different name while making the original name
>> be the new version of the datatype. That way people can migrate and
>> be up,
On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas wrote:
> On Sun, May 31, 2009 at 11:49 PM, Tom Lane wrote:
>> "Updating the catalog tables directly via SQL"? Good luck making that
>> work. If you ever get it to work at all, it'll require a pile of hacks
>> that will make pg_migrator look like parad
Sam Mason writes:
> On Sun, May 31, 2009 at 06:32:53PM -0400, Tom Lane wrote:
>> There is some case to be made that we should throw error here,
>> which we could do by putting error tests where the attached patch
>> has comments suggesting an error test.
> With things as they are I think it would
On Sun, May 31, 2009 at 11:49 PM, Tom Lane wrote:
> 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
Tom Lane wrote:
Fujii Masao writes:
pg_standby can use ln command to restore an archived file,
which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
"archive" in the real sense of the word, it's just a temporary staging
area betwee
Fujii Masao writes:
> pg_standby can use ln command to restore an archived file,
> which might destroy the archived file as follows.
Does it matter? pg_standby's source area wouldn't normally be an
"archive" in the real sense of the word, it's just a temporary staging
area between master and sla
Bruce Momjian wrote:
> 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 th
1 - 100 of 102 matches
Mail list logo
