Simon Riggs wrote:
I'm undecided as to whether this is too much code or too little. I'm
somewhat uncertain as to the locking requirements for the physical scan
during a vacuum. I've worked out various options if we need to change
this.
For the B-tree, an exclusive lock is enough to modify the
Charles Duffy wrote:
I'm interested in compressing archived WAL segments in an environment
set up for PITR in the interests of reducing both network traffic and
storage requirements. However, pg_standby presently checks file sizes,
requiring that an archive segment be exactly the right size to
Dave Gudeman wrote:
On Mon, Oct 20, 2008 at 2:28 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Another objection to this design is that it's completely unclear that
functions from text to text should necessarily yield the same collation
that went into them, but if you treat
On Thu, Oct 23, 2008 at 1:15 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Charles Duffy wrote:
I'm interested in compressing archived WAL segments in an environment
set up for PITR in the interests of reducing both network traffic and
storage requirements. However, pg_standby presently
For making psql fully scriptable I would think it would be smarter to
embed a full well-supported existing language rather than trying to
invent a new one.
If we do want to to that I would suggest looking at lua which is
intended to be used this way.
greg
On 23 Oct 2008, at 05:45 AM,
On 23 okt 2008, at 00.48, Alvaro Herrera [EMAIL PROTECTED]
wrote:
Josh Berkus wrote:
Hackers,
Just had a feature request from Wheeler, and I don't see why it
shouldn't
go on our todo list.
I think you're asking for more scriptability in psql. Personally I
think that would be a great
2008/10/23 Greg Stark [EMAIL PROTECTED]:
For making psql fully scriptable I would think it would be smarter to embed
a full well-supported existing language rather than trying to invent a new
one.
plpgsql?
regards
Pavel
If we do want to to that I would suggest looking at lua which is
Pavel Stehule wrote:
2008/10/23 Greg Stark [EMAIL PROTECTED]:
For making psql fully scriptable I would think it would be smarter to embed
a full well-supported existing language rather than trying to invent a new
one.
plpgsql?
I think plpgsql is a pretty good example of the sort of disaster
Magnus Hagander wrote:
If you want full scripting, look at pgscript, one of this summers gsoc
projects. It'll ship in the next pgadmin and is also available as a
standalone executable.
Yet another language?
What people asking for psql scriptability really want, in my estimate,
is the
2008/10/23 Peter Eisentraut [EMAIL PROTECTED]:
Magnus Hagander wrote:
If you want full scripting, look at pgscript, one of this summers gsoc
projects. It'll ship in the next pgadmin and is also available as a
standalone executable.
Yet another language?
it is more crazy - pgscript is based
On Thu, 2008-10-23 at 08:40 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2008-10-22 at 21:47 +0100, Simon Riggs wrote:
But once you reach 64 transactions, you'll need to write an extra WAL
record for every subtransaction, which currently I've managed to avoid.
Yes,
I would like to add an escape mechanism to PostgreSQL for entering
arbitrary Unicode characters into string literals. We currently only
have the option of entering the character directly via the keyboard or
cut-and-paste, which is difficult for a number of reasons, such as when
the font
On Thu, 2008-10-23 at 09:09 +0300, Heikki Linnakangas wrote:
However, we require that in b-tree vacuum, you take a cleanup lock on
*every* leaf page of the index, not only those that you modify. That's a
problem, because there's no trace of such pages in the WAL.
OK, good. Thanks for the
Simon Riggs wrote:
The patch isn't ready to apply standalone because we need to include the
changes to XidInMVCCSnapshot() also, which would take a little while to
extract. Let me know if that is worth producing a standalone patch for.
FWIW, this patch becomes a lot simpler if you don't change
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
ExplainableStmt:
SelectStmt
| InsertStmt
| UpdateStmt
| DeleteStmt
| DeclareCursorStmt
+ | CreateAsStmt
| ExecuteStmt
On Thu, 2008-10-23 at 13:40 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
The patch isn't ready to apply standalone because we need to include the
changes to XidInMVCCSnapshot() also, which would take a little while to
extract. Let me know if that is worth producing a standalone
On Thu, 2008-10-23 at 14:29 +0300, Peter Eisentraut wrote:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
Yes please.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
Hi,
On Wed, Oct 22, 2008 at 8:14 PM, Jaime Casanova
[EMAIL PROTECTED] wrote:
just remembering that -patches is a dead list, so i'm sending this to
-hackers where it will have more visibility...
-- Forwarded message --
On 10/22/08, Nikhil Sontakke [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't explain CREATE TABLE,
On Wed, Oct 22, 2008 at 04:14:11PM -0700, Joshua Drake wrote:
True enough, but a car doesn't roll without at least four wheels.
I'm not sure I agree: http://en.wikipedia.org/wiki/Image:1885Benz.jpg
(Sorry, I couldn't resist.)
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
Magnus Hagander wrote:
This patch changes the options field of pg_hba.conf to take name/value
pairs instead of a fixed string. This makes it a lot nicer to deal with
auth methods that need more than one parameter, such as LDAP.
While at it, it also adds map support to kerberos, gssapi and
Le jeudi 23 octobre 2008, Tom Lane a écrit :
Peter Eisentraut [EMAIL PROTECTED] writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
It turns out you cannot EXPLAIN on CREATE TABLE AS, but it seems to work
fine if I extend the grammar as below:
This seems to me to be something that will look like a wart, not a
feature, from the user's point of view. You can't
Peter Eisentraut [EMAIL PROTECTED] writes:
SQL has the following escape syntax for it:
U'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand? How do you propose to distinguish
this from a perfectly legitimate use of the operator?
2. Convert this syntax to a
Peter Eisentraut [EMAIL PROTECTED] writes:
Isn't the whole point of EXPLAIN to expose implementation artifacts in
the first place?
Touche ... I withdraw the complaint.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Currently in heaptuple.c we have duplicated code. heap_deformtuple and
heap_formtuple are mark as a obsolete interface. Is any reason to have still
them? I know that they are still used on many places, but is there any stopper
to keep these function alive?
Zdenek
--
Zdenek
Hi All,
BTree Insert requires a data-structure called BTStack to report the
page splits that have happened in the leaf pages to non-leaf pages upwards.
It basically goes back and updates those non-leaf pages. But this will never
happen in a search operation. You never need to climb upwards
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
SQL has the following escape syntax for it:
U'special character: \' [ UESCAPE '\' ]
Man that's ugly. Why the ampersand?
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax
Zdenek Kotala [EMAIL PROTECTED] writes:
Currently in heaptuple.c we have duplicated code. heap_deformtuple and
heap_formtuple are mark as a obsolete interface. Is any reason to have still
them? I know that they are still used on many places, but is there any
stopper
to keep these
Peter Eisentraut [EMAIL PROTECTED] writes:
There are some other disadvantages for making a function call. You
couldn't use that kind of literal in any other place where the parser
calls for a string constant: role names, tablespace locations,
passwords, copy delimiters, enum values,
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Currently in heaptuple.c we have duplicated code. heap_deformtuple and
heap_formtuple are mark as a obsolete interface. Is any reason to have still
them? I know that they are still used on many places, but is there any stopper
to
Zdenek Kotala [EMAIL PROTECTED] writes:
Tom Lane napsal(a):
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of that code,
Zdenek Kotala wrote:
Tom Lane napsal(a):
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of that code, but less annoying
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of
This patch adds a configuration option to pg_hba.conf for clientcert.
This makes it possible to have different client certificate requirements
on different connections. It also makes sure that if you specify that
you want client cert verification and the root store isn't there, we
give an error
In terms of compress/decompress WAL in archive/restore, please take a
look at my project pglesslog,
http://pgfoundry.org/projects/pglesslog/
This project compresses WAL segment by replacing full page writes with
corresponding incremental logs. When restored, it inserts dummy WAL
record to
Koichi Suzuki wrote:
In terms of compress/decompress WAL in archive/restore, please take a
look at my project pglesslog,
http://pgfoundry.org/projects/pglesslog/
This project compresses WAL segment by replacing full page writes with
corresponding incremental logs. When restored, it inserts
Zdenek Kotala wrote:
Alvaro Herrera napsal(a):
Agreed, I started doing that some time ago ... it doesn't seem all that
complicated.
Do you have any half patch?
Couldn't find it here, sorry :-(
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL
Magnus Hagander wrote:
This patch adds a configuration option to pg_hba.conf for clientcert.
This makes it possible to have different client certificate requirements
on different connections. It also makes sure that if you specify that
you want client cert verification and the root store isn't
ITAGAKI Takahiro wrote:
I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though. As to your
questions:
- Are there any performance degradation because of addtional memcpy?
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
The patch seems pretty far short of sufficient as far as supporting a
new conninfo option goes --- for instance it appears to leak the string
at disconnect. Check through all the references to some existing option
field to see if you
Simon Riggs wrote:
It would also be possible to introduce a special tweak there which is
that if the block is not in cache, don't read it in at all. If its not
in cache we know that nobody has a pin on it, so don't need to read it
in just to say got the lock. That icing for later.
Heh, that's
On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
Man that's ugly. Why the ampersand?
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax diagram.
Probably because many Unicode representations are done with U+
followed by 4-6
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
I have some comments about the double-buffering:
Since posting this patch I have realized that this implementation is
bogus. I'm now playing with WAL-logging hint bits though.
Yeah, the torn page + hint bit updates problem is the tough
Magnus Hagander [EMAIL PROTECTED] writes:
Looking over it again, that's pretty much the only one I find. I checked
against sslmode. Did you spot something else?
No, I just thought that it looked like too small a patch for adding
a new conn option, and complained as soon as I found something
Andrew Sullivan [EMAIL PROTECTED] writes:
On Thu, Oct 23, 2008 at 06:04:43PM +0300, Peter Eisentraut wrote:
Yeah, excellent question. It seems completely unnecessary, but it is
surely there in the syntax diagram.
Probably because many Unicode representations are done with U+
followed by
On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
It would also be possible to introduce a special tweak there which is
that if the block is not in cache, don't read it in at all. If its not
in cache we know that nobody has a pin on it, so don't need to read
Heikki Linnakangas [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
I thought about that too. I admit I am not sure if this really works
portably; however I don't want to add a palloc() to that routine.
It should work, AFAIK, but unaligned memcpy()s and write()s can be a
significantly
Simon Riggs wrote:
On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
You have other issues with those still, namely that
table locks are not yet taken appropriately, so I'm not sure if this is
worth worrying about until that's done.
Please explain. If you know of a correctness
Everyone,
What people asking for psql scriptability really want, in my estimate,
is the ability to write SQL plus some control structures anywhere, in
the server, in the client, or so that they don't have to know where.
Commercial vendors have that: Oracle has PL/SQL as server-side language
On Thu, 2008-10-23 at 20:24 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2008-10-23 at 19:21 +0300, Heikki Linnakangas wrote:
You have other issues with those still, namely that
table locks are not yet taken appropriately, so I'm not sure if this is
worth worrying about
On Thu, 2008-10-23 at 04:38 +0100, Simon Riggs wrote:
That means that out of the four state transitions that are
disallowed by the original coding of that Assert, you are now having to
consider two as legal. I don't like that, and I like even less that
it's not even trying to determine
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Works fine for me, eg
I think he's looking for something like:
5 IN (col1,col2,col3)
resulting in a bitmap or of three index scans of three different indexes on
col1, col2, and col3.
Ah, I see. It would be easy to
On Thu, 23 Oct 2008, Tom Lane wrote:
Well, aside from the gruntwork needed to convert all the core code that
still uses the old APIs, there's the prospect of breaking extension
modules that still use the old APIs. It's kind of annoying to have two
copies of that code, but less annoying
On Mon, 2008-10-20 at 10:25 +0100, Simon Riggs wrote:
What else do we need?
* pg_freeze_recovery()
* pg_unfreeze_recovery()
Two more functions
pg_freeze_recovery_cleanup()
pg_unfreeze_recovery_cleanup()
These would allow recovery to continue normally, except for row removal
operations
Magnus Hagander wrote:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
sslverify, and can be set to:
Because SSL offers both encryption and authentication, I wonder if we
should call this sslauthenticate.
The sad thing us that I also did a patch for this and lost it. I think
it wouldn't be too hard to convert all the call sites in the backend
and provide a wrapper for other users.
greg
On 23 Oct 2008, at 08:59 PM, Kris Jurka [EMAIL PROTECTED] wrote:
On Thu, 23 Oct 2008, Tom Lane wrote:
Julius Stroffek wrote:
Hi All,
we would like to start some work on improving the performance of
PostgreSQL in a multi-CPU environment. Dano Vojtek is student at the
Faculty of Mathematics and Physics of Charles university in Prague
(http://www.mff.cuni.cz) and he is going to cover this
On Thu, 23 Oct 2008, Bruce Momjian wrote:
I think the current plan is to use posix_advise() to allow parallel I/O,
rather than async I/O becuase posix_advise() will require fewer code
changes.
These are not necessarily mutually exclusive designs. fadvise works fine
on Linux, but as far as I
Bruce Momjian wrote:
Magnus Hagander wrote:
Attached patch cleans up the certificate verification in libpq, and adds
a configuration paraqmeter to control it. The new parameter is
sslverify, and can be set to:
Because SSL offers both encryption and authentication, I wonder if we
should
I notice that there is a src/backend/libpq/README.SSL that contains a
couple of copied emails in it (it even contains our end-of-broadcast
message string!) And it contains a reply to the mail, with quoted stuff!
In general, this seem to be some hints about how to use things. Things
that if we
While you're cleaning up SSL, how about the thread with this email on
it:
19212172.post%40talk.nabble.com
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list
On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith [EMAIL PROTECTED] wrote:
I think the current plan is to use posix_advise() to allow parallel I/O,
rather than async I/O becuase posix_advise() will require fewer code
changes.
These are not necessarily mutually exclusive designs. fadvise works fine
Magnus Hagander wrote:
I notice that there is a src/backend/libpq/README.SSL that contains a
couple of copied emails in it (it even contains our end-of-broadcast
message string!) And it contains a reply to the mail, with quoted stuff!
In general, this seem to be some hints about how to use
Jonah H. Harris wrote:
On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith [EMAIL PROTECTED] wrote:
I think the current plan is to use posix_advise() to allow parallel I/O,
rather than async I/O becuase posix_advise() will require fewer code
changes.
These are not necessarily mutually exclusive
Alvaro Herrera wrote:
While you're cleaning up SSL, how about the thread with this email on
it:
19212172.post%40talk.nabble.com
Yeah, I mentioned this to Magnus this morning (my time) and he said
Bruce was compiling a patch in time for the next commit fest.
I'm not sure where it's all
Russell Smith wrote:
Alvaro Herrera wrote:
While you're cleaning up SSL, how about the thread with this email on
it:
19212172.post%40talk.nabble.com
Yeah, I mentioned this to Magnus this morning (my time) and he said
Bruce was compiling a patch in time for the next commit fest.
We've occasionally talked about allowing pending-trigger-event lists to
spill to disk when there get to be so many events that it's a memory
problem. I'm not especially interested in doing that right now, but
I noticed recently that we could alleviate the problem a lot by adopting
a more compact
I couldn't get async I/O to work on Linux. That is it worked but
performed the same as reading one block at a time. On solaris the
situation is reversed.
In what way is fadvise a kludge?
greg
On 24 Oct 2008, at 01:44 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
Jonah H. Harris wrote:
On
Greg Stark wrote:
I couldn't get async I/O to work on Linux. That is it worked but
performed the same as reading one block at a time. On solaris the
situation is reversed.
In what way is fadvise a kludge?
I think he is saying AIO gives us more flexibility, but I am unsure we
need it.
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
True, it is a kludge but if it gives us 95% of the benfit with 10% of
the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
--
Jonah H. Harris, Senior DBA
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
[EMAIL PROTECTED] wrote:
I couldn't get async I/O to work on Linux. That is it worked but performed
the same as reading one block at a time. On solaris the situation is
reversed.
Hmm, then obviously you did something wrong, because my tests showed
Jonah H. Harris [EMAIL PROTECTED] writes:
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
In what way is fadvise a kludge?
non-portable, requires more user-to-system CPU, ... need I go on?
I'd be interested to know which of these proposals you claim *is*
portable. The single biggest reason to
On Fri, Oct 24, 2008 at 12:42 AM, Tom Lane [EMAIL PROTECTED] wrote:
non-portable, requires more user-to-system CPU, ... need I go on?
I'd be interested to know which of these proposals you claim *is*
portable. The single biggest reason to reject 'em all is that
they aren't.
Yes, that was
On 24 Oct 2008, at 04:31 AM, Jonah H. Harris
[EMAIL PROTECTED] wrote:
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
[EMAIL PROTECTED] wrote:
I couldn't get async I/O to work on Linux. That is it worked but
performed
the same as reading one block at a time. On solaris the situation is
Based on what? I did test this and posted the data. The results I
posted showed that posix_fadvise on Linux performed nearly as well on
Linux as async I/O on Solaris on identical hardware.
More importantly it scaled with the number if drives. A 15 drive array
gets about 15x the performance
We did discuss this in Ottawa and I beleive your comment was the hint
is in the name referring to posix_fadvise.
In any case both aio and posix_fadvise are specified by posix so I
don't see either as a problem on that front.
I don't think we can ignore any longer that we effectively can't
77 matches
Mail list logo
