Robert Haas writes:
> On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane wrote:
>> Please note also that what pgpool users have got right now is a time
>> bomb, which is not better than immediately-visible breakage. I would
>> prefer to try to get this change out ahead of widespread adoption of the
>> bro
On Thu, Jun 2, 2011 at 10:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> Ugh. We are already stuck supporting all kinds of backward
>> compatibility cruft in tablecmds.c as a result of the fact that you
>> used to have to use ALTER TABLE to operate on views and sequences.
>> The whole thing is
Excerpts from Tom Lane's message of jue jun 02 11:10:00 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
> >> That's a lot of work for a purely cosmetic issue, though. What would be
> >> trivial is to let this work:
> >> regression=# loc
Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
> Robert Haas writes:
> > On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
> > wrote:
> >> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
> >> to have.
>
> > It cause a grammar conflict.
>
> That's a lot o
On Thu, Jun 2, 2011 at 10:31 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
>> wrote:
>>> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
>>> to have.
>
>> It cause a grammar conflict.
>
> That's a lot of work for a purely cosm
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
>> That's a lot of work for a purely cosmetic issue, though. What would be
>> trivial is to let this work:
>> regression=# lock table s1;
>> ERROR: "s1" is not a table
> Yeah, though it'd be nice to avo
Robert Haas writes:
> Ugh. We are already stuck supporting all kinds of backward
> compatibility cruft in tablecmds.c as a result of the fact that you
> used to have to use ALTER TABLE to operate on views and sequences.
> The whole thing is confusing and a mess.
[ shrug... ] I don't find it so.
Robert Haas writes:
> On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
> wrote:
>> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
>> to have.
> It cause a grammar conflict.
That's a lot of work for a purely cosmetic issue, though. What would be
trivial is to let this wor
On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane wrote:
> Please note also that what pgpool users have got right now is a time
> bomb, which is not better than immediately-visible breakage. I would
> prefer to try to get this change out ahead of widespread adoption of the
> broken pgpool version.
Hmm, I
On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
wrote:
> Excerpts from Tatsuo Ishii's message of mié jun 01 19:08:16 -0400 2011:
>> What pgpool really wanted to do was locking sequence tables, not
>> locking rows in sequences. I wonder why the former is not allowed.
>
> Yeah -- why is LOCK SEQUENCE
I wrote:
> Please note also that what pgpool users have got right now is a time
> bomb, which is not better than immediately-visible breakage.
BTW, so far as that goes, I suggest that we tweak nextval() and setval()
to force the sequence tuple's xmax to zero. That will provide a simple
recovery p
Alvaro Herrera writes:
> Excerpts from Tatsuo Ishii's message of mié jun 01 19:08:16 -0400 2011:
>> What pgpool really wanted to do was locking sequence tables, not
>> locking rows in sequences. I wonder why the former is not allowed.
> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a
>> Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
>> to have.
>
> I don't see any particular reason to continue to disallow it, but does
> that actually represent a workable solution path for pgpool? Switching
> over to that would fail on older servers.
pgpool will provi
Excerpts from Tatsuo Ishii's message of mié jun 01 19:08:16 -0400 2011:
> What pgpool really wanted to do was locking sequence tables, not
> locking rows in sequences. I wonder why the former is not allowed.
Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
to have.
--
Álv
> Maybe. How hard would it be to fix that so it doesn't blow up? What
> I don't like about the proposed solution is that it will cause very
> user-visible breakage as a result of a minor release upgrade, for
> anyone using pgpool, which is a lot of people; unless pgpool is
> upgraded to a suffici
> If we're going to try to retroactively make the world safe for pgpool
> doing what it's doing, the only way is to start including sequences in
> the set of objects that are vacuumed and included in
> relfrozenxid/datfrozenxid bookkeeping. Which is a lot more overhead
> than I think is justified
Robert Haas writes:
> On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane wrote:
>> * Does anyone want to argue for not forbidding SELECT FOR UPDATE on
>> toast tables?
> Maybe. How hard would it be to fix that so it doesn't blow up? What
> I don't like about the proposed solution is that it will cause v
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane wrote:
> I wrote:
> I think the most appropriate solution may be to disallow SELECT FOR
> UPDATE/SHARE on sequences ... so if you have a good reason why we
> shouldn't do so, please explain it.
>
> Attached is a proposed patch to close off this
I wrote:
I think the most appropriate solution may be to disallow SELECT FOR
UPDATE/SHARE on sequences ... so if you have a good reason why we
shouldn't do so, please explain it.
Attached is a proposed patch to close off this hole. I found that
somebody had already inserted code to
> Tomasz Chmielewski writes:
>> On 31.05.2011 05:16, Tom Lane wrote:
>>> I think the most appropriate solution may be to disallow SELECT FOR
>>> UPDATE/SHARE on sequences ... so if you have a good reason why we
>>> shouldn't do so, please explain it.
>
>> I grepped the sources of the application
Tomasz Chmielewski writes:
> On 31.05.2011 05:16, Tom Lane wrote:
>> I think the most appropriate solution may be to disallow SELECT FOR
>> UPDATE/SHARE on sequences ... so if you have a good reason why we
>> shouldn't do so, please explain it.
> I grepped the sources of the application using pos
21 matches
Mail list logo
