On Tue, May 22, 2012 at 3:27 PM, Tatsuo Ishii wrote:
> > Thanks for your comments. They clarify a lot.
> > But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
> > Isn't it possible for them to produce same pg_wchar?
>
> If LB is in 0x90 - 0x99 range, then they are LC2.
> If LB
On 24 May 2012 05:30, Peter Eisentraut wrote:
> On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote:
>> I'd be okay with just adding a note in the manual under Date/Time
>> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
>> letter 'T' to separate the date and time. Postgre
Antonin Houska writes:
> On 05/22/2012 09:31 PM, Robert Haas wrote:
>> Also, I think we will want something that implements the LATERAL()
>> syntax, rather than just removing the prohibition on lateral references.
> So you think it's not good to first implement (implicitly) lateral
> functions
On 05/22/2012 09:31 PM, Robert Haas wrote:
This implementation looks different than I'd expect: I would have
thought that it would work by generating paths with param_info set to
the appropriate set of rels to provide the necessary values, rather
than inventing its own mechanism for forcing a n
I wrote:
> Jeff Janes writes:
>> But what happens if the SIGQUIT is blocked before the system(3) is
>> invoked? Does the ignore take precedence over the block, or does the
>> block take precedence over the ignore, and so the signal is still
>> waiting once the block is reversed after the system(3
On 23 May 2012 18:13, Robert Haas wrote:
> On Tue, May 22, 2012 at 5:26 PM, Simon Riggs wrote:
>>> A bigger problem is that creating such an index turns all
>>> of pgbench's write traffic from HOT updates into non-HOT updates,
>>> which means this is probably only going to be a win if the write
On May 23, 2012, at 1:55 PM, Simon Riggs wrote:
>> Well, I *will* point out that you have your work cut out for you on 9.3
>> already ...
>
> Yes, we do. It would be best to conclude that things I do on hackers
> relate in some way to those goals, even if it isn't immediately clear
> how.
Simon
On 23 May 2012 21:15, Josh Berkus wrote:
>> However, given sufficient people speaking against it, I'll leave this idea.
>
> Well, I *will* point out that you have your work cut out for you on 9.3
> already ...
Yes, we do. It would be best to conclude that things I do on hackers
relate in some wa
Jeff Janes writes:
> On Wed, May 23, 2012 at 1:10 PM, Tom Lane wrote:
>> On my machine, man system(3) saith:
>>
>> system() ignores the SIGINT and SIGQUIT signals, and blocks the
>> SIGCHLD signal, while waiting for the command to terminate. If this
>> might cause the application to
On Wed, May 23, 2012 at 1:10 PM, Tom Lane wrote:
> Jeff Janes writes:
>> It looks to me like the SIGQUIT from the postmaster is simply getting
>> lost. And from what little I understand of signal handling, this is a
>> known race with system(3). The archive_command, child of archiver,
>> exits
I wrote:
> On my machine, man system(3) saith:
> system() ignores the SIGINT and SIGQUIT signals, and blocks the
> SIGCHLD signal, while waiting for the command to terminate. If this
> might cause the application to miss a signal that would have killed
> it, the application sh
Simon,
> However, given sufficient people speaking against it, I'll leave this idea.
Well, I *will* point out that you have your work cut out for you on 9.3
already ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Wed, May 23, 2012 at 3:45 PM, Kohei KaiGai wrote:
> I wanted to have discussion to handle this problem.
>
> Unlike leaky-view problem, we don't need to worry about unexpected
> qualifier distribution on either side of join, because a scan on table
> never contains any join. Thus, all we need to
Jeff Janes writes:
> It looks to me like the SIGQUIT from the postmaster is simply getting
> lost. And from what little I understand of signal handling, this is a
> known race with system(3). The archive_command, child of archiver,
> exits before it can receive the signal sent to the entire arch
2012/5/23 Alastair Turner :
> On Wed, May 23, 2012 at 5:09 PM, Tom Lane wrote:
>> Kohei KaiGai writes:
>>> Let me have a discussion to get preferable interface for row-level security.
>>> My planned feature will perform to append additional conditions to WHERE
>>> clause implicitly, to restrict t
Peter Eisentraut writes:
> The postgres -C option was added in 9.2.
> $ postgres -D ... -C shared_buffers
> 4096
> Shouldn't that use units? We use them everywhere else in user
> interfaces.
Hm. But AFAIR, that feature is not meant to support user interfaces,
it's for programs (such as configu
On Wed, May 23, 2012 at 8:11 PM, Fujii Masao wrote:
> On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
>> On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
>>> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander
>>> wrote:
Should we go down the easy way and just reject connections whe
On Mon, May 21, 2012 at 9:22 AM, Fujii Masao wrote:
> On Sat, May 19, 2012 at 1:23 AM, Jeff Janes wrote:
>> I've been testing the crash recovery of REL9_2_BETA1, using the same
>> method I posted in the "Scaling XLog insertion" thread. I have the
>> checkpointer occasionally throw a FATAL error,
2012/5/23 Tom Lane :
> Kohei KaiGai writes:
>> Let me have a discussion to get preferable interface for row-level security.
>> My planned feature will perform to append additional conditions to WHERE
>> clause implicitly, to restrict tuples being visible for the current user.
>> For example, when
Peter Eisentraut writes:
> On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote:
>> I'd be okay with just adding a note in the manual under Date/Time
>> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
>> letter 'T' to separate the date and time. Postgres uses a space for
>
The postgres -C option was added in 9.2.
$ postgres -D ... -C shared_buffers
4096
Shouldn't that use units? We use them everywhere else in user
interfaces.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
On May 22, 2012, at 12:18, Tom Lane wrote:
> Another objection is that it wouldn't scale up nicely to multiple levels
> of catalog hierarchy. But maybe local/global is enough.
That would be a huge improvement and this wouldn't get in the way of
any solution to the global oid conflict issue comin
Jeff Janes writes:
> On Wed, May 23, 2012 at 11:40 AM, Tom Lane wrote:
>> Hmm ... ISTM that that was discussed back when we instituted buffer
>> usage counts, and rejected on the grounds that a newly-read buffer could
>> then have negligible life expectancy. The clock sweep might be just
>> abou
On mån, 2012-05-21 at 15:34 +1000, Brendan Jurd wrote:
> I'd be okay with just adding a note in the manual under Date/Time
> Output to the effect of "Note: ISO 8601 specifies the use of uppercase
> letter 'T' to separate the date and time. Postgres uses a space for
> improved readability, in line w
On tis, 2012-05-22 at 18:00 +0200, Susanne Ebrecht wrote:
> CREATE SCHEMA foo LC_COLLATE bar isn't supported so you went up a
> level and do it by creating a database.
>
> I would like to get default collation per schema / table in 9.2 or 9.3
> but that is my personal wish,
Another way I've been
On Wed, May 23, 2012 at 5:09 PM, Tom Lane wrote:
> Kohei KaiGai writes:
>> Let me have a discussion to get preferable interface for row-level security.
>> My planned feature will perform to append additional conditions to WHERE
>> clause implicitly, to restrict tuples being visible for the curren
On Wed, May 23, 2012 at 2:05 PM, Tom Lane wrote:
> In any case, I would've expected we'd end up changing all these page
> formats if we go over to your concept of a metapage for everything.
> Fixing indexes that already have some kind of metapage will surely be
> trivial compared to fixing heaps.
On Wed, May 23, 2012 at 2:09 PM, Jeff Janes wrote:
> On Wed, May 23, 2012 at 10:33 AM, Amit Kapila wrote:
I don't think there is a clear picture yet of what benchmark to use for
>> testing changes here.
>> I will first try to generate such a scenario(benchmark). I have still not
>> thought co
On Wed, May 23, 2012 at 11:40 AM, Tom Lane wrote:
> Jeff Janes writes:
>> One thing I wanted to play with is having newly read buffers get a
>> usage count of 0 rather than 1. The problem is that there is no way
>> to test it in enough different situations to convince people it would
>> be a gen
>>Do we have any evidence that this is actually a problem which needs to be
solved?
I don't have very clear evidence, didn't generate any profiling report
still. However in the scenario
Where there are many buffers in the list and backend has to traverse it,
there should be reasonable work under
Jeff Janes writes:
> One thing I wanted to play with is having newly read buffers get a
> usage count of 0 rather than 1. The problem is that there is no way
> to test it in enough different situations to convince people it would
> be a general improvement.
Hmm ... ISTM that that was discussed b
>>You need to have shared_buffers be much smaller than RAM, and have almost
all the "disk" data resident in RAM but not
>> in shared_buffers.
Sure, this is better way to generate heavy activity buffers
-Original Message-
From: Jeff Janes [mailto:jeff.ja...@gmail.com]
Sent: Wednesday, May
On Sat, Dec 31, 2011 at 10:34 PM, Simon Riggs wrote:
> Send new protocol keepalive messages to standby servers.
> Allows streaming replication users to calculate transfer latency
> and apply delay via internal functions. No external functions yet.
Is there plan to implement such external function
On Wed, May 23, 2012 at 8:36 AM, Amit Kapila wrote:
>>>And besides
>>>if the decrements are decoupled from the allocation requests it's no
>>>longer obvious that the algorithm is even an approximation of LRU.
>
> I was trying to highlight that we can do the clocksweep in bgwriter and keep
> the ba
On Tue, May 22, 2012 at 11:04 PM, Robert Haas wrote:
> On Mon, May 14, 2012 at 2:24 PM, Fujii Masao wrote:
>> On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander
>> wrote:
>>> Should we go down the easy way and just reject connections when the flag is
>>> mismatching between the client and the se
On Wed, May 23, 2012 at 10:33 AM, Amit Kapila wrote:
>>>I don't think there is a clear picture yet of what benchmark to use for
> testing changes here.
> I will first try to generate such a scenario(benchmark). I have still not
> thought completely.
> However the idea in my mind is that scenario w
On Wed, May 23, 2012 at 2:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> Since we haven't actually released spgist yet, I'm wondering if it
>> should be revised to look more like btree and hash - that is, add a
>> 32-bit version number immediately following the magic number. All
>> experience h
On Wed, May 23, 2012 at 2:00 PM, Jeff Janes wrote:
> On Tue, May 22, 2012 at 11:01 AM, Robert Haas wrote:
>> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>>> Jeff Janes writes:
Now that there are index only scans, there is a use case for having a
composite index which has the prim
Robert Haas writes:
> Since we haven't actually released spgist yet, I'm wondering if it
> should be revised to look more like btree and hash - that is, add a
> 32-bit version number immediately following the magic number. All
> experience hath shown that it is often much more work to add such
>
On Tue, May 22, 2012 at 11:01 AM, Robert Haas wrote:
> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>> Jeff Janes writes:
>>> Now that there are index only scans, there is a use case for having a
>>> composite index which has the primary key or a unique key as the
>>> prefix column(s) but wi
On May 23, 2012, at 10:35 AM, Robert Haas wrote:
>> "Exclusion constraints generalize uniqueness constraints by allowing
>> arbitrary comparison operators, not just equalityThis is useful
>> for time periods and other ranges, as well as arrays."
>
> I objected to it at the time, but lost the
>>I don't think there is a clear picture yet of what benchmark to use for
testing changes here.
I will first try to generate such a scenario(benchmark). I have still not
thought completely.
However the idea in my mind is that scenario where buffer list is heavily
operated upon.
Operations where
On Wed, May 23, 2012 at 1:34 PM, Peter Geoghegan wrote:
> On 13 May 2012 23:45, Robert Haas wrote:
>> Hmm, it looks like GIN can't support exclusive constraints because
>> amgettuple support is required, and unfortunately that got remove for
>> GIN in this commit:
>>
>> commit ff301d6e690bb558150
On 13 May 2012 23:45, Robert Haas wrote:
> Hmm, it looks like GIN can't support exclusive constraints because
> amgettuple support is required, and unfortunately that got remove for
> GIN in this commit:
>
> commit ff301d6e690bb5581502ea3d8591a1600fd87acc
That seems very unfortunate, given that t
A quick survey of our various index AMs reveals that:
1. btree and hash indexes have a metapage that begins with a 32-bit
magic number, followed by a 32-bit version number.
2. spgist has a metapage with a version number, but no magic number.
3. gin has a metapage with a version number that is not
Robert Haas writes:
> I don't object to the feature, but I think it's real-world utility
> will be more limited than we might hope. When covering indexes are
> not in play, someone might choose to index only, say, the primary key.
> And maybe the primary key doesn't change very often, so HOT st
On Tue, May 22, 2012 at 5:26 PM, Simon Riggs wrote:
>> A bigger problem is that creating such an index turns all
>> of pgbench's write traffic from HOT updates into non-HOT updates,
>> which means this is probably only going to be a win if the write
>> volume is miniscule.
>
> Not sure whether yo
On Thu, May 24, 2012 at 1:26 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2012-05-21 at 13:14 -0400, Tom Lane wrote:
>>> ... wait, scratch that. AFAICS, that commit was totally useless,
>>> because BlockSig should always already contain SIGQUIT.
>
>> No, because PostgresMain() delet
On 05/23/2012 11:36 AM, Amit Kapila wrote:
Do you feel I can attempt to address this problem with some prototypes and
discuss here after few days when I have some results ready.
I don't think there is a clear picture yet of what benchmark to use for
testing changes here. Items like "Consider
Peter Eisentraut writes:
> On mån, 2012-05-21 at 13:14 -0400, Tom Lane wrote:
>> ... wait, scratch that. AFAICS, that commit was totally useless,
>> because BlockSig should always already contain SIGQUIT.
> No, because PostgresMain() deletes it from BlockSig.
Ah. So potentially we have an iss
On mån, 2012-05-21 at 13:14 -0400, Tom Lane wrote:
> > ... but having said that, I see Peter's commit
> > d6de43099ac0bddb4b1da40088487616da892164 only touched postgres.c's
> > quickdie(), and not all the *other* background processes with
> identical
> > coding. That seems a clear oversight, so I
On mån, 2012-05-21 at 12:52 -0400, Tom Lane wrote:
> I see Peter's commit d6de43099ac0bddb4b1da40088487616da892164 only
> touched postgres.c's quickdie(), and not all the *other* background
> processes with identical coding. That seems a clear oversight, so I
> will go fix it.
None[*] of the othe
On Tue, May 22, 2012 at 11:33 AM, Jeff Janes wrote:
> On Mon, May 21, 2012 at 2:29 PM, Merlin Moncure wrote:
>> See here:
>> http://www.devheads.net/database/postgresql/performance/index-all-necessary-columns-postgres-vs-mssql.htm
>> for a 'in the wild' gripe about about not having index scans.
>>And besides
>>if the decrements are decoupled from the allocation requests it's no
>>longer obvious that the algorithm is even an approximation of LRU.
I was trying to highlight that we can do the clocksweep in bgwriter and keep
the backends logic as it is currently.
The core idea is that it wil
Kohei KaiGai writes:
> Let me have a discussion to get preferable interface for row-level security.
> My planned feature will perform to append additional conditions to WHERE
> clause implicitly, to restrict tuples being visible for the current user.
> For example, when row-level policy "uname = g
On Mon, May 21, 2012 at 9:37 PM, Simon Riggs wrote:
>>> This is exactly what we do for VACUUM and it works faster there.
>>
>> The reason that's okay for vacuum is that vacuum doesn't care if it
>> visits the same index tuple multiple times. It will not work for real
>> queries, unless you would
On Fri, Mar 2, 2012 at 2:26 PM, Magnus Hagander wrote:
> On Tue, Feb 28, 2012 at 09:22, Fujii Masao wrote:
>> On Thu, Feb 23, 2012 at 1:02 AM, Magnus Hagander wrote:
>>> On Tue, Feb 7, 2012 at 12:30, Fujii Masao wrote:
Hi,
http://www.depesz.com/2012/02/03/waiting-for-9-2-pg_baseb
Let me have a discussion to get preferable interface for row-level security.
My planned feature will perform to append additional conditions to WHERE
clause implicitly, to restrict tuples being visible for the current user.
For example, when row-level policy "uname = getpgusername()" is configured
On May23, 2012, at 00:21 , Josh Berkus wrote:
>> If you could help me work out the semantics and the high-level issues,
>> I'd love to spend time on this for 9.3...
>
> Syntax seems simple: CREATE LOCAL ROLE ...
>
> For that matter, let's keep other things simple:
>
> 1. local roles can inherit
59 matches
Mail list logo
