On 25 October 2010 21:31, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
LABEL is already an unreserved keyword, and I'm pretty sure that's all
we'll need.
The only reason it's a keyword is the SECURITY LABEL patch that went
in a month or so ago; which is
Hi Merlin, I completely forgot about hstore! I'll give it a go. Thanks!
From: Merlin Moncure mmonc...@gmail.com
To: Greg grigo...@yahoo.co.uk
Cc: Pavel Stehule pavel.steh...@gmail.com; pgsql-hackers@postgresql.org
Sent: Mon, 25 October, 2010 23:52:55
Subject:
comments about it for the functionality? It might also be
used by SQL/MED and executor hooks, but I have no specific idea yet.
--
Itagaki Takahiro
extensible_execnodes-20101026.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On 25 October 2010 21:01, David Fetter da...@fetter.org wrote:
Folks,
Please find attached patch for $subject :)
Thanks for looking at this. I forgot about tab completion.
I think that the change to ALTER TRIGGER is not necessary. AFAICT it
works OK unmodified. In fact, the modified code
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
Ah, some reading of the patch reveals that the script defaults to the
control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat
Le 25 oct. 2010 à 17:26, Alvaro Herrera a écrit :
Ah, some reading of the patch reveals that the script defaults to the
control file name, but it can be overridden.
Yes, that's new in v10. In v11 I've kept that and removed the name property in
the control file, so that we have:
cat
Thanks for your comments.
On Mon, 25 Oct 2010 15:05:51 +0200
Pavel Stehule pavel.steh...@gmail.com wrote:
4) List of foreign connections
Users (especially DBAs?) might want to see list of foreign connections.
Currently postgresql_fdw provides its own connection list via
On Tue, Oct 26, 2010 at 12:35:13PM +0100, Dean Rasheed wrote:
On 25 October 2010 21:01, David Fetter da...@fetter.org wrote:
Folks,
Please find attached patch for $subject :)
Thanks for looking at this. I forgot about tab completion.
I think that the change to ALTER TRIGGER is not
2010/10/26 Robert Haas robertmh...@gmail.com:
On Mon, Oct 25, 2010 at 8:13 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 18:03 -0400, Robert Haas wrote:
Hmm. Do you have some concrete examples of cases where a range type
might want to do some representational optimization?
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
element, so how about ADD ELEMENT?
Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it
The attached patch modifies TRUNCATE ... RESTART IDENTITY so that if the
transaction rolls back the restart of the sequence will also be rolled back.
It follows the general outline discussed at
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00550.php of
assigning a new reffilenode to
On Tue, Oct 26, 2010 at 9:54 AM, Andrew Dunstan and...@dunslane.net wrote:
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
element, so how about ADD ELEMENT?
Unlike
Excerpts from Andrew Dunstan's message of mar oct 26 10:54:59 -0300 2010:
On 10/26/2010 03:02 AM, Dean Rasheed wrote:
In mathematics (and I think also computer science), the term
conventionally used the refer to the things in an enumeration is
element, so how about ADD ELEMENT?
Unlike
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Andrew Dunstan's message of mar oct 26 10:54:59 -0300 2010:
Unlike the other suggestions, ELEMENT is not currently a keyword. That
doesn't rule it out entirely, but it's a factor worth consideration.
It can be added as an
On Mon, Oct 25, 2010 at 6:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Oct 22, 2010 at 3:08 PM, fazool mein fazoolm...@gmail.com wrote:
I'm writing a function that will read data from the buffer in xlog (i.e.
from XLogCtl-pages and XLogCtl-xlblocks). I want to make sure that I am
Excerpts from Jeff Janes's message of mar oct 26 12:22:38 -0300 2010:
I don't think that holding WALWriteLock accomplishes much. It
prevents part of the buffer from being written out to OS/disk, and
thus becoming eligible for being overwritten in the buffer, but the
WALInsertLock prevents it
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you want...
+1
David
--
Sent via pgsql-hackers mailing list
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Jeff Janes's message of mar oct 26 12:22:38 -0300 2010:
I don't think that holding WALWriteLock accomplishes much. It
prevents part of the buffer from being written out to OS/disk, and
thus becoming eligible for being overwritten
On mån, 2010-10-25 at 22:10 +0200, Pavel Stehule wrote:
2010/10/25 Robert Haas robertmh...@gmail.com:
Example #1: Foreign key side is an array, every member must match some
PK.
CREATE TABLE pk (a int PRIMARKY KEY, ...);
CREATE TABLE fk (x int[] REFERENCES pk (a), ...);
What about
On mån, 2010-10-25 at 17:38 -0700, Jeff Davis wrote:
Implementing the foreign key side of this merely requires the system
to
have some knowledge of the required contains operator, which it
does
in the array case, and something can surely be arranged for the
range
case. The problem is
On Mon, 2010-10-25 at 21:07 -0400, Robert Haas wrote:
See, that gets complicated, because now you're restricting the range
of values that can be expressed by the range type to something less
than the natural range of the data type. I am not sure the value of
supporting that is sufficient to
On mån, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
Well if you lock multiple records then it's not clear what operations
you should conflict with. Removing any one of them wouldn't actually
invalidate the foreign key reference unless you remove the last one.
I always assumed this was why
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2010-10-25 at 21:07 -0400, Robert Haas wrote:
See, that gets complicated, because now you're restricting the range
of values that can be expressed by the range type to something less
than the natural range of the data
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
However, this is orthogonal, I think. I can always ask the user to
specify everything when creating a Range Type, and then we can make them
default to use the interface functions
What happens if max_wal_size is less than checkpoint_segments?
Currently a checkpoint tries to leave WAL files which were generated
from the prior ckpt start to current ckpt end. Because those WAL files
are required for crash recovery. But we should delete some of them
according to
On Tue, Oct 26, 2010 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis pg...@j-davis.com wrote:
However, this is orthogonal, I think. I can always ask the user to
specify everything when creating a Range Type,
Might I suggest adopting the same technique walsender does, ie just read
the data back from disk? There's a reason why we gave up trying to have
walsender read directly from the buffers.
That is exactly what I do not want to do, i.e. read from disk, as long as
the piece of WAL is available
On 26.10.2010 21:03, fazool mein wrote:
Might I suggest adopting the same technique walsender does, ie just read
the data back from disk? There's a reason why we gave up trying to have
walsender read directly from the buffers.
That is exactly what I do not want to do, i.e. read from disk, as
Isn't this error message logically backwards?
=# SECURITY LABEL ON SCHEMA public IS NULL;
ERROR: 22023: security label providers have been loaded
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 26.10.2010 21:03, fazool mein wrote:
Might I suggest adopting the same technique walsender does, ie just read
the data back from disk? There's a reason why we gave up trying to have
walsender
Folks,
I just realized I hadn't closed out the commitfest earlier. Have done
so.
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal:
On 26 October 2010 17:04, David E. Wheeler da...@kineticode.com wrote:
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad choice.
I still think we should just go for LABEL and be done with it. But
y'all can ignore me if you
On Tue, 2010-10-26 at 20:25 +0300, Peter Eisentraut wrote:
Let's say you have
PK
1
2
3
4
5
FK
[1,2,3]
[3,4,5]
[4,4,4]
When you delete PK = 3, what do you expect to happen? OK, you might
decide to delete the first two rows from the FK table. This might or
might not make
On Mon, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis pg...@j-davis.com wrote:
I think that's easier when the PK must contain the FK, because then you
only need to lock one record. Even when you need to lock multiple
records, it seems feasible, and
On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But it might be a good change anyway from a performance standpoint,
in case a call through a function pointer is faster than a big switch.
Have you tried benchmarking it on common platforms?
I've always wondered why we didn't
On Tue, Oct 26, 2010 at 2:20 PM, Peter Eisentraut pete...@gmx.net wrote:
Isn't this error message logically backwards?
=# SECURITY LABEL ON SCHEMA public IS NULL;
ERROR: 22023: security label providers have been loaded
Ouch. How embarrassing. Fixed.
--
Robert Haas
EnterpriseDB:
On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Can you please describe why
walsender reading directly from the buffers was given up? To avoid a lot
of
locking?
On Tue, Oct 26, 2010 at 2:57 PM, fazool mein fazoolm...@gmail.com wrote:
On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Can you please describe why
walsender
I agree that the standby might get ahead, but this doesn't necessarily
lead to database corruption. Here, the interesting case is what happens
when the primary fails, which can lead to *either* of the following two
cases:
1) The standby, due to some triggering mechanism, becomes the new
On Tue, Oct 26, 2010 at 3:00 PM, Josh Berkus j...@agliodbs.com wrote:
I agree that the standby might get ahead, but this doesn't necessarily
lead to database corruption. Here, the interesting case is what happens
when the primary fails, which can lead to *either* of the following two
cases:
On tis, 2010-10-26 at 11:53 -0700, Jeff Davis wrote:
Case #2 is the strange one, I think. It's not actually just an
adaptation of #1. #1 requires that all elements of the array have a
corresponding PK value; but #2 just requires that one of them does.
Peter, can you clarify case #2? Did you
Greg Stark gsst...@mit.edu writes:
On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But it might be a good change anyway from a performance standpoint,
in case a call through a function pointer is faster than a big switch.
Have you tried benchmarking it on common platforms?
On Mon, 2010-10-25 at 16:58 -0400, Robert Haas wrote:
On Mon, Oct 25, 2010 at 4:10 PM, Greg Stark gsst...@mit.edu wrote:
On Mon, Oct 25, 2010 at 12:40 PM, Robert Haas robertmh...@gmail.com wrote:
Now, as Greg says, that might be what some people want, but it's
certainly monumentally
On Thu, 2010-10-21 at 20:57 -0400, Robert Haas wrote:
Very true. But the lack of a -1 setting for wal_keep_segments means
that if you would like to take a backup without archiving, you must
set wal_keep_segments to a value greater than or equal to the rate at
which you generate WAL segments
On Tue, Oct 26, 2010 at 8:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
I agree with your analysis. Let me review...
[review]
Sounds like we're on the same page.
Two options for resolution are
1) Throw SERIALIZABLE error
2) Implement something similar to EvalPlanQual
As you say, we
I wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
One simple idea is to keep a flag along with the executor state to
indicate that the executor state is currently in use. Set it just before
calling ExecEvalExpr, and reset afterwards. If the flag is already set
in the
On Tue, 2010-10-26 at 16:08 -0400, Robert Haas wrote:
On Tue, Oct 26, 2010 at 8:10 AM, Simon Riggs si...@2ndquadrant.com wrote:
I agree with your analysis. Let me review...
[review]
Sounds like we're on the same page.
Two options for resolution are
1) Throw SERIALIZABLE error
On Tue, Oct 26, 2010 at 8:27 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-10-21 at 20:57 -0400, Robert Haas wrote:
Very true. But the lack of a -1 setting for wal_keep_segments means
that if you would like to take a backup without archiving, you must
set wal_keep_segments to a
On Wed, Oct 20, 2010 at 5:54 PM, Marti Raudsepp ma...@juffo.org wrote:
Here's the second patch from my coccicheck run. Originally it flagged
the fact that the opened file in psql's process_file() wasn't being
closed in the ON_ERROR_STOP path, but there seem to be two more
unintended behaviors
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
On 26 October 2010 17:04, David E. Wheeler da...@kineticode.com wrote:
On Oct 26, 2010, at 7:15 AM, Robert Haas wrote:
Notwithstanding the above, I don't think ELEMENT would be a very bad
choice.
I still think we
On Mon, Oct 25, 2010 at 12:51 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-10-25 at 09:33 -0400, Robert Haas wrote:
It seems we're still missing some relevant details, because hdparm
doesn't seem to work on SCSI devices. Is sdparm the right utility in
that case? Does anyone know
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
Well ELEMENT is a reserved keyword in SQL:2008, to support multisets,
so if we ever supported that feature...
Hah!
Hmmm ... I dug through SQL:2008, and so far as I can
On Mon, Oct 25, 2010 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
Oh. You know, I am realizing that I misread this patch. This hook is
actually after authentication has been done; it's merely before we've
told the client what happened. So maybe this is committable as-is,
modulo some
On Thu, Oct 21, 2010 at 8:33 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/20/10 6:54 PM, Robert Haas wrote:
I find it impossible to believe that's
a good decision, and IMHO we should be focusing on
If you set wal_keep_segments=0, archive_mode=on, and
archive_command=something, you might run out of disk space.
If you set wal_keep_segments=-1, you might run out of disk space.
Are you any more screwed in the second case than you are in the first
case?
It is the same to the user
On Tue, Oct 26, 2010 at 9:59 PM, Josh Berkus j...@agliodbs.com wrote:
If you set wal_keep_segments=0, archive_mode=on, and
archive_command=something, you might run out of disk space.
If you set wal_keep_segments=-1, you might run out of disk space.
Are you any more screwed in the second
56 matches
Mail list logo
