On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
alvhe...@commandprompt.com 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 --
On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
alvhe...@commandprompt.com 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.
Robert Haas robertmh...@gmail.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, Jun 2, 2011 at 10:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
to have.
It cause a grammar
Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Yeah -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
to have.
It cause a
Excerpts from Tom Lane's message of jue jun 02 11:10:00 -0400 2011:
Alvaro Herrera alvhe...@commandprompt.com 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:
On Thu, Jun 2, 2011 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us 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
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 forbid the
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane t...@sss.pgh.pa.us 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
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 to
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
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.
--
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 provide
Alvaro Herrera alvhe...@commandprompt.com 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
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
Tomasz Chmielewski man...@wpkg.org 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 man...@wpkg.org 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
21 matches
Mail list logo
