On Tue, Oct 26, 2010 at 9:59 PM, Josh Berkus wrote:
>
>> If you set wal_keep_segments=0, archive_mode=on, and
>> archive_command=, 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
> If you set wal_keep_segments=0, archive_mode=on, and
> archive_command=, 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 either w
On Thu, Oct 21, 2010 at 8:33 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus 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 how to make the
>> >
On Mon, Oct 25, 2010 at 9:45 PM, Robert Haas 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 work on the comme
Alvaro Herrera 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 find, the only use
of E
On Mon, Oct 25, 2010 at 12:51 PM, Peter Eisentraut 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 what the
Excerpts from Dean Rasheed's message of mar oct 26 15:46:56 -0300 2010:
> On 26 October 2010 17:04, David E. Wheeler 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 s
On Wed, Oct 20, 2010 at 5:54 PM, Marti Raudsepp 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 here.
>
> (1
On Tue, Oct 26, 2010 at 8:27 AM, Simon Riggs 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 value greater t
On Tue, 2010-10-26 at 16:08 -0400, Robert Haas wrote:
> On Tue, Oct 26, 2010 at 8:10 AM, Simon Riggs 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) Im
I wrote:
> Heikki Linnakangas 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 beginning of exec_eval_simp
On Tue, Oct 26, 2010 at 8:10 AM, Simon Riggs 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 already resolve t
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 segmen
On Mon, 2010-10-25 at 16:58 -0400, Robert Haas wrote:
> On Mon, Oct 25, 2010 at 4:10 PM, Greg Stark wrote:
> > On Mon, Oct 25, 2010 at 12:40 PM, Robert Haas wrote:
> >> Now, as Greg says, that might be what some people want, but it's
> >> certainly monumentally unserializable.
> >
> > To be clear
Greg Stark writes:
> On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane 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
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
On Tue, Oct 26, 2010 at 3:00 PM, Josh Berkus 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:
>> 1) The
> 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 2:57 PM, fazool mein wrote:
>
> On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas wrote:
>>
>> On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
>> wrote:
>> >
>> >> Can you please describe why
>> >> walsender reading directly from the buffers was given up? To avoid a
>> >>
On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas wrote:
> On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
> wrote:
> >
> >> Can you please describe why
> >> walsender reading directly from the buffers was given up? To avoid a lot
> >> of
> >> locking?
> >
> > To avoid locking yes, and complexit
On Tue, Oct 26, 2010 at 2:20 PM, Peter Eisentraut 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: http://www.enterprise
On Mon, Oct 25, 2010 at 8:28 AM, Tom Lane 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 use function poi
On Mon, 2010-10-25 at 17:57 -0700, Greg Stark wrote:
> On Mon, Oct 25, 2010 at 5:24 PM, Jeff Davis 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 is just an
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
On 26 October 2010 17:04, David E. Wheeler 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 want...
>
>
Folks,
I just realized I hadn't closed out the commitfest earlier. Have done
so.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david7
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
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 read directly from the bu
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:
http://www.postgresql.org/mailpref/pgsq
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 l
> 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 availab
On Tue, Oct 26, 2010 at 1:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis 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
> 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 max_w
Robert Haas writes:
> On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis 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 later. Some, like "plus" might be
>>
On Tue, Oct 26, 2010 at 1:26 PM, Jeff Davis 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 type. I a
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 w
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 t
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
On mån, 2010-10-25 at 22:10 +0200, Pavel Stehule wrote:
> 2010/10/25 Robert Haas :
> >> 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 op
Alvaro Herrera 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 in the buffer, but
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 (pgsql-
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
On Mon, Oct 25, 2010 at 6:31 PM, Robert Haas wrote:
> On Fri, Oct 22, 2010 at 3:08 PM, fazool mein 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
>> doing it correctly.
>> For reading
Alvaro Herrera 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 unreserved keyword, as in t
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?
>
On Tue, Oct 26, 2010 at 9:54 AM, Andrew Dunstan 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 the oth
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 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 i
2010/10/26 Robert Haas :
> On Mon, Oct 25, 2010 at 8:13 PM, Jeff Davis 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?
>>
>> Let's say for instance you
On Tue, Oct 26, 2010 at 12:35:13PM +0100, Dean Rasheed wrote:
> On 25 October 2010 21:01, David Fetter 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 neces
Thanks for your comments.
On Mon, 25 Oct 2010 15:05:51 +0200
Pavel Stehule 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
> > postgresql_fdw_connections view.
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 contri
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 contri
On 25 October 2010 21:01, David Fetter 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 here:
*** 971,9
might be performance and code refactoring.
> Does anyone have 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
-
Hi Merlin, I completely forgot about hstore! I'll give it a go. Thanks!
From: Merlin Moncure
To: Greg
Cc: Pavel Stehule ; pgsql-hackers@postgresql.org
Sent: Mon, 25 October, 2010 23:52:55
Subject: Re: [HACKERS] Composite Types and Function Parameters
On Mon,
On 25 October 2010 21:31, Tom Lane wrote:
> Andrew Dunstan 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 syntax that might still be thought
56 matches
Mail list logo
