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
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 need to look into the sequence. That is like
having to query
43 matches
Mail list logo
