On 1/3/17 1:17 PM, Andreas Karlsson wrote:
> Hm, doesn't this change the intent of the test case? As I read the test
> it seems to make sure that we are allowed to do a read from a sequence
> relation on the slave. If so I think it should be changed to something
> like the below.
>
> select is_
On 01/03/2017 03:30 PM, Peter Eisentraut wrote:
On 1/3/17 7:23 AM, Kuntal Ghosh wrote:
The regression tests for hot standby check fails since it uses the
following statement:
-select min_value as sequence_min_value from hsseq;
which is no longer supported I guess. It should be modified as follow
On 1/3/17 7:23 AM, Kuntal Ghosh wrote:
> The regression tests for hot standby check fails since it uses the
> following statement:
> -select min_value as sequence_min_value from hsseq;
> which is no longer supported I guess. It should be modified as following:
> select min_value as sequence_min_val
On Tue, Dec 20, 2016 at 7:14 PM, Peter Eisentraut
wrote:
> On 12/1/16 9:47 PM, Andreas Karlsson wrote:
>> I think this patch looks good now so I am setting it to ready for committer.
>
> committed, thanks
The regression tests for hot standby check fails since it uses the
following statement:
-sele
On 12/1/16 9:47 PM, Andreas Karlsson wrote:
> I think this patch looks good now so I am setting it to ready for committer.
committed, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hac
On Fri, Dec 2, 2016 at 1:47 PM, Andreas Karlsson wrote:
> I think this patch looks good now so I am setting it to ready for
> committer.
>
> I like the idea of the patch and I think that while this change will break
> some tools which look at the sequence relations I think the advantages are
> wo
I think this patch looks good now so I am setting it to ready for committer.
I like the idea of the patch and I think that while this change will
break some tools which look at the sequence relations I think the
advantages are worth it (for example making more sequence DDL respecting
MVCC).
On 11/11/16 10:06 PM, Andreas Karlsson wrote:
> As pointed out by Peter this patch also requires the changes to
> pg_upgrade. I have not looked at those patches.
The required changes to pg_upgrade have been committed, so that will
work now.
> - The pg_dump tests fails due to the pg_dump code not
On 11/11/16 12:53 PM, Andreas Karlsson wrote:
> Other than my comment above about is_called and last_value I think the
> patch looks great.
I have made that change and committed the patch. Thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
Review for pg_sequence catalog
I like this change since it moves all the parts which should be
transactional to the system catalogs while keeping the only
non-transactional stuff in the sequence relations.
There was some discussion upthread about more compact representations
for the sequence
On 11/10/2016 06:27 AM, Andreas Karlsson wrote:
On 11/10/2016 05:29 AM, Peter Eisentraut wrote:
On 11/8/16 6:43 PM, Andreas Karlsson wrote:
- Shouldn't last_value be NULL directly after we have created the
sequence but nobody has called nextval() yet?
- I noticed that last_value includes the c
On 11/10/2016 05:29 AM, Peter Eisentraut wrote:
On 11/8/16 6:43 PM, Andreas Karlsson wrote:
- A worry is that it might get a bit confusing to have both the future
catalog pg_sequence and the view pg_sequences.
We already have this in other cases: pg_index/pg_indexes,
pg_user_mapping/pg_user_ma
On 11/8/16 6:43 PM, Andreas Karlsson wrote:
> - A worry is that it might get a bit confusing to have both the future
> catalog pg_sequence and the view pg_sequences.
We already have this in other cases: pg_index/pg_indexes,
pg_user_mapping/pg_user_mappings. It's an established naming system by n
Review of the pg_sequences view.
This seems like a useful addition to me, making life easier for
administrators and monitoring tools. While there is already a view in
information_schema it is missing cache_size and last_value.
= Functional review
- The patch applies and passes the test suite
On 9/10/16 7:17 AM, Peter Eisentraut wrote:
> Let's start with that. Here is a patch that adds a pg_sequences view in
> the style of pg_tables, pg_indexes, etc. This seems useful independent
> of anything else, but would give us more freedom to change things around
> behind the scenes.
I have re
On Sun, Sep 11, 2016 at 2:15 PM, Amit Kapila wrote:
> On Sun, Sep 11, 2016 at 12:39 AM, Andres Freund wrote:
>> On 2016-09-10 17:23:21 +0530, Amit Kapila wrote:
>>> >
>>>
>>> I may be missing something here, but why would it contend on a lock,
>>> as per locking scheme proposed by Alvaro, access
On Sun, Sep 11, 2016 at 12:39 AM, Andres Freund wrote:
> On 2016-09-10 17:23:21 +0530, Amit Kapila wrote:
>> >
>>
>> I may be missing something here, but why would it contend on a lock,
>> as per locking scheme proposed by Alvaro, access to sequence object
>> will need a share lock on buffer page.
On 2016-09-10 17:23:21 +0530, Amit Kapila wrote:
> On Thu, Sep 1, 2016 at 12:00 AM, Andres Freund wrote:
> > On 2016-08-31 14:23:41 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >> > On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
> >> >> You are ignoring the performance costs associated with
On Thu, Sep 1, 2016 at 12:00 AM, Andres Freund wrote:
> On 2016-08-31 14:23:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
>> >> You are ignoring the performance costs associated with eating 100x more
>> >> shared buffer space than necessary.
On 9/5/16 10:35 PM, Tom Lane wrote:
> In this viewpoint, we'd keep the sequence-specific data in a pg_sequence
> catalog. pg_sequence rows would be extensions of the associated pg_class
> rows in much the same way that pg_index rows extend the pg_class entries
> for indexes. We should supply a vi
Andres Freund writes:
> On September 5, 2016 7:26:42 AM PDT, Tom Lane wrote:
>> The main problem I can see with this is that serial columns will have
>> default expressions that are written out as
>> "nextval('foo_f1_seq'::regclass)". I do not think we can afford to
>> break dumps containing tha
On September 5, 2016 7:26:42 AM PDT, Tom Lane wrote:
>Simon Riggs writes:
>> On 4 September 2016 at 23:17, Greg Stark wrote:
>>> So? Clients expect changes like this between major releases surely.
>>> Subtle changes that cause silent breakage for end-users seems
>scarier
>>> than unsubtle brea
Simon Riggs writes:
> On 4 September 2016 at 23:17, Greg Stark wrote:
>> So? Clients expect changes like this between major releases surely.
>> Subtle changes that cause silent breakage for end-users seems scarier
>> than unsubtle breakage that tool authors can fix.
> Agreed; some change in the
On 4 September 2016 at 23:17, Greg Stark wrote:
> On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane wrote:
>>
>> Uh, not as subtly as all that, because "select * from sequence" will
>> now return a different set of columns, which will flat out break a
>> lot of clients that use that method to get sequenc
On Wed, Aug 31, 2016 at 3:01 PM, Tom Lane wrote:
>
> Uh, not as subtly as all that, because "select * from sequence" will
> now return a different set of columns, which will flat out break a
> lot of clients that use that method to get sequence properties.
So? Clients expect changes like this bet
On 2016-08-31 14:23:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
> >> You are ignoring the performance costs associated with eating 100x more
> >> shared buffer space than necessary.
>
> > I doubt that's measurable in any real-world scenario.
Andres Freund writes:
> On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
>> You are ignoring the performance costs associated with eating 100x more
>> shared buffer space than necessary.
> I doubt that's measurable in any real-world scenario. You seldomly have
> hundreds of thousands of sequences th
On 2016-08-31 13:59:48 -0400, Tom Lane wrote:
> and...@anarazel.de (Andres Freund) writes:
> > On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote:
> >> Yes, sure, we're still improving even if we stick to one-seq-per-bufpage,
> >> but while we're at it, we could as well find a way to make it as bes
and...@anarazel.de (Andres Freund) writes:
> On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote:
>> Yes, sure, we're still improving even if we stick to one-seq-per-bufpage,
>> but while we're at it, we could as well find a way to make it as best as
>> we can. And allowing multiple seqs per page s
On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> >
> > On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> > > Improving on the space wastage is exactly the point IMO. If it's still
> > > going to be 8k per sequence on disk (*and* in shared buffers, remember),
> >
Andres Freund wrote:
> Hi,
>
> On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> > Improving on the space wastage is exactly the point IMO. If it's still
> > going to be 8k per sequence on disk (*and* in shared buffers, remember),
> > I'm not sure it's worth all the work to change things at all.
>
Hi,
On 2016-08-31 12:53:30 -0400, Tom Lane wrote:
> Improving on the space wastage is exactly the point IMO. If it's still
> going to be 8k per sequence on disk (*and* in shared buffers, remember),
> I'm not sure it's worth all the work to change things at all.
A separate file is a heck lot more
Andres Freund writes:
> On 2016-08-31 12:56:45 -0300, Alvaro Herrera wrote:
>> I was thinking that nextval could grab a shared buffer lock and release
>> immediately, just to ensure no one holds exclusive buffer lock
>> concurrently (which would be used for things like dropping one seq tuple
>> fr
On 2016-08-31 12:56:45 -0300, Alvaro Herrera wrote:
> I was thinking that nextval could grab a shared buffer lock and release
> immediately, just to ensure no one holds exclusive buffer lock
> concurrently (which would be used for things like dropping one seq tuple
> from the page, when a sequence
Andres Freund wrote:
> On 2016-08-31 11:23:27 -0400, Tom Lane wrote:
> > Another issue is what is the low-level interlock between nextvals
> > in different processes. Right now it's the buffer lock on the
> > sequence's page. With a scheme like this, if we just kept doing
> > that, we'd have a si
On 2016-08-31 11:23:27 -0400, Tom Lane wrote:
> Another issue is what is the low-level interlock between nextvals
> in different processes. Right now it's the buffer lock on the
> sequence's page. With a scheme like this, if we just kept doing
> that, we'd have a single lock covering probably O(1
Craig Ringer writes:
> On 31 August 2016 at 22:01, Tom Lane wrote:
>> Personally, my big beef with the current approach to sequences is that
>> we eat a whole relation (including a whole relfilenode) per sequence.
>> I wish that we could reduce a sequence to just a single row in a
>> catalog, inc
On 31/08/16 16:10, Tom Lane wrote:
I wrote:
Personally, my big beef with the current approach to sequences is that
we eat a whole relation (including a whole relfilenode) per sequence.
I wish that we could reduce a sequence to just a single row in a
catalog, including the nontransactional state.
On 31 August 2016 at 22:01, Tom Lane wrote:
> Personally, my big beef with the current approach to sequences is that
> we eat a whole relation (including a whole relfilenode) per sequence.
> I wish that we could reduce a sequence to just a single row in a
> catalog, including the nontransactional
I wrote:
> Personally, my big beef with the current approach to sequences is that
> we eat a whole relation (including a whole relfilenode) per sequence.
> I wish that we could reduce a sequence to just a single row in a
> catalog, including the nontransactional state. Not sure how feasible
> that
Craig Ringer writes:
> On 31 August 2016 at 21:17, Peter Eisentraut
> wrote:
>> I don't know if this is a net improvement. Maybe this introduces as
>> many new issues as it removes. But I figured I'll post this, so that at
>> least we can discuss it.
> This will change behaviour subtly.
Uh, n
On 31 August 2016 at 21:17, Peter Eisentraut
wrote:
> While I was hacking around sequence stuff, I felt the urge to look into
> an old peeve: That sequence metadata is not stored in a proper catalog.
> Right now in order to find out some metadata about sequences (min, max,
> increment, etc.), you
42 matches
Mail list logo
