Hello
I migrated database cluster from 8.1 to 8.3, and I had problem with
tsvector domain. I imported tsearch2 module into template1 and then I
started import of complete dump - but public.tsvectors wasn't be known
- and I got message
ERROR: type "tsvector" is only a shell
LINE 5: fulltext_i
On Mon, Nov 17, 2008 at 10:42:21PM -0800, Jeff Davis wrote:
> On Mon, 2008-11-17 at 23:19 -0700, Joshua Tolley wrote:
> > -- it speeds up joins by fairly significant margins in some cases
>
> The original claim in the message you cite says 10-50% for some data
> distributions. Were you able to obs
Obviously that went too soon.
> In config.sgml, the documentation is good, but suffers from a slightly
> informal style. There are a lot of places where commas seem
> appropriate but are not present. Suggested changes by paragraph:
>
> 1. Replace last sentence: "Raising this value will cause Pos
> I addressed all the nitpicks and added comments.
Woot, yeah for comments.
There's a trivial conflict with CVS HEAD due to unrelated changes to
AC_CHECK_FUNCS(...kitchen sink...) but that led me to notice something
else: can't all this stuff about posix_fallocate be ripped out of
configure.in at
Hi,
On Wed, Oct 8, 2008 at 10:23 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Minor bug fix for pg_stop_backup() to prevent it waiting longer than
> necessary in certain circumstances.
Why don't you use XLByteToPrevSeg like pg_xlogfile_name?
I think that we should uniform the logic as much as pos
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Here is an update version of contrib/auto_explain patch.
Applied with some editorialization, mostly around the GUC stuff.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
This patch adds the ability to retrieve async notifications using dblink,
via the addition of the function dblink_get_notify.
It is written against cvs head, includes documentation and regression
testing. It compiles, tests and works well.
I would be interested in some feedback on the regression
Hi,
I just released new RPM sets, which is based on Nov 18 2008 11:00 PM
EEST CVS snapshot.
These packages *do* require a dump/reload, even from previous 8.4
packages, because of a catversion update.
We have more than 400 testers using these sets.
As usual, please find detailed info from:
http
Andrew Chernow wrote:
> For cygwin builds, src/test/thread/thread_test.c needs to include
> sys/param.h to get MAXHOSTNAMELEN. configure is currently failing when
> --enable-thread-safety is used because of this. See attached patch
> against head.
Applied, thanks.
//Magnus
--
Sent via pgsql-
Sorry about the HTML post, but I wanted to include the error form.
When trying to perform an upgrade with PostgreSQL 8.3.5 over 8.3.4, the
installer insists that PostgreSQL has failed to start.
However, I can see the processes in memory (it has indeed started) and
even attach with PG Admin
Heikki Linnakangas wrote:
Somehow this feels pretty baroque, though. Perhaps a better approach
would be to add a new AtPrepare_OnCommitActions function to tablecmds.c,
that gets called before AtPrepare_Locks. It would scan through the
on_commits list, and release all locks for the "PREPARE-safe
Simon Riggs <[EMAIL PROTECTED]> writes:
> heap_inplace_fetch takes as input "tuple" which is a palloc'd tuple,
> extracts from it the tid of the tuple, reads the buffer, locks it, then
> releases the original tuple. It then returns a copy of the on-block
> tuple. So all other code the same as befor
On Wed, 2008-11-12 at 16:25 -0500, Tom Lane wrote:
> The alternative I was thinking about involved taking an exclusive buffer
> lock on the page containing the tuple to be updated in-place. The point
> being that you have to examine the old tuple contents and decide whether
> to update after you
for anyone interested
Solaris 2.5.1 with --enable-thread-safety
configure:25848: gcc -o conftest -O2 -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -fwrapv -pthreads -pthreads -D_REENTRANT
-D_THREAD_SAFE -D_POSIX_PTHREAD_SE
On Tue, Nov 18, 2008 at 07:32:33PM +0100, Pavel Stehule wrote:
> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> > this is what I think you want to do in the context of aggregates:
> >
> > CREATE FUNCTION array_concat_(ANYARRAY,ANYARRAY) RETURNS ANYARRAY
> >AS $$ SELECT array_cat($1,ARRAY[$2]); $$
2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 06:22:21PM +, Sam Mason wrote:
>> I've always been taught to design things so that the that the basic
>> semantics should be as simple as possible which maintaining useful
>
> this should of course be "while"! ^
>
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> there are clean rules. you do array from input - when input is 1D
> array, then result is 2D array, when input is record, then result is
> 1D array of record. Where should be problem?
That seems all right, but it's *not* what you first proposed, and
wh
On Tue, Nov 18, 2008 at 06:22:21PM +, Sam Mason wrote:
> I've always been taught to design things so that the that the basic
> semantics should be as simple as possible which maintaining useful
this should of course be "while"! ^
> performance.
> CREATE FUNCTION array_concat
2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 06:55:26PM +0100, Pavel Stehule wrote:
>> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
>> > On Tue, Nov 18, 2008 at 05:20:27PM +0100, Pavel Stehule wrote:
>> >> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
>> >> > I've used this syntax b
On Tue, Nov 18, 2008 at 06:55:26PM +0100, Pavel Stehule wrote:
> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> > On Tue, Nov 18, 2008 at 05:20:27PM +0100, Pavel Stehule wrote:
> >> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> >> > I've used this syntax before and got a surprising message back. I'd
>
2008/11/18 Tom Lane <[EMAIL PROTECTED]>:
> Sam Mason <[EMAIL PROTECTED]> writes:
>> I've used this syntax before and got a surprising message back. I'd
>> expect to be able to do the following:
>>
>> and get the following back {"(a,1)","(b,2)"}. So I think I'm with
>> David.
>
> I concur --- if w
Sam Mason <[EMAIL PROTECTED]> writes:
> I've used this syntax before and got a surprising message back. I'd
> expect to be able to do the following:
> ARRAY((SELECT col1, col2 FROM (VALUES ('a',1), ('b',2)) x(col1,col2)));
> and get the following back {"(a,1)","(b,2)"}. So I think I'm with
> Da
On Tue, 2008-11-18 at 12:54 -0500, Aidan Van Dyk wrote:
> * Tom Lane <[EMAIL PROTECTED]> [081118 12:43]:
> > Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > The trouble here is to avoid repeated WAL-logging of the same hint bits.
> >
> > (Alvaro's patch tried to do that by depending on another hint
2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 05:20:27PM +0100, Pavel Stehule wrote:
>> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
>> > I've used this syntax before and got a surprising message back. I'd
>> > expect to be able to do the following:
>> >
>> > ARRAY((SELECT col1
* Tom Lane <[EMAIL PROTECTED]> [081118 12:43]:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > But why can't you wal-log the hint bits from the "buffered" page. then your
> > consitent. At least as consistent as the original write was.
>
> > So you're CRC ends up being:
> >Buffer the page
>
The patch mentioned in the subject leaves this compiler warning:
tsvector_op.c: In function ‘insertStatEntry’:
tsvector_op.c:815: warning: ‘res’ may be used uninitialized in this function
I took a quick look but it is not immediately obvious whether the
compiler might actually have a point here
Simon, Stark, others:
It seems a strange moderation policy that allows bald insults from some
people but not others. And stranger still that you think you should leap
to the defence of any person making them. If the comments were meant so
lightly, it would seem easy to withdraw them also, with a
2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 05:19:12PM +0100, Pavel Stehule wrote:
>> there are some not necessary limits, because we should some operations:
>>
>> postgres=# select array(select * from foo);
>> ERROR: subquery must return only one column
>> LINE 1: select a
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> But why can't you wal-log the hint bits from the "buffered" page. then your
> consitent. At least as consistent as the original write was.
> So you're CRC ends up being:
>Buffer the page
>Calculate CRC on the buffered page
>WAL (in bulk) th
Greg,
To give you an idea how overdiscussed this general topic is, I just sent
a message to Josh suggesting we might put database size into tiers and
set some parameters based on that. Guess what? That was his idea the
last time around, I subconsciously regurgitated it:
http://archives.post
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Right now we flip hint bits without taking any kind
>> of lock on the page.
> That's not quite true. You need to hold a shared lock on heap page to
> examine the visibility of a tuple, and that's when the hint bits are
> s
* Alvaro Herrera <[EMAIL PROTECTED]> [081118 12:25]:
> I don't think it's a matter of hoy many writes or how much IO. The
> question is locks. Right now we flip hint bits without taking any kind
> of lock on the page. If we're going to WAL-log each hint bit change,
> then we will need to lock
Alvaro Herrera wrote:
Right now we flip hint bits without taking any kind
of lock on the page.
That's not quite true. You need to hold a shared lock on heap page to
examine the visibility of a tuple, and that's when the hint bits are
set. So we always hold at least a shared lock on the page w
Aidan Van Dyk wrote:
> And I don't think anyone's going to have a good answer either way unless we
> get
> real numbers. But I don't know of any way to get at these numbers right now.
>
> 1) How many writes happen on buffer pages that are "hint dirty" but not
> "really
>dirty"?
>
> 2) How
On Wed, 2008-11-19 at 01:42 +0900, KaiGai Kohei wrote:
> Simon,
> I'm sorry, if my expression felt you uncomfortable.
No worries at all. I know exactly how you feel. Good Luck.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers
On Tue, Nov 18, 2008 at 05:19:12PM +0100, Pavel Stehule wrote:
> there are some not necessary limits, because we should some operations:
>
> postgres=# select array(select * from foo);
> ERROR: subquery must return only one column
> LINE 1: select array(select * from foo);
The current limitation
On Tue, Nov 18, 2008 at 05:20:27PM +0100, Pavel Stehule wrote:
> 2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> > I've used this syntax before and got a surprising message back. I'd
> > expect to be able to do the following:
> >
> > ARRAY((SELECT col1, col2 FROM (VALUES ('a',1), ('b',2)) x(col1,col2
> One thing which is bothering me is that the guc assign hook is throwing an
> error if you set effective_io_concurrency when your system's posix_fadvise is
> deemed inadequate (either unavailable or from an old version of glibc). I'm
> starting to think it shouldn't throw an error, just not set th
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Just a very quick look on your patch. See my comments:
...
2) PG_PAGE_LAYOUT_VERSION should be bump
The patch doesn't change the page layout AFAICS.
It is good question what is and what is not page layout. I think that toast
implementati
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> I'll try your approash in first, as follows:
>
> This seems a vast amount of uglification to avoid adding an argument to
> CreateTemplateTupleDesc. We do that kind of thing all the time --- it
> is a simple and reliable change to make.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There are probably no rigid rules on this, but my interpretation of these tags
> is usually this:
>
> XXX -- not sure if this is the best way to do this, needs ideas
> TODO -- specific ideas for improvement
> FIXME -- broken, must be fixed to be usabl
Gregory Stark wrote:
> Paul Schlie writes:
>
>> Heikki Linnakangas wrote:
Gregory Stark wrote:
However you still have a problem that someone could come along and set the
hint bit between calculating the CRC and actually calling write.
>>>
>>> The double-buffering will solve that.
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> This is not something we would typically backpatch because of the danger
>> of introducing some unexpected change in libpq. We can provide a patch
>> to anyone who needs it, or if the community wants it backpatched I can
>> certa
2008/11/18 Sam Mason <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 07:37:44AM -0800, David Fetter wrote:
>> On Tue, Nov 18, 2008 at 10:29:53AM -0500, Robert Haas wrote:
>> > Seems like you could just write SELECT ARRAY[col1, col2, col3]
>> > instead of SELECT col1, col2, col3.
>>
>> If I understan
2008/11/18 David Fetter <[EMAIL PROTECTED]>:
> On Tue, Nov 18, 2008 at 10:29:53AM -0500, Robert Haas wrote:
>> On Tue, Nov 18, 2008 at 10:06 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
>> > Hello
>> >
>> > I am thinking about allowing 2D array from multicolumn subselect
>> > (all columns have to s
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
If I'm thinking more, it is not probably CATALOG_VERSION_NO as well.
Because toast table is created on demand. It is not in BKI.
It's not catversion in the sense that there's no catalog change, but it
certainly requires a catversion bump due to i
KaiGai Kohei <[EMAIL PROTECTED]> writes:
> I'll try your approash in first, as follows:
This seems a vast amount of uglification to avoid adding an argument to
CreateTemplateTupleDesc. We do that kind of thing all the time --- it
is a simple and reliable change to make.
When designing a patch, y
On Tue, Nov 18, 2008 at 07:37:44AM -0800, David Fetter wrote:
> On Tue, Nov 18, 2008 at 10:29:53AM -0500, Robert Haas wrote:
> > Seems like you could just write SELECT ARRAY[col1, col2, col3]
> > instead of SELECT col1, col2, col3.
>
> If I understand this right, Pavel is thinking that
>
> AR
On Tue, 2008-11-18 at 10:36 -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
> >> I was looking into that and I figured using the \G expression in
> >> Perl REs would be useful for this (to find multiple s).
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> If I'm thinking more, it is not probably CATALOG_VERSION_NO as well.
>> Because toast table is created on demand. It is not in BKI.
> It's not catversion in the sense that there's no catalog change, but it
> certainly requires a
On Tue, Nov 18, 2008 at 10:29:53AM -0500, Robert Haas wrote:
> On Tue, Nov 18, 2008 at 10:06 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> > I am thinking about allowing 2D array from multicolumn subselect
> > (all columns have to share same type, ofcourse). Is there some
> > real li
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
>> I was looking into that and I figured using the \G expression in
>> Perl REs would be useful for this (to find multiple s).
>> But this was introduced in Perl 5.000, and we claim to sup
Zdenek Kotala wrote:
> If I'm thinking more, it is not probably CATALOG_VERSION_NO as well.
> Because toast table is created on demand. It is not in BKI.
It's not catversion in the sense that there's no catalog change, but it
certainly requires a catversion bump due to internal changes.
Otherwis
On Tue, Nov 18, 2008 at 04:01:58PM +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
>> Hmm. Given the current infrastructure for \h, the only way to do
>> that would be to make a separate ref page for WITH, which feels
>> like the wrong thing. And the objection I have to TABLE is not the
>> code
On Tue, Nov 18, 2008 at 10:06 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> Hello
>
> I am thinking about allowing 2D array from multicolumn subselect (all
> columns have to share same type, ofcourse). Is there some real limit,
> why this functionality is disallowed?
Seems like you could just wri
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Just a very quick look on your patch. See my comments:
...
2) PG_PAGE_LAYOUT_VERSION should be bump
The patch doesn't change the page layout AFAICS.
It is good question what is and what
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Looking forward to v20.
Here you go!
I addressed all the nitpicks and added comments.
I also stripped out the sequential i/o posix_fadvises. I'm kind of sad to see
them go since it did seem like a nice way to give more info to the OS even if
no OSes t
Gregory Stark wrote:
The XXX is something that probably needs to be fixed but it's just a question
of what header file to put a declaration in. I couldn't find a good choice but
perhaps someone else has an idea?
For the FIXMEs I don't have any problem leaving them in place. They're
warnings to f
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Just a very quick look on your patch. See my comments:
...
2) PG_PAGE_LAYOUT_VERSION should be bump
The patch doesn't change the page layout AFAICS.
It is good question what is and what
Hello
I am thinking about allowing 2D array from multicolumn subselect (all
columns have to share same type, ofcourse). Is there some real limit,
why this functionality is disallowed?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
> For the FIXMEs I don't have any problem leaving them in place. They're
> warnings to future coders working in the same area of what they may have to do
> to make the code more general.
That's fine with me. I think it's fine to document possibilities for
future development, but sometimes it's ha
Tom Lane wrote:
Hmm. Given the current infrastructure for \h, the only way to do that
would be to make a separate ref page for WITH, which feels like the
wrong thing. And the objection I have to TABLE is not the code but the
apparent need to give it its own ref page (as we already did for VALUE
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Just a very quick look on your patch. See my comments:
...
2) PG_PAGE_LAYOUT_VERSION should be bump
The patch doesn't change the page layout AFAICS.
It is good question what is and what is not page layout. I think th
Zdenek Kotala wrote:
Just a very quick look on your patch. See my comments:
...
2) PG_PAGE_LAYOUT_VERSION should be bump
The patch doesn't change the page layout AFAICS.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
Heikki Linnakangas wrote:
Hmm, you're right. I think it can be made to work by storing the
*end* offset of each chunk. To find the chunk containing offset X,
search for the first chunk with end_offset > X.
FWIW I'm t
On Tue, 2008-11-18 at 21:40 +0900, KaiGai Kohei wrote:
> A concern is why you suggested this feature at the last half of the
> November. :(
I gave you my feedback as soon as I read the Wiki article. Even then I
didn't understand some aspects of the patch design, which was
unfortunate. But these
Garick Hamlin wrote:
I have a patch that I have been using to support postgresql's
notion of ident authentication when using unix domain sockets on
Solaris. This patch basically just adds support for using
getupeercred() on Solaris so unix sockets and ident auth works just
like it does
Simon Riggs wrote:
> On Tue, 2008-11-18 at 16:51 +0900, KaiGai Kohei wrote:
>
>> Anyway, I've started to work with the prior approach.
>
> Sounds good.
The matters currently I faces:
* In the approach.1 (add "tdhassecurity" to TupleDesc)
An explosion of the number of points to be patched. :(
*
Bruce Momjian wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <[EMAIL PROTECTED]> writes:
I am unsure of exactly where this thing hacks into the authentication
stream, but is it really only MD5 that fails?
>>> The problem with md5 is that the username is part of the
Bruce Momjian wrote:
> Russell Smith wrote:
> > Will this be back patched when it's committed?
>
> This is not something we would typically backpatch because of the danger
> of introducing some unexpected change in libpq. We can provide a patch
> to anyone who needs it, or if the community wants
"Robert Haas" <[EMAIL PROTECTED]> writes:
> - However, having said that, it looks as if there is still a bit of
> experimentation going on in terms of what you actually want the patch
> to do. There are a couple of things that say FIXME or XXX, and at
> least one diff hunk that adds code surroun
Emmanuel Cecchet wrote:
Emmanuel Cecchet wrote:
As I have not found yet an elegant solution to deal with the DROP
CASCADE issue, here is a simpler patch that handles temp tables that
are dropped at commit time. This is a good first step and we will try
to elaborate further to support ON COMMIT
On Tue, 2008-11-18 at 16:51 +0900, KaiGai Kohei wrote:
> Anyway, I've started to work with the prior approach.
Sounds good.
> Now we have less than two weeks remained in the CommitFest:Nov, so we have
> no time to be spent uselessly.
>
> >>> SUSE?
> >> The "u" might be a large-letter.
> >
> >
Hi,
we currently want to employ PG and Gin Index for light-weight full text
search engine. however,
we encounter a problem that Gin Index is not quick enough for relevence,
because it must
scan all heaptuples which statisfy the condition, then invoke ts_rank to
compute the rank of tuple.
a
>>> The length of HeapTupleData is determined during heap_form_tuple(),
>>> and it is unchanged later. Thus, we have to interpose here, as object
>>> identifier doing.
>> Currently yes. Is there a reason not to? Do we rely on the tuple length
>> staying same after those operations?
>>
>> Just consi
Paul Schlie <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>>> Gregory Stark wrote:
>>> However you still have a problem that someone could come along and set the
>>> hint bit between calculating the CRC and actually calling write.
>>
>> The double-buffering will solve that.
>
> Or simply
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
On Mon, 2008-11-17 at 19:34 -0500, Tom Lane wrote:
My point is it's a user-visible change --- maybe a subtle one, but still
a change that in principle could break some app somewhere --- and no
good reason has been put forward for mak
77 matches
Mail list logo
