On 01/18/2012 04:23 PM, Marti Raudsepp wrote:
The updated patch looks good, marking as 'Ready for Committer'
Patches without documentation are never ready for commit. For this one,
I'm not sure if that should be in the form of a reference example in
contrib, or just something that documents
> > And primary keys are anyways not inherited. So why is the conisonly
> > field interfering in rename? Seems quite orthogonal to me.
>
> In the past, each kind of constraint was either always inherited or
> always not, implicitly. Now, for check constraints we can choose what
> we want, and in t
On fre, 2012-01-20 at 09:08 +0530, Nikhil Sontakke wrote:
> > Umm, conisonly is set as false from primary key entries in
> pg_constraint.
> And primary keys are anyways not inherited. So why is the conisonly
> field interfering in rename? Seems quite orthogonal to me.
In the past, each kind of co
Andrew Dunstan writes:
> On 01/19/2012 04:12 PM, Robert Haas wrote:
>> On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan wrote:
>>> The spec only allows unescaped Unicode chars (and for our purposes that
>>> means UTF8). An unescaped non-ASCII character in, say, ISO-8859-1 will
>>> result in someth
On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote:
> For that reason, I wonder if I should just hard-code the plpython
> rename into the pg_upgrade test in check_loadable_libraries().
Yes, I haven't come up with a better solution either.
If this becomes a general problem, we might need to ad
On 01/19/2012 10:52 AM, Robert Haas wrote:
It's not quite clear from your email, but I gather that the way that
this is intended to work is that these values increment every time we
checkpoint?
Right--they get updated in the same atomic bump that moves up things
like buffers_checkpoint
Also
Robert Haas writes:
> On Thu, Jan 19, 2012 at 3:42 PM, Dimitri Fontaine
>> I'm trying to open the extension facilities (versions being the first of
>> them, think \dx) to application PL code, and to hosted environments
>> where you're not granted access to the server's file system.
> I guess the
I chewed a bit on Heikki's comment that similarity to the query planning
parameters might be useful, and Robert's that being able to explain how
the feature works more easily has value. I have an initial adjustment
of my general idea that I think moves usefully in both those directions.
The e
On Sun, Jan 15, 2012 at 11:05 PM, Kevin Grittner
wrote:
> Attached is a version of a previously posted patch which has been
> modified based on on-list feedback from Álvaro.
>
> This is a generalized trigger function which can be used as an AFTER
> EACH ROW trigger on any table which has a primary
On 12-01-17 05:38 AM, Fujii Masao wrote:
On Fri, Jan 13, 2012 at 5:02 PM, Fujii Masao wrote:
The amount of code changes to allow pg_basebackup to make a backup from
the standby seems to be small. So I ended up merging that changes and the
infrastructure patch. WIP patch attached. But I'd happy
On 19 January 2012 17:40, Robert Haas wrote:
> I don't know what you mean by this. I think removing wal_writer_delay
> is premature, because I think it still may have some utility, and the
> patch removes it. That's a separate change that should be factored
> out of this patch and discussed sepa
On Fri, Jan 20, 2012 at 4:17 AM, Simon Riggs wrote:
> On Tue, Jan 17, 2012 at 6:52 AM, Fujii Masao wrote:
>> On Mon, Jan 16, 2012 at 2:06 AM, Simon Riggs wrote:
>>> WALRestore process asynchronously executes restore_command while
>>> recovery continues working.
>>>
>>> Overlaps downloading of ne
> > Make check passed. Patch has tests for rename constraint.
> >
> > Most normal uses of alter table ... rename constraint ... worked
> normally. However, the patch does not deal correctly with constraints
> which are not inherited, such as primary key constraints:
>
> That appears to be because
On Wed, Jan 18, 2012 at 4:23 PM, Dimitri Fontaine
wrote:
> Alvaro Herrera writes:
>> Huh, isn't it simpler to just pass the triggers the parse tree *after*
>> parse analysis? I don't understand what you're doing here.
>
> I didn't realize that the parse analysis is in fact done from within
> sta
On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch wrote:
> > I agree with Merlin; the frontend/backend protocol is logically distinct
> > from
> > the binary send/recv formats of data types. ?For one key point, the latter
> > is
> > not e
On Thu, Jan 19, 2012 at 5:39 PM, Greg Smith wrote:
> On 1/19/12 1:10 PM, Robert Haas wrote:
>> I have to say that I find that intensely counterintuitive. The
>> current settings are not entirely easy to tune correctly, but at least
>> they're easy to explain.
>
> I attempt to explain those settin
On Thu, Jan 19, 2012 at 7:15 PM, Alvaro Herrera
wrote:
>> >> I think we should remove this from the TODO list, or at least document
>> >> that there are a number of reasons why it might be a deeper hole than
>> >> it appears to be at first glance.
>> >
>> > Maybe not remove it, but instead add a l
On Jan 19, 2012, at 4:27 PM, Robert Haas wrote:
> I think the real fix for this problem is to introduce an
> infrastructure inside the database that allows us to have different
> columns stored in different encodings. People use bytea for that
> right now, but that's pretty unfriendly: it would b
On Thu, Jan 19, 2012 at 5:59 PM, Andrew Dunstan wrote:
> OK, then we need to say that very clearly and up front (including in the
> EXPLAIN docs.)
Can do.
> Of course, for data going to the client, if the client encoding is UTF8,
> they should get legal JSON, regardless of what the database enco
Excerpts from Robert Haas's message of jue ene 19 20:53:42 -0300 2012:
>
> On Thu, Jan 19, 2012 at 6:30 PM, Alvaro Herrera
> wrote:
> >
> > Excerpts from Robert Haas's message of jue ene 19 18:07:33 -0300 2012:
> >
> >> I think we should remove this from the TODO list, or at least document
> >>
On Thu, Jan 19, 2012 at 6:30 PM, Alvaro Herrera
wrote:
>
> Excerpts from Robert Haas's message of jue ene 19 18:07:33 -0300 2012:
>
>> I think we should remove this from the TODO list, or at least document
>> that there are a number of reasons why it might be a deeper hole than
>> it appears to be
On Thu, January 19, 2012 21:30, Heikki Linnakangas wrote:
> On 22.11.2011 21:38, Alexander Korotkov wrote:
>> WIP patch with index support for regexp search for pg_trgm contrib is
>> attached.
>> In spite of techniques which extracts continuous text parts from regexp,
>> this patch presents techniq
Excerpts from Robert Haas's message of jue ene 19 18:07:33 -0300 2012:
> I think we should remove this from the TODO list, or at least document
> that there are a number of reasons why it might be a deeper hole than
> it appears to be at first glance.
Maybe not remove it, but instead add a link
On 01/19/2012 04:12 PM, Robert Haas wrote:
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan wrote:
On 01/19/2012 03:49 PM, Robert Haas wrote:
In other words, let's decree that when the database encoding isn't
UTF-8, *escaping* of non-ASCII characters doesn't work. But
*unescaped* non-ASCII c
On 1/19/12 1:10 PM, Robert Haas wrote:
I have to say that I find that intensely counterintuitive. The
current settings are not entirely easy to tune correctly, but at least
they're easy to explain.
I attempt to explain those settings to people in training classes about
once a month. It's nev
On 1/18/12 4:18 PM, Jim Nasby wrote:
What about doing away with all the arbitrary numbers completely, and just state
data rate limits for hit/miss/dirty?
Since many workloads will have a mix of all three, it still seems like
there's some need for weighing these individually, even if they each
On Thu, Dec 22, 2011 at 11:42:23AM -0500, Robert Haas wrote:
> On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut wrote:
> > Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken
> > because the module plpython.so was renamed to plpython2.so, and so the
> > pg_upgrade check for l
On Thu, Jan 19, 2012 at 4:07 PM, Andrew Dunstan wrote:
> On 01/19/2012 03:49 PM, Robert Haas wrote:
>> In other words, let's decree that when the database encoding isn't
>> UTF-8, *escaping* of non-ASCII characters doesn't work. But
>> *unescaped* non-ASCII characters should still work just fine.
On Fri, Jan 20, 2012 at 1:07 AM, Alexander Korotkov wrote:
> What does last 7 zeros in the first column means? No conversion to
> pg_wchar is possible from these encodings?
>
Uh, I see. These encodings is not supported as server encodings.
--
With best regards,
Alexander Korotkov.
On 01/19/2012 03:49 PM, Robert Haas wrote:
In other words, let's decree that when the database encoding isn't
UTF-8, *escaping* of non-ASCII characters doesn't work. But
*unescaped* non-ASCII characters should still work just fine.
The spec only allows unescaped Unicode chars (and for our p
On Sat, Jan 14, 2012 at 5:51 PM, Thomas Munro wrote:
> On 12 January 2012 00:58, Tom Lane wrote:
>> Hmm ... this seems a bit inconsistent with the fact that we got rid of
>> automatic renaming of indexes a year or three back. Won't renaming of
>> serials have all the same problems that caused us
I also have a question about pg_wchar.
/*
*---
* encoding info table
* XXX must be sorted by the same order as enum pg_enc (in mb/pg_wchar.h)
*---
*/
pg_wchar_tbl pg
On Sat, Dec 31, 2011 at 07:41:00PM -0500, Noah Misch wrote:
> On Mon, Dec 05, 2011 at 05:06:37PM -0500, Bruce Momjian wrote:
> > Pg_upgrade has the following check to make sure the cluster is safe for
> > upgrading:
> >
> > res = executeQueryOrDie(conn,
> >
On Thu, Jan 19, 2012 at 3:42 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> I'm with Heikki on not believing that this is a good idea. If you are
>> trying to do careful versioning of a set of object definitions, you want
>> to stick the things in a file, you don't want them just flying by in
On Fri, Jan 20, 2012 at 12:30 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> The code badly needs comments. There is no explanation of how the trigram
>> extraction code in trgm_regexp.c works.
>
> Sure. I hoped to find a time for comments before commitfest starts.
Unfortun
On Sat, Jan 14, 2012 at 3:06 PM, Andrew Dunstan wrote:
> Second, what should be do when the database encoding isn't UTF8? I'm
> inclined to emit a \u escape for any non-ASCII character (assuming it
> has a unicode code point - are there any code points in the non-unicode
> encodings that don't
On Sat, Jan 14, 2012 at 8:40 AM, Peter Eisentraut wrote:
> On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote:
>> I think I would like to have a set of GUC parameters to control the
>> location of the server-side SSL files.
>
> Here is the patch for this.
>
> One thing that is perhaps worth
On Mon, Jan 16, 2012 at 3:47 PM, Magnus Hagander wrote:
> Seem 1575fbcb caused this warning:
>
> view.c: In function ‘DefineVirtualRelation’:
> view.c:105:6: warning: variable ‘namespaceId’ set but not used
> [-Wunused-but-set-variable]
>
> Attached seems to be the easy fix - or am I missing somet
Tom Lane writes:
> I'm with Heikki on not believing that this is a good idea. If you are
> trying to do careful versioning of a set of object definitions, you want
> to stick the things in a file, you don't want them just flying by in
> submitted SQL.
I'm trying to open the extension facilities
On 22.11.2011 21:38, Alexander Korotkov wrote:
WIP patch with index support for regexp search for pg_trgm contrib is
attached.
In spite of techniques which extracts continuous text parts from regexp,
this patch presents technique of automatum transformation. That allows more
comprehensive trigram
On Tue, Jan 17, 2012 at 12:38 AM, Fujii Masao wrote:
>> Here is a patch for $SUBJECT. I merely added support for ~, & and |
>> operators for the macaddr type. The patch itself is rather trivial,
>> and includes regression tests and a doc update.
>
> The patch looks fine except that it uses the O
On Mon, Jan 16, 2012 at 3:51 AM, Greg Smith wrote:
> There is an important distinction to make here. Statement logging is one of
> the largest producers of logging data you want to worry about optimizing for
> on a high performance system. The decision about whether to log or not may
> need to b
On Tue, Jan 17, 2012 at 6:52 AM, Fujii Masao wrote:
> On Mon, Jan 16, 2012 at 2:06 AM, Simon Riggs wrote:
>> WALRestore process asynchronously executes restore_command while
>> recovery continues working.
>>
>> Overlaps downloading of next WAL file to reduce time delays in file
>> based archive r
Excerpts from Simon Riggs's message of jue ene 19 16:05:36 -0300 2012:
> On Sun, Jan 15, 2012 at 9:17 PM, Heikki Linnakangas
> wrote:
>
> > I think it makes more sense to use the max read rate as the main knob,
> > rather than write rate. That's because the max read rate is higher than the
> > w
On 01/19/2012 01:41 PM, Alex Shulgin wrote:
With the proposed approach it would only take me to include
@fest comment "Patch applies cleanly"
and possibly
@fest status Needs Review
to update the patch status and that'd be it.
It will be easy if you get it right. My point was that it's w
On Sun, Jan 15, 2012 at 9:17 PM, Heikki Linnakangas
wrote:
> I think it makes more sense to use the max read rate as the main knob,
> rather than write rate. That's because the max read rate is higher than the
> write rate, when you don't need to dirty pages. Or do you think saturating
> the I/O
On tor, 2012-01-12 at 22:43 -0600, Joshua Berkus wrote:
> Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
> 2012-01-12 git checkout.
>
> Patch applied fine.
>
> Docs are present, build, look good and are clear.
>
> Changes to gram.y required Bison 2.5 to compile. Are we re
Excerpts from Alex Shulgin's message of jue ene 19 15:41:54 -0300 2012:
> PS: yes, I could just copy message id from the sent mail in my MUA, but
> I like to make sure links I post aren't broke, so still I'll need to
> wait until archives catches up to double check.
I find this a bad excuse. If
On Thu, Jan 19, 2012 at 10:37 AM, Noah Misch wrote:
> I agree with Merlin; the frontend/backend protocol is logically distinct from
> the binary send/recv formats of data types. For one key point, the latter is
> not exclusively core-defined; third-party extensions change their send/recv
> format
On tor, 2012-01-12 at 21:25 -0800, probabble wrote:
> Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
> 2012-01-12 checkout.
>
> Bison upgraded to v2.5, and downgraded to v2.4.1
>
> Make process for both versions resulted in the following errors:
>
> make[3]: Leaving directo
Andrew Dunstan writes:
> On 01/19/2012 12:59 PM, Alex Shulgin wrote:
>
>> Another idea: introduce some simple tag system in mails sent to -hackers
>> to be treated specially, e.g:
>>
>> @fest add-to-current
>>
>> to add new patch to the commit fest currently in progress, or
>>
>> @fest add-to-ne
On Thu, Jan 19, 2012 at 1:02 PM, Simon Riggs wrote:
> On Thu, Jan 19, 2012 at 5:47 PM, Robert Haas wrote:
>> I feel I've adequate explained why it makes sense to me to separate
>> those options. If you want, I'll do the work myself; it will take
>> less time than arguing about it.
>
> If you hav
Nick Roosevelt writes:
I am sorry, seems like my new MUA was misconfigured so the two previous
attempts to reply to -hackers@ failed. So here goes again.
>Just reviewed the patch for adding URI connection string support for
>libpg.
Thank you for taking your time on this.
>There s
On 01/19/2012 12:59 PM, Alex Shulgin wrote:
Greg Smith writes:
One unicorn I would like to have here would give the CF app a database
of recent e-mails to pgsql-hackers. I login to the CF app, click on
"Add recent submission", and anything matching my e-mail address
appears with a checkbox
On Sun, Jan 15, 2012 at 4:17 PM, Heikki Linnakangas
wrote:
> +1. I've been thinking we should do that for a long time, but haven't gotten
> around to it.
>
> I think it makes more sense to use the max read rate as the main knob,
> rather than write rate. That's because the max read rate is higher
On Thu, Jan 19, 2012 at 5:47 PM, Robert Haas wrote:
> I feel I've adequate explained why it makes sense to me to separate
> those options. If you want, I'll do the work myself; it will take
> less time than arguing about it.
If you have time to contribute, please use the patch as stands to test
Greg Smith writes:
> One unicorn I would like to have here would give the CF app a database
> of recent e-mails to pgsql-hackers. I login to the CF app, click on
> "Add recent submission", and anything matching my e-mail address
> appears with a checkbox next to it. Click on the patch submissi
On Thu, Jan 19, 2012 at 11:46 AM, Simon Riggs wrote:
> On Thu, Jan 19, 2012 at 4:12 PM, Robert Haas wrote:
>> On Thu, Jan 19, 2012 at 10:55 AM, Simon Riggs wrote:
Also, I don't think the behavior described here should be joined at
the hip to --inserts:
+ * We do this a
On Thu, Jan 19, 2012 at 18:12, Robert Haas wrote:
> Right, but the point is that to address Heikki's objection that this
> is a special-purpose hack, we should try to make it general, so that
> it can be used by other people for other things.
Personally I would like to see support for more flexib
On Wed, Jan 18, 2012 at 5:38 PM, Simon Riggs wrote:
> On Wed, Jan 18, 2012 at 1:23 AM, Robert Haas wrote:
>> On Tue, Jan 17, 2012 at 12:37 PM, Heikki Linnakangas
>> wrote:
>>> I found it very helpful to reduce wal_writer_delay in pgbench tests, when
>>> running with synchronous_commit=off. The r
On Jan 19, 2012, at 7:21 AM, Dimitri Fontaine wrote:
> Now, for the dependency on a SQL file hosting the content, it's easier
> to just connect to the databases and get them the script in the SQL
> command rather than deploying a set of files: that means OS level
> packaging, either RPM or debian
On Thu, Jan 19, 2012 at 3:52 PM, Robert Haas wrote:
> And, it doesn't seem like it's necessarily going to safe me a whole
> lot either, because if it turns out that my sync phases are long, the
> first question out of my mouth is going to be "what percentage of my
> total sync time is accounted f
On Thu, Jan 19, 2012 at 4:12 PM, Robert Haas wrote:
> On Thu, Jan 19, 2012 at 10:55 AM, Simon Riggs wrote:
>>> Also, I don't think the behavior described here should be joined at
>>> the hip to --inserts:
>>>
>>> + * We do this after a load by COPY, but before a load via INSERT
>>> +
Dimitri Fontaine writes:
> Heikki Linnakangas writes:
>> Frankly I don't see the point of this. If the extension is an independent
>> piece of (SQL) code, developed separately from an application, with its own
>> lifecycle, a .sql file seems like the best way to distribute it. If it's
>> not, ie.
On Thu, Jan 19, 2012 at 10:55 AM, Simon Riggs wrote:
>> Also, I don't think the behavior described here should be joined at
>> the hip to --inserts:
>>
>> + * We do this after a load by COPY, but before a load via INSERT
>> + *
>> + * This is done deliberately to ensure that n
On Thu, Jan 19, 2012 at 3:51 AM, Kohei KaiGai wrote:
> 2012/1/19 Robert Haas :
>> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
>>> In sepgsql side, it determines a case to apply permission checks
>>> according to the contextual information; that is same technique
>>> when we implemented c
On Thu, Jan 19, 2012 at 3:41 PM, Robert Haas wrote:
> I agree: I think this is useful.
>
> However, I think we should follow the precedent of some of the other
> somewhat-obscure options we've added recently and have only a long
> form option for this: --inserts.
Yep, no problem.
> Also, I don'
On Mon, Jan 16, 2012 at 1:28 AM, Greg Smith wrote:
> One of the most useful bits of feedback on how well checkpoint I/O is going
> is the amount of time taken to sync files to disk. Right now the only way
> to get that is to parse the logs. The attached patch publishes the most
> useful three bi
On Thu, Jan 19, 2012 at 10:18 AM, Simon Riggs wrote:
> On Thu, Jan 19, 2012 at 2:36 PM, Heikki Linnakangas
> wrote:
>> On 12.01.2012 14:31, Simon Riggs wrote:
>>>
>>> In order to simulate real-world clog contention, we need to use
>>> benchmarks that deal with real world situations.
>>>
>>> Curre
Hi Mikko,
First, for everyone else: this patch provides a more-compact binary output
format for arrays. When the array contains no NULL elements and has a
fixed-length element type, the new format saves four bytes per array element.
We could do more. We could add support for arrays containing NU
On Wed, Jan 18, 2012 at 7:15 AM, Fujii Masao wrote:
> On Sun, Nov 13, 2011 at 5:13 PM, Simon Riggs wrote:
>> On Tue, Nov 1, 2011 at 12:11 PM, Simon Riggs wrote:
>>
>>> When I say skip the shutdown checkpoint, I mean remove it from the
>>> critical path of required actions at the end of recovery.
Heikki Linnakangas writes:
> Frankly I don't see the point of this. If the extension is an independent
> piece of (SQL) code, developed separately from an application, with its own
> lifecycle, a .sql file seems like the best way to distribute it. If it's
> not, ie. if it's an integral part of the
On Thu, Jan 19, 2012 at 2:36 PM, Heikki Linnakangas
wrote:
> On 12.01.2012 14:31, Simon Riggs wrote:
>>
>> In order to simulate real-world clog contention, we need to use
>> benchmarks that deal with real world situations.
>>
>> Currently, pgbench pre-loads data using COPY and executes a VACUUM so
On Wed, Jan 18, 2012 at 11:12 PM, Robert Haas wrote:
> On Wed, Jan 18, 2012 at 5:49 PM, Simon Riggs wrote:
>> Can I just check with you that the only review comment is a one line
>> change? Seems better to make any additional review comments in one go.
>
> No, I haven't done a full review yet - I
On 19 January 2012 14:36, Heikki Linnakangas
wrote:
> No doubt this is handy for testing this particular area, but overall I feel
> this is too much of a one-trick pony to include in pgbench.
I don't think that being conservative in accepting pgbench options is
the right way to go. It's already s
On Thu, Jan 19, 2012 at 10:31 PM, Magnus Hagander wrote:
> Applied with fairly extensive modifications. I moved things around,
> switched to using enum instead of int+#define and a few things like
> that. Also changed most of the markup in the docs - I may well have
> broken some previously good l
On 12.01.2012 14:31, Simon Riggs wrote:
In order to simulate real-world clog contention, we need to use
benchmarks that deal with real world situations.
Currently, pgbench pre-loads data using COPY and executes a VACUUM so
that all hint bits are set on every row of every page of every table.
Thu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08.01.2012 22:36, Dimitri Fontaine wrote:
The extension mechanism we added in 9.1 is aimed at allowing a fully
integrated contrib management, which was big enough a goal to preclude
doing anything else in its first release.
Hooray!
Now we have it and we can think some more about what featu
Excerpts from Hitoshi Harada's message of jue ene 19 07:08:52 -0300 2012:
> On Sun, Jan 15, 2012 at 10:46 PM, Greg Smith wrote:
> > On 01/16/2012 01:28 AM, Greg Smith wrote:
> >>
> >> -I can't tell for sure if this is working properly when log_checkpoints is
> >> off. This now collects checkpoin
On Wed, Jan 18, 2012 at 16:35, Scott Mead wrote:
>
> On Wed, Jan 18, 2012 at 8:27 AM, Magnus Hagander
> wrote:
>>
>> On Tue, Jan 17, 2012 at 01:43, Scott Mead wrote:
>> >
>> >
>> > On Mon, Jan 16, 2012 at 6:10 PM, Scott Mead wrote:
>> >>
>> >>
>> >> On Sun, Jan 15, 2012 at 4:28 AM, Greg Smith
Hello
This is review of Tomas' patch for counting of using temporary files:
* This patch was cleanly applied and code was compiled
* All 128 tests passed
* There are own regress tests, but usually pg_stat_* functions are not tested
* There is adequate documentation
* This patch was requested
http
On 23.12.2011 02:01, Phil Sorber wrote:
On Thu, Dec 22, 2011 at 3:19 PM, Robert Haas wrote:
On Thu, Dec 22, 2011 at 2:02 PM, Phil Sorber wrote:
On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane wrote:
Robert Haas writes:
I'm wondering if we oughta just return NULL and be done with it.
+1. Ther
On Sun, Jan 15, 2012 at 10:46 PM, Greg Smith wrote:
> On 01/16/2012 01:28 AM, Greg Smith wrote:
>>
>> -I can't tell for sure if this is working properly when log_checkpoints is
>> off. This now collects checkpoint end time data in all cases, whereas
>> before it ignored that work if log_checkpoin
On Wed, Jan 18, 2012 at 1:11 AM, Hitoshi Harada wrote:
> On Sat, Jan 14, 2012 at 8:10 AM, Matthew Draper wrote:
>>
>> I just remembered to make time to advance this from WIP to proposed
>> patch this week... and then worked out I'm rudely dropping it into the
>> last commitfest at the last minute
Thanks for explanation.
Now I remember the discussion on hackers list about this feature, but
anyway, this feature surprised little bit.
G.
2012/1/19 Robert Haas :
> On Wed, Jan 18, 2012 at 9:50 AM, Kohei KaiGai wrote:
>> In sepgsql side, it determines a case to apply permission checks
>> according to the contextual information; that is same technique
>> when we implemented create permission.
>> Thus, it could checks db_xxx:{drop} per
87 matches
Mail list logo
