I found a workaround: domain type defined as: CREATE DOMAIN currency AS
numeric(16,4);
Thank you!
Dean Rasheed writes:
> On 28 March 2013 00:04, Tom Lane wrote:
>> Yeah, if '[1:1]={0}'::int[] is distinct from '[2:2]={0}'::int[],
>> it's a bit hard to argue that '[1:0]={}'::int[] must not be
>> distinct from '[2:1]={}'::int[].
> You could make the exact same argument for ranges --- if
> '[1,1
On 2013-03-19 08:57:31 +0900, Michael Paquier wrote:
> On Tue, Mar 19, 2013 at 3:24 AM, Fujii Masao wrote:
>
> > On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
> > wrote:
> > > I have been working on improving the code of the 2 patches:
> > > 1) reltoastidxid removal:
> >
> > > - Fix a bug wi
On 2013-03-28 10:18:45 +0900, Michael Paquier wrote:
> On Thu, Mar 28, 2013 at 3:12 AM, Fujii Masao wrote:
> Since we call relation_open() with lockmode, ISTM that we should also call
> > relation_close() with the same lockmode instead of NoLock. No?
> >
> Agreed on that.
That doesn't really hold
On 28 March 2013 00:04, Tom Lane wrote:
> Brendan Jurd writes:
>> On 28 March 2013 09:39, Dean Rasheed wrote:
>>> Maybe. But even in 1-D, it's still jumping from having one empty array
>>> to infinitely many starting at different indexes, e.g., '{}'::int[] !=
>>> '[4:3]={}'::int[]. There may be
> We already have the ability to define lower bounds other than 1 on
> arrays, and it would be inconsistent to allow that for arrays with
> elements, but not for arrays without. I could imagine somebody
> wanting to create an empty zero-based array, and then iteratively
> append elements to it.
On Thu, Mar 28, 2013 at 6:05 AM, Heikki Linnakangas wrote:
> What exactly was wrong with pg_basebackup -R, without
> recovery_config_directory?
>
pg_basebackup -R generates automatically recovery.conf inside data folder,
so if
recovery_config_directory is specified the slave startup will fail.
Th
Brendan Jurd writes:
> On 28 March 2013 09:39, Dean Rasheed wrote:
>> Maybe. But even in 1-D, it's still jumping from having one empty array
>> to infinitely many starting at different indexes, e.g., '{}'::int[] !=
>> '[4:3]={}'::int[]. There may be a certain logic to that, but I'm not
>> convinc
On 28 March 2013 09:39, Dean Rasheed wrote:
> On 27 March 2013 17:14, Brendan Jurd wrote:
>> Well the fix is primarily about 1-D empty arrays, and in that respect
>> it is much less confusing than what we have now.
>
> Maybe. But even in 1-D, it's still jumping from having one empty array
> to in
On 27 March 2013 23:01, Tom Lane wrote:
> Simon Riggs writes:
>> On 27 March 2013 20:40, Heikki Linnakangas wrote:
>>> While looking at bug #7969, it occurred to me that it would be nice if we
>>> could catch resource leaks in WAL redo routines better. It would be useful
>>> during development,
Simon Riggs writes:
> On 27 March 2013 20:40, Heikki Linnakangas wrote:
>> While looking at bug #7969, it occurred to me that it would be nice if we
>> could catch resource leaks in WAL redo routines better. It would be useful
>> during development, to catch bugs earlier, and it could've turned t
On 27 March 2013 17:14, Brendan Jurd wrote:
> On 28 March 2013 00:21, Dean Rasheed wrote:
>> The patch is also allowing '{{},{},{}}' which is described up-thread
>> as a 2-D empty array. That's pretty misleading, since it has length 3
>> (in the first dimension). '{{},{}}' and '{{}}' are both "mo
Hello
I redesigned output from plpgsql_check_function. Now, it returns table
everytime.
Litlle bit code simplification.
postgres=# \sf fx
CREATE OR REPLACE FUNCTION public.fx(integer)
RETURNS integer
LANGUAGE plpgsql
AS $function$
BEGIN
RETURN (SELECT a FROM t1 WHERE b < $1);
END;
$function$
On Wed, Mar 27, 2013 at 9:03 AM, Heikki Linnakangas
wrote:
> Writing it like that suggests that autovac might sometimes be NULL, even if
> deadlock_state == DS_BLOCKED_BY_AUTOVACUUM. From your explanation above, I
> gather that's not possible (and I think you're right), so the NULL check is
> unne
On 27 March 2013 20:40, Heikki Linnakangas wrote:
> While looking at bug #7969, it occurred to me that it would be nice if we
> could catch resource leaks in WAL redo routines better. It would be useful
> during development, to catch bugs earlier, and it could've turned that
> replay-stopping err
On 27 March 2013 21:05, Heikki Linnakangas wrote:
>> Same argument applies to all conf files, not just recovery.conf.
>>
>> Sounds like the patch to add -R to pg_basebackup should be revoked as
>> being not well thought out. Or it should be fixed, in which case this
>> works the same.
>
> What ex
Simon Riggs wrote:
> doc/src/sgml/config.sgml | 17 +
So that doc builds could proceed without error I fixed the obvious
pasto in config.sgml.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mail
Peter Eisentraut writes:
> On 3/24/13 1:55 PM, Tom Lane wrote:
>> I experimented a bit with this version of the patch. The hunk that
>> removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build
>> breaks the build for me, so I took it out.
> What was the error message? Probably not i
On 27.03.2013 20:02, Simon Riggs wrote:
On 27 March 2013 17:50, Heikki Linnakangas wrote:
Imagine that you have set recovery_config_directory='/foo/' in the master
server. Now you want to set up a standby, so you do:'
pg_basebackup -D data-standby -R
With the -R option, pg_basebackup creates
On 3/24/13 1:55 PM, Tom Lane wrote:
> I experimented a bit with this version of the patch. The hunk that
> removes -I$(libpq_srcdir) and $(libpq) from the ecpg/compatlib build
> breaks the build for me, so I took it out.
What was the error message? Probably not important, but curious.
> With th
While looking at bug #7969, it occurred to me that it would be nice if
we could catch resource leaks in WAL redo routines better. It would be
useful during development, to catch bugs earlier, and it could've turned
that replay-stopping error into a warning.
For regular transactions, we use Res
On 1/15/13 7:04 AM, Peter Eisentraut wrote:
>> It would seem to be much more in the spirit of things to simply list
>> > the
>> > allowed plugins in a GUC variable, like
>> >
>> > some_clever_name_here = $libdir/this, $libdir/that
> Here is a patch, with some_clever_name = user_loadable_libraries
On 1/19/13 8:45 AM, Kohei KaiGai wrote:
> I think, it is a time to investigate separation of database superuser
> privileges
> into several fine-grained capabilities, like as operating system doing.
> https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h
The Linux capabili
On 1/11/13 10:25 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> It turned out that actually getting rid of lanpltrusted would be too
>> invasive, especially because some language handlers use it to determine
>> their own behavior.
>
>> So instead the lanpltrusted attribute now just determined
On 03/27/2013 03:49 PM, Stefan Kaltenbrunner wrote:
On 03/26/2013 10:18 PM, Tom Lane wrote:
Andrew Dunstan writes:
There is some timeout code already in the buildfarm client. It was
originally put there to help us when we got CVS hangs, a not infrequent
occurrence in the early days, so it's c
On 03/26/2013 10:18 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> There is some timeout code already in the buildfarm client. It was
>> originally put there to help us when we got CVS hangs, a not infrequent
>> occurrence in the early days, so it's currently only used if configured
>> for the
On 27 March 2013 18:15, Fujii Masao wrote:
> This patch breaks also pg_ctl promote because it always checks the existence
> of
> $PGDATA/recovery.conf.
You're right. It does. Good catch.
That also suggest a solution: create a status file called
$PGDATA/recovery_in_progress which would then all
On 03/26/2013 11:30 PM, Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> hmm - will look into that in a bit - but I also just noticed that on the
>> same day spoonbill broke there was also a commit to that file
>> immediately before that code adding the fflush() calls.
>
> It's hard to see how t
On Thu, Mar 28, 2013 at 2:58 AM, Simon Riggs wrote:
> Arguments against?
>
Also the fact that many discussions have been done on recovery.conf between
the time this feature has been decided and actually committed (perhaps too
promptly just by looking at how this thread is becoming long)?
--
Mich
On Thu, Mar 28, 2013 at 1:24 AM, Heikki Linnakangas
wrote:
> On 27.03.2013 18:10, Simon Riggs wrote:
>>
>> On 27 March 2013 15:35, Heikki Linnakangas
>> wrote:
>>>
>>> Ok, cool. Can you please revert this commit so that we can move on, then?
>>
>>
>> Please explain why you want this reverted, with
On Wed, Mar 27, 2013 at 8:26 AM, Michael Paquier
wrote:
>
>
> On Wed, Mar 27, 2013 at 3:05 AM, Fujii Masao wrote:
>>
>> ISTM you failed to make the patches from your repository.
>> 20130323_1_toastindex_v7.patch contains all the changes of
>> 20130323_2_reindex_concurrently_v25.patch
>
> Oops, so
On 27 March 2013 17:50, Heikki Linnakangas wrote:
> On 27.03.2013 19:34, Simon Riggs wrote:
>>
>> On 27 March 2013 16:24, Heikki Linnakangas
>> wrote:
>>>
>>> Lastly, it breaks the new pg_basebackup -R
>>>
>>> functionality; pg_basebackup will create the recovery.conf file, but it
>>> won't take e
On 27 March 2013 17:23, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 27.03.2013 18:10, Simon Riggs wrote:
>>> On 27 March 2013 15:35, Heikki Linnakangas wrote:
Ok, cool. Can you please revert this commit so that we can move on, then?
>
>>> Please explain why you want this reverted, wi
On 27.03.2013 19:34, Simon Riggs wrote:
On 27 March 2013 16:24, Heikki Linnakangas wrote:
Lastly, it breaks the new pg_basebackup -R
functionality; pg_basebackup will create the recovery.conf file, but it
won't take effect.
AFAIK pg_basebackup doesn't backup files not in the data directory an
On 27 March 2013 16:24, Heikki Linnakangas wrote:
> On 27.03.2013 18:10, Simon Riggs wrote:
>>
>> On 27 March 2013 15:35, Heikki Linnakangas
>> wrote:
>>>
>>> Ok, cool. Can you please revert this commit so that we can move on, then?
>>
>>
>> Please explain why you want this reverted, without menti
Heikki Linnakangas writes:
> On 27.03.2013 18:10, Simon Riggs wrote:
>> On 27 March 2013 15:35, Heikki Linnakangas wrote:
>>> Ok, cool. Can you please revert this commit so that we can move on, then?
>> Please explain why you want this reverted, without mentioning the
>> other task we agree is r
On 28 March 2013 00:21, Dean Rasheed wrote:
> The patch is also allowing '{{},{},{}}' which is described up-thread
> as a 2-D empty array. That's pretty misleading, since it has length 3
> (in the first dimension). '{{},{}}' and '{{}}' are both "more empty",
> but neither is completely empty.
> I
Konstantin Izmailov writes:
> Is it possible to import money into Postgres with 4 digits after the dot?
You would need to set lc_monetary to a locale that permits that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 27.03.2013 18:10, Simon Riggs wrote:
On 27 March 2013 15:35, Heikki Linnakangas wrote:
Ok, cool. Can you please revert this commit so that we can move on, then?
Please explain why you want this reverted, without mentioning the
other task we agree is required.
If an admin can't trust that
On 27.03.2013 15:28, Tom Lane wrote:
Heikki Linnakangas writes:
Alvaro Herrera wrote:
Not happy with misc.c as a filename.
There's a bunch of files called pg_backup_*.c that are also shared
between pg_dump and pg_restore, so perhaps pg_backup_utils.c?
Works for me.
Ok, sold.
- Heikki
I'm trying to insert data into Postgres using COPY command. The data
originates from AdventureWorksDW. However, it fails with: "ERROR: invalid
input syntax for type money: "2171.2942" "
Is it possible to import money into Postgres with 4 digits after the dot?
On 27 March 2013 15:35, Heikki Linnakangas wrote:
> On 27.03.2013 17:23, Simon Riggs wrote:
>>
>> On 27 March 2013 14:20, Heikki Linnakangas
>> wrote:
>>>
>>> You didn't answer the question. Does this get us any closer to merging
>>>
>>> postgresql.conf and recovery.conf? Why is this bundled in wi
On 27.03.2013 17:23, Simon Riggs wrote:
On 27 March 2013 14:20, Heikki Linnakangas wrote:
You didn't answer the question. Does this get us any closer to merging
postgresql.conf and recovery.conf? Why is this bundled in with that?
Why do you think these points are bundled?
Because you say th
On 27 March 2013 15:19, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 10:51 AM, Thom Brown wrote:
>>> create here is referring to the sepgsql permission, not the SQL
>>> command, so it's correct as-is.
>>
>> My bad.
>
> Here's an attempt at reworking the whole section to be more
> understandable.
On 27 March 2013 14:20, Heikki Linnakangas wrote:
> On 27.03.2013 15:09, Simon Riggs wrote:
>>
>> On 27 March 2013 12:12, Heikki Linnakangas
>> wrote:
>>>
>>> On 27.03.2013 13:47, Simon Riggs wrote:
Allow external recovery_config_directory
If required, recovery.conf can now be
On Wed, Mar 27, 2013 at 10:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Mar 27, 2013 at 10:20 AM, Tom Lane wrote:
>>> It's arguable that we should unsetenv all of these inside the postmaster
>>> (once it's absorbed the values from the ones it historically pays
>>> attention to), so th
On Wed, Mar 27, 2013 at 10:51 AM, Thom Brown wrote:
>> create here is referring to the sepgsql permission, not the SQL
>> command, so it's correct as-is.
>
> My bad.
Here's an attempt at reworking the whole section to be more
understandable. I took the liberty of rearranging the text into
bullet
On 27 March 2013 14:50, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 9:09 AM, Thom Brown wrote:
>> Perhaps something along the lines of:
>>
>> "When a CREATE FUNCTION command is executed, the install permission
>> will be checked to determine whether the LEAKPROOF attribute was
>> present. This p
On Wed, Mar 27, 2013 at 9:09 AM, Thom Brown wrote:
> Perhaps something along the lines of:
>
> "When a CREATE FUNCTION command is executed, the install permission
> will be checked to determine whether the LEAKPROOF attribute was
> present. This permission will also be checked when the user tries
Robert Haas writes:
> On Wed, Mar 27, 2013 at 10:20 AM, Tom Lane wrote:
>> It's arguable that we should unsetenv all of these inside the postmaster
>> (once it's absorbed the values from the ones it historically pays
>> attention to), so that the postmaster environment does not impinge on
>> the
On Wed, Mar 27, 2013 at 11:26 PM, Robert Haas wrote:
> There are also weird edge cases here when the server is promoted. The
> recovery.conf file won't exist any more, but the GUC settings changes
> it contains will live on until the next SIGHUP.
>
Yes indeed, I forgot that.
The proposal Greg S
On Wed, Mar 27, 2013 at 10:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 25, 2013 at 4:38 AM, Albe Laurenz
>> wrote:
>>> If possible, I would suggest the following defaults (that's what I as
>>> a user would expect without thinking too hard):
>>> 1) Default the user to the current
Robert Haas escribió:
> On Wed, Mar 27, 2013 at 10:16 AM, Heikki Linnakangas
> wrote:
> > I'm quite worried about the security ramifications of this patch. Today, if
> > you're not sure if a system has e.g sslinfo installed, you can safely just
> > run "CREATE EXTENSION sslinfo". With this patch,
On 27.03.2013 16:16, Heikki Linnakangas wrote:
Below are some random bugs that I bumped into while testing. These could
be fixed, but frankly I think this should be rejected for security reasons.
Also:
pg_dump does not dump the owner of an extension template correctly.
- Heikki
--
Sent via
On Wed, Mar 27, 2013 at 10:16 AM, Heikki Linnakangas
wrote:
> I'm quite worried about the security ramifications of this patch. Today, if
> you're not sure if a system has e.g sslinfo installed, you can safely just
> run "CREATE EXTENSION sslinfo". With this patch, that's no longer true,
> because
On Wed, Mar 27, 2013 at 10:15 AM, Michael Paquier
wrote:
> Here would be the plan:
> 1) we move all the recovery parameters to GUC as proposed Masao's patch (and
> somewhat my patch now).
> 2) as default, the custom file that is used to trigger recovery is called
> recovery.conf and needs to be lo
On 27.03.2013 15:09, Simon Riggs wrote:
On 27 March 2013 12:12, Heikki Linnakangas wrote:
On 27.03.2013 13:47, Simon Riggs wrote:
Allow external recovery_config_directory
If required, recovery.conf can now be located outside of the data
directory.
Server needs read/write permissions on this d
Robert Haas writes:
> On Mon, Mar 25, 2013 at 4:38 AM, Albe Laurenz wrote:
>> If possible, I would suggest the following defaults (that's what I as
>> a user would expect without thinking too hard):
>> 1) Default the user to the current effective database user.
>> 2) Default the port to 5432.
>>
On Wed, Mar 27, 2013 at 10:43 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> 3. Would it make sense to make the option "recovery_config_file", pointing
> to the file, instead of just the directory?
>
+1 on that. I just sent the same suggestion.
--
Michael
On 15.03.2013 23:00, Alvaro Herrera wrote:
Dimitri Fontaine wrote:
Please find attached v3 of the Extension Templates patch, with full
pg_dump support thanks to having merged default_full_version, appended
with some regression tests now that it's possible.
Here's a rebased version; there were
On Wed, Mar 27, 2013 at 10:11 PM, Simon Riggs wrote:
> On 27 March 2013 12:59, Michael Paquier wrote:
>
> > Also, based on Greg's spec (that Robert and I basically agreed on), if
> > recovery.conf is found at the root of data folder an error is returned to
> > user, recommending him to migrate c
On Wed, Mar 27, 2013 at 10:06 AM, Simon Riggs wrote:
> On 27 March 2013 13:53, Robert Haas wrote:
>>> Please look again.
>>
>> I have a better idea: how about if you tell me where you see any such
>> message? Because I think the reason I don't see it is because it
>> doesn't exist.
>
> http://ww
On 2013-03-27 10:06:19 -0400, Robert Haas wrote:
> On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith wrote:
> > to get them going again. If the install had checksums, I could have figured
> > out which blocks were damaged and manually fixed them, basically go on a
> > hunt for torn pages and the last k
On Mon, Mar 18, 2013 at 4:31 PM, Greg Smith wrote:
> to get them going again. If the install had checksums, I could have figured
> out which blocks were damaged and manually fixed them, basically go on a
> hunt for torn pages and the last known good copy via full-page write.
Wow. How would you
On 27 March 2013 13:53, Robert Haas wrote:
>> Please look again.
>
> I have a better idea: how about if you tell me where you see any such
> message? Because I think the reason I don't see it is because it
> doesn't exist.
http://www.postgresql.org/message-id/20130109204225.gb21...@momjian.us
h
On Wed, Mar 27, 2013 at 9:40 AM, Simon Riggs wrote:
> On 27 March 2013 13:21, Robert Haas wrote:
>> On Wed, Mar 27, 2013 at 9:11 AM, Simon Riggs wrote:
>>> On 27 March 2013 12:59, Michael Paquier wrote:
>>>
Also, based on Greg's spec (that Robert and I basically agreed on), if
recover
On 27.03.2013 15:11, Simon Riggs wrote:
On 27 March 2013 12:59, Michael Paquier wrote:
Also, based on Greg's spec (that Robert and I basically agreed on), if
recovery.conf is found at the root of data folder an error is returned to
user, recommending him to migrate correctly by referring to de
On 27 March 2013 13:21, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 9:11 AM, Simon Riggs wrote:
>> On 27 March 2013 12:59, Michael Paquier wrote:
>>
>>> Also, based on Greg's spec (that Robert and I basically agreed on), if
>>> recovery.conf is found at the root of data folder an error is retur
Heikki Linnakangas writes:
>> Alvaro Herrera wrote:
>>> Not happy with misc.c as a filename.
> There's a bunch of files called pg_backup_*.c that are also shared
> between pg_dump and pg_restore, so perhaps pg_backup_utils.c?
Works for me. There's inherently not going to be a lot of content
i
On 26 March 2013 20:44, Tom Lane wrote:
> Robert Haas writes:
>> Well, you could easily change array_ndims() to error out if ARR_NDIM()
>> is negative or more than MAXDIM and return NULL only if it's exactly
>> 0. That wouldn't break backward compatibility because it would throw
>> an error only
On Wed, Mar 27, 2013 at 9:11 AM, Simon Riggs wrote:
> On 27 March 2013 12:59, Michael Paquier wrote:
>
>> Also, based on Greg's spec (that Robert and I basically agreed on), if
>> recovery.conf is found at the root of data folder an error is returned to
>> user, recommending him to migrate correc
On Mon, Mar 25, 2013 at 4:38 AM, Albe Laurenz wrote:
> I agree that this is an unhappy situation.
>
> If possible, I would suggest the following defaults (that's what I as
> a user would expect without thinking too hard):
> 1) Default the user to the current effective database user.
> 2) Default t
On 27 March 2013 12:59, Michael Paquier wrote:
> Also, based on Greg's spec (that Robert and I basically agreed on), if
> recovery.conf is found at the root of data folder an error is returned to
> user, recommending him to migrate correctly by referring to dedicated
> documentation.
I'm followi
On 27 March 2013 12:58, Robert Haas wrote:
> On Wed, Mar 27, 2013 at 8:44 AM, Thom Brown wrote:
>> On 27 March 2013 12:33, Robert Haas wrote:
>>> sepgsql: Support for new post-ALTER access hook.
>>
>> I notice that due to commit bc5334d8 I can't actually build the docs
>> at the moment.
>>
>> Bu
On 27 March 2013 12:12, Heikki Linnakangas wrote:
> On 27.03.2013 13:47, Simon Riggs wrote:
>>
>> Allow external recovery_config_directory
>> If required, recovery.conf can now be located outside of the data
>> directory.
>> Server needs read/write permissions on this directory.
>
>
> This was a s
On 27.03.2013 14:50, Robert Haas wrote:
On Sat, Mar 23, 2013 at 6:45 PM, Xi Wang wrote:
A side question: at src/backend/storage/lmgr/proc.c:1150, is there a
null pointer deference for `autovac'?
I think you mean on line 1142:
PGPROC *autovac = GetBlockingAutoVacuumPgproc
On Wed, Mar 27, 2013 at 9:59 PM, Michael Paquier
wrote:
>
>
> On Wed, Mar 27, 2013 at 9:12 PM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 27.03.2013 13:47, Simon Riggs wrote:
>>
>>> Allow external recovery_config_directory
>>> If required, recovery.conf can now be located outsi
On Wed, Mar 27, 2013 at 9:12 PM, Heikki Linnakangas wrote:
> On 27.03.2013 13:47, Simon Riggs wrote:
>
>> Allow external recovery_config_directory
>> If required, recovery.conf can now be located outside of the data
>> directory.
>> Server needs read/write permissions on this directory.
>>
>
> Th
On Wed, Mar 27, 2013 at 8:44 AM, Thom Brown wrote:
> On 27 March 2013 12:33, Robert Haas wrote:
>> sepgsql: Support for new post-ALTER access hook.
>
> I notice that due to commit bc5334d8 I can't actually build the docs
> at the moment.
>
> But I think the language here definitely needs improvin
On Sat, Mar 23, 2013 at 6:45 PM, Xi Wang wrote:
> A side question: at src/backend/storage/lmgr/proc.c:1150, is there a
> null pointer deference for `autovac'?
Not really. If the deadlock_state is DS_BLOCKED_BY_AUTOVACUUM, there
has to be a blocking autovacuum proc. As in the other case that you
On Sat, Mar 23, 2013 at 6:38 PM, Xi Wang wrote:
> CHECK_STACK_DEPTH checks if errordata_stack_depth is negative.
> Move the dereference of &errordata[errordata_stack_depth] after
> the check to avoid out-of-bounds read.
This seems sensible and I'm inclined to commit it. It's unlikely to
matter v
On Fri, Jan 25, 2013 at 10:29 AM, Kohei KaiGai wrote:
> I asked folks of Debian-JP how and when does package maintainer
> pushes new versions. Usually, new versions shall be pushed to
> unstable branch, then testing and stable. But it is now feature freeze
> period thus it is prohibited to push ne
On Tue, Mar 19, 2013 at 9:28 AM, Kohei KaiGai wrote:
>> But I've left it the way you have it for now. Part
>> of me thinks that what you really want here is a pre-alter hook rather
>> than a post-alter hook...
>>
> Yes. It is the reason why I wanted to put a pre-alter hook for this
> code path e
On 27.03.2013 13:47, Simon Riggs wrote:
Allow external recovery_config_directory
If required, recovery.conf can now be located outside of the data directory.
Server needs read/write permissions on this directory.
This was a surprising commit. Does this get us any closer to merging
postgresql.c
On 24 December 2012 17:15, Andres Freund wrote:
>> On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
>> > From all of the above, I think its worth doing this
>> > * allowing recovery.conf to be in a different directory
>> > * make recovery config parameters into GUCs
>> > * no other ch
On 27 March 2013 10:57, Kohei KaiGai wrote:
> 2013/3/25 Simon Riggs :
>> On 19 March 2013 15:08, Kohei KaiGai wrote:
>>
>>> It is much helpful if someone give me comments around these
>>> arguable portions from the standpoint with fresh eyes.
>>
>> My feeling at this point is that I don't think I
I moved Row Level Security patch to the 2013-Next commitfest.
2013/3/27 Kohei KaiGai :
> 2013/3/25 Simon Riggs :
>> On 19 March 2013 15:08, Kohei KaiGai wrote:
>>
>>> It is much helpful if someone give me comments around these
>>> arguable portions from the standpoint with fresh eyes.
>>
>> My fe
2013/3/25 Simon Riggs :
> On 19 March 2013 15:08, Kohei KaiGai wrote:
>
>> It is much helpful if someone give me comments around these
>> arguable portions from the standpoint with fresh eyes.
>
> My feeling at this point is that I don't think I should commit this
> and related patches without mor
(Resending, I think google mail failed delivering it first time).
Hi folks,
I've always been fascinated with genetic algorithms. Having had a chance to
implement it once before, to solve real life issue - I knew they can be
brilliant at searching for right solutions in multi dimensional space.
On 27 March 2013 08:12, Heikki Linnakangas wrote:
> On 27.03.2013 08:51, Atri Sharma wrote:
I'm a bit confused as to why this is being proposed as a
Postgres-related project. I don't even know what MADlib is, but I'm
pretty darn sure that no part of Postgres uses it. KNNGist
Darren Duncan wrote:
> Consider the context however. We're talking about a UNIQUE constraint and so
> what we want to do is prevent the existence of multiple tuples in a relation
> that are the same for some defined subset of their attributes. I would argue
> that logically, and commonsensically,
> But it would be even better if MADLib would apply to GSoC as an independent
> organization. The deadline for organization applications is on March 29th,
> so if the MADLIb people are interested in that, they need to hurry and send
> the application right now.
Agreed. Is there any way we could ad
On Tuesday, March 26, 2013 9:49 PM Greg Stark wrote:
> On Tue, Mar 26, 2013 at 7:31 AM, Amit Kapila
> wrote:
> > Above ideas could be useful to improve concurrency testing and can
> also be
> > helpful to generate test cases for some of the complicated bugs for
> which
> > there is no direct test.
On 27.03.2013 08:51, Atri Sharma wrote:
I'm a bit confused as to why this is being proposed as a
Postgres-related project. I don't even know what MADlib is, but I'm
pretty darn sure that no part of Postgres uses it. KNNGist certainly
doesn't.
It's a reasonably well established extension for P
On 26.03.2013 22:14, Kevin Grittner wrote:
Alvaro Herrera wrote:
Not happy with misc.c as a filename.
We already have two misc.c files:
src/backend/utils/adt/misc.c
src/interfaces/ecpg/ecpglib/misc.c
I much prefer not to repeat the same filename in different
directories if we can avoid it.
95 matches
Mail list logo
