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 making
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 require that
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 considering multiple
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.
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.
Sorry, I wasn't
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
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 surrounded by
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 it
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 encryption salt
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. :(
* In the
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
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
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
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
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
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
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 hard
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
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
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
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 today
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
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 write
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 refnames).
But this was introduced in Perl 5.000, and we claim to
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 limit, why
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
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.
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 but the
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 refnames).
But
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
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, you
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
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 share same type,
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 understand this right,
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
certainly do
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.
Or simply require
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 usable
I
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.
When
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
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 the
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)));
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 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
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 much IO
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
* 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 the
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
set. So we
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:
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) the hint
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 array(select
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
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
* 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
Calculate
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, col2 FROM
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 bit in the
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
David.
I
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 we support something
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
expect to be
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 before and got a
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
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
what you
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! ^
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]); $$
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
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
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 before when
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
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
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
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:
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
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 changes
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
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
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
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 observe
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:
77 matches
Mail list logo
