pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: pgpool versus sequences
20+ messages / 4 participants
[nested] [flat]
* Re: pgpool versus sequences
@ 2011-05-31 15:14 Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 20+ messages in thread
From: Tatsuo Ishii @ 2011-05-31 15:14 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
> Tomasz Chmielewski <mangoo@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 using postgres, and it certainly doesn't do it.
>> [ but pgpool does, as of a couple months ago ]
>> This is a message explaining why it was introduced to pgpool:
>> http://comments.gmane.org/gmane.comp.db.postgresql.pgpool.devel/348
>
> Too bad that wasn't mentioned on pgsql-hackers, where someone might have
> pointed out the major flaws in the idea.
>
>> 2) is pgpool behaviour correct?
>
> No. Quite aside from the lack-of-XID-maintenance problem, the proposal
> seems just plain bizarre to me. SELECT FOR UPDATE wouldn't block
> nextval(), so the command doesn't actually guarantee serialization of
> sequence value acquisition.
Actually it was already explained before:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg00805.php
At the time no one noticed the lack-of-XID-maintenance
problem. Tomasz, thanks for the report. I will go back to old way as
pgpool-II used to do, which is very inefficient unfortunately...
> Taking a table lock on the sequence could
> do so, and wouldn't run into any implementation issues, so I fail to see
> why that alternative was rejected.
Table lock on the sequence? PostgreSQL doesn't allow it...
> I'm also wondering a bit how one
> determines *which* sequence to lock, in a case where the table has
> multiple serial columns ...
No problem at least for pgpool-II. Just choose one of them and obtain
lock on it is enough. Because purpose for the lock is to prevent
concurrent INSERT to the table.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
@ 2011-06-01 22:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2011-06-01 22:04 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
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 case for foreign
tables, so I just extended that idea a bit (by copying-and-pasting
CheckValidResultRel). Questions:
* Does anyone want to bikeshed on the wording of the error messages?
* Does anyone want to argue for not forbidding SELECT FOR UPDATE on
toast tables?
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-01 22:25 ` Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:26 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 2 replies; 20+ messages in thread
From: Robert Haas @ 2011-06-01 22:25 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane <tgl@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 hole. I found that
> somebody had already inserted code to forbid the case for foreign
> tables, so I just extended that idea a bit (by copying-and-pasting
> CheckValidResultRel). Questions:
>
> * Does anyone want to bikeshed on the wording of the error messages?
Not particularly.
> * 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 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 sufficiently new version first.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
@ 2011-06-01 22:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-02 00:15 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:31 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
1 sibling, 3 replies; 20+ messages in thread
From: Tom Lane @ 2011-06-01 22:53 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 1, 2011 at 6:04 PM, Tom Lane <tgl@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 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 sufficiently new version first.
I think you are answering a different question than what I asked.
I was asking about the not-strictly-necessary forbidding of SFU on
toast tables, not sequences.
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 clean up after a bad decision. I'm not
even terribly sure that it would work, since nobody has ever looked at
what would happen if nextval executed concurrently with vacuum doing
something to a sequence. The relfrozenxid logic might have some
difficulty with sequences that have zero relfrozenxid to start with,
too.
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.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-01 23:08 ` Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2 siblings, 1 reply; 20+ messages in thread
From: Tatsuo Ishii @ 2011-06-01 23:08 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: robertmhaas@gmail.com; mangoo@wpkg.org; scott.marlowe@gmail.com; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
> 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 clean up after a bad decision. I'm not
> even terribly sure that it would work, since nobody has ever looked at
> what would happen if nextval executed concurrently with vacuum doing
> something to a sequence. The relfrozenxid logic might have some
> difficulty with sequences that have zero relfrozenxid to start with,
> too.
What pgpool really wanted to do was locking sequence tables, not
locking rows in sequences. I wonder why the former is not allowed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
@ 2011-06-01 23:47 ` Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 00:02 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
0 siblings, 2 replies; 20+ messages in thread
From: Alvaro Herrera @ 2011-06-01 23:47 UTC (permalink / raw)
To: Tatsuo Ishii <ishii@postgresql.org>; +Cc: tgl <tgl@sss.pgh.pa.us>; robertmhaas <robertmhaas@gmail.com>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
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.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
@ 2011-06-02 00:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 00:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
1 sibling, 1 reply; 20+ messages in thread
From: Tom Lane @ 2011-06-02 00:02 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; robertmhaas <robertmhaas@gmail.com>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Alvaro Herrera <alvherre@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 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.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 00:02 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 00:08 ` Tatsuo Ishii <ishii@postgresql.org>
0 siblings, 0 replies; 20+ messages in thread
From: Tatsuo Ishii @ 2011-06-02 00:08 UTC (permalink / raw)
To: tgl@sss.pgh.pa.us; +Cc: alvherre@commandprompt.com; ishii@postgresql.org; robertmhaas@gmail.com; mangoo@wpkg.org; scott.marlowe@gmail.com; kevin.grittner@wicourts.gov; pgsql-hackers@postgresql.org
>> 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 following method for older version of PostgreSQL.
> Probably creating a "secret" relation and acquire table locking
> on it is the way to go. This is essentially a dirty alternative for
> sequence table locking.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
@ 2011-06-02 14:28 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 20+ messages in thread
From: Robert Haas @ 2011-06-02 14:28 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; tgl <tgl@sss.pgh.pa.us>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
<alvherre@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 -- why is LOCK SEQUENCE foo_seq not allowed? Seems a simple thing
> to have.
It cause a grammar conflict. Since SEQUENCE and NOWAIT are both
unreserved keywords, it's not clear to the parser whether "LOCK
SEQUENCE NOWAIT" means to lock a table called SEQUENCE without
waiting, or whether it means to lock a sequence called NOWAIT.
Tom and I discussed possible ways of fixing this on -hackers a few
months ago. Currently the syntax for LOCK is:
LOCK [ TABLE ] [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ];
I suggested fixing this by making TABLE required, thus:
LOCK TABLE [ ONLY ] name [, ...] [ IN lockmode MODE ] [ NOWAIT ];
Tom suggested fixing it by making NOWAIT require IN lockmode MODE, thus:
LOCK [ TABLE ] [ ONLY ] name [,...] [ IN lockmode MODE [ NOWAIT ]];
My proposed fix is probably more likely to break people's
applications, but Tom's isn't completely free from that possibility
either. It's also somewhat counterintuitive IMV. The best option
might be to come up with some completely new syntax that is a little
better designed than the current one, maybe along the lines of the
extensible-options syntax used by EXPLAIN. The trouble is that the
first word of the command would probably have to be something other
than LOCK if we don't want to break backward compatibility with the
existing syntax in some way, and there aren't too many good synonyms
for LOCK. LATCH? FASTEN? Blech. We're probably going to end up
having to make a compatibility break here if we want to support this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
@ 2011-06-02 14:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:42 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:55 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 2 replies; 20+ messages in thread
From: Tom Lane @ 2011-06-02 14:31 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
> <alvherre@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. What would be
trivial is to let this work:
regression=# create sequence s1;
CREATE SEQUENCE
regression=# begin;
BEGIN
regression=# lock table s1;
ERROR: "s1" is not a table
We should do that anyway, even if we put in the effort to support the
other syntax.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 14:42 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:47 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 20+ messages in thread
From: Robert Haas @ 2011-06-02 14:42 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Thu, Jun 2, 2011 at 10:31 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
>> <alvherre@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. What would be
> trivial is to let this work:
>
> regression=# create sequence s1;
> CREATE SEQUENCE
> regression=# begin;
> BEGIN
> regression=# lock table s1;
> ERROR: "s1" is not a table
>
> We should do that anyway, even if we put in the effort to support the
> other syntax.
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. -1 from me on extending that
mess to more places.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:42 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
@ 2011-06-02 14:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 16:50 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
0 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2011-06-02 14:47 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Robert Haas <robertmhaas@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 don't find it so. We have a convention that TABLE is
an umbrella term for all applicable relation types. End of story.
Even if you disagree with that, the convention does exist, and making
LOCK the one command type that disobeys it doesn't seem like a good
plan.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:42 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:47 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 16:50 ` Robert Haas <robertmhaas@gmail.com>
0 siblings, 0 replies; 20+ messages in thread
From: Robert Haas @ 2011-06-02 16:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alvaro Herrera <alvherre@commandprompt.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
On Thu, Jun 2, 2011 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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 don't find it so. We have a convention that TABLE is
> an umbrella term for all applicable relation types. End of story.
>
> Even if you disagree with that, the convention does exist, and making
> LOCK the one command type that disobeys it doesn't seem like a good
> plan.
I agree that wouldn't be a good plan to make LOCK inconsistent with
everything else, but LOCK is not the only case that's like this:
rhaas=# drop table v1;
ERROR: "v1" is not a table
HINT: Use DROP VIEW to remove a view.
rhaas=# comment on table v1 is 'v1 is a view';
ERROR: "v1" is not a table
rhaas=# load 'dummy_seclabel';
LOAD
rhaas=# security label on table v1 is 'classified';
ERROR: "v1" is not a table
As far as I can see, ALTER TABLE is just about the only place where we
allow this; and only for certain command types. Your commit message
seems to indicate that we continue to allow that stuff only for
backward-compatibility:
commit a0b012a1ab85ae115f30e5e4fe09922b4885fdad
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun Jun 15 01:25:54 2008 +0000
Rearrange ALTER TABLE syntax processing as per my recent proposal: the
grammar allows ALTER TABLE/INDEX/SEQUENCE/VIEW interchangeably for all
subforms of those commands, and then we sort out what's really legal
at execution time. This allows the ALTER SEQUENCE/VIEW reference pages
to fully document all the ALTER forms available for sequences and views
respectively, and eliminates a longstanding cause of confusion for users.
The net effect is that the following forms are allowed that weren't before:
ALTER SEQUENCE OWNER TO
ALTER VIEW ALTER COLUMN SET/DROP DEFAULT
ALTER VIEW OWNER TO
ALTER VIEW SET SCHEMA
(There's no actual functionality gain here, but formerly you had to say
ALTER TABLE instead.)
Interestingly, the grammar tables actually get smaller, probably because
there are fewer special cases to keep track of.
I did not disallow using ALTER TABLE for these operations. Perhaps we
should, but there's a backwards-compatibility issue if we do; in fact
it would break existing pg_dump scripts. I did however tighten up
ALTER SEQUENCE and ALTER VIEW to reject non-sequences and non-views
in the new cases as well as a couple of cases where they didn't before.
The patch doesn't change pg_dump to use the new syntaxes, either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 14:55 ` Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 15:10 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 20+ messages in thread
From: Alvaro Herrera @ 2011-06-02 14:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Excerpts from Tom Lane's message of jue jun 02 10:31:58 -0400 2011:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Jun 1, 2011 at 7:47 PM, Alvaro Herrera
> > <alvherre@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. What would be
> trivial is to let this work:
>
> regression=# create sequence s1;
> CREATE SEQUENCE
> regression=# begin;
> BEGIN
> regression=# lock table s1;
> ERROR: "s1" is not a table
Yeah, though it'd be nice to avoid this:
alvherre=# create schema public_too;
CREATE SCHEMA
alvherre=# set search_path to 'public_too', 'public';
SET
alvherre=# create table public_too.s1 ();
CREATE TABLE
alvherre=# create sequence public.s1;
CREATE SEQUENCE
alvherre=# begin;
BEGIN
alvherre=# lock s1;
LOCK TABLE
At this point we have a lock on the table, but if we change LOCK to also
look for sequences, the behavior would change. At the very least, the
command tag should be different.
Hopefully few people name sequences the same as tables ...
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:55 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
@ 2011-06-02 15:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 15:27 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 1 reply; 20+ messages in thread
From: Tom Lane @ 2011-06-02 15:10 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@commandprompt.com>; +Cc: Robert Haas <robertmhaas@gmail.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Alvaro Herrera <alvherre@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 be nice to avoid this:
> alvherre=# create schema public_too;
> CREATE SCHEMA
> alvherre=# set search_path to 'public_too', 'public';
> SET
> alvherre=# create table public_too.s1 ();
> CREATE TABLE
> alvherre=# create sequence public.s1;
> CREATE SEQUENCE
> alvherre=# begin;
> BEGIN
> alvherre=# lock s1;
> LOCK TABLE
> At this point we have a lock on the table, but if we change LOCK to also
> look for sequences, the behavior would change.
No it wouldn't. You seem to be imagining that sequences live in a
different namespace from tables, but they don't. There can only be one
relation that "s1" will refer to for any search_path setting.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 14:28 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:55 ` Re: pgpool versus sequences Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 15:10 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 15:27 ` Alvaro Herrera <alvherre@commandprompt.com>
0 siblings, 0 replies; 20+ messages in thread
From: Alvaro Herrera @ 2011-06-02 15:27 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Robert Haas <robertmhaas@gmail.com>; Tatsuo Ishii <ishii@postgresql.org>; mangoo <mangoo@wpkg.org>; scott.marlowe <scott.marlowe@gmail.com>; Kevin.Grittner <kevin.grittner@wicourts.gov>; pgsql-hackers <pgsql-hackers@postgresql.org>
Excerpts from Tom Lane's message of jue jun 02 11:10:00 -0400 2011:
> Alvaro Herrera <alvherre@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 be nice to avoid this:
>
> > alvherre=# create schema public_too;
> > CREATE SCHEMA
> > alvherre=# set search_path to 'public_too', 'public';
> > SET
> > alvherre=# create table public_too.s1 ();
> > CREATE TABLE
> > alvherre=# create sequence public.s1;
> > CREATE SEQUENCE
> > alvherre=# begin;
> > BEGIN
> > alvherre=# lock s1;
> > LOCK TABLE
>
> > At this point we have a lock on the table, but if we change LOCK to also
> > look for sequences, the behavior would change.
>
> No it wouldn't. You seem to be imagining that sequences live in a
> different namespace from tables, but they don't. There can only be one
> relation that "s1" will refer to for any search_path setting.
Doh, I see that I messed up and reversed the schemas in the search_path
line above. If I fix that I get the expected error:
alvherre=# set search_path to 'public', 'public_too';
SET
alvherre=# lock s1;
ERROR: «s1» no es una tabla
("s1" is not a table). What I was imagining was that LOCK was using
search path to look only for tables and ignoring sequences.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 00:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 0 replies; 20+ messages in thread
From: Tom Lane @ 2011-06-02 00:15 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
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 path for anyone who's at risk at the moment. Of course, this
has to go hand-in-hand with the change to forbid SELECT FOR UPDATE,
else those operations would risk breaking active tuple locks.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
@ 2011-06-02 14:31 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 19:54 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2 siblings, 1 reply; 20+ messages in thread
From: Robert Haas @ 2011-06-02 14:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane <tgl@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 version.
Hmm, I gather from what Tatsuo is saying at the web site that this has
only been broken since the release of 3.0 on February 23rd, so given
that I think your approach makes sense.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:31 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
@ 2011-06-02 19:54 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 20+ messages in thread
From: Tom Lane @ 2011-06-02 19:54 UTC (permalink / raw)
To: Robert Haas <robertmhaas@gmail.com>; +Cc: Tatsuo Ishii <ishii@postgresql.org>; mangoo@wpkg.org; scott.marlowe@gmail.com; t-ishii@sra.co.jp; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 1, 2011 at 6:53 PM, Tom Lane <tgl@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 version.
> Hmm, I gather from what Tatsuo is saying at the web site that this has
> only been broken since the release of 3.0 on February 23rd, so given
> that I think your approach makes sense.
Done, and I also installed a kluge to clean up the damage retroactively
during any nextval/setval operation.
regards, tom lane
^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: pgpool versus sequences
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Re: pgpool versus sequences Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Re: pgpool versus sequences Robert Haas <robertmhaas@gmail.com>
@ 2011-06-01 23:26 ` Tatsuo Ishii <ishii@postgresql.org>
1 sibling, 0 replies; 20+ messages in thread
From: Tatsuo Ishii @ 2011-06-01 23:26 UTC (permalink / raw)
To: robertmhaas@gmail.com; +Cc: tgl@sss.pgh.pa.us; mangoo@wpkg.org; scott.marlowe@gmail.com; Kevin.Grittner@wicourts.gov; pgsql-hackers@postgresql.org
> 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 sufficiently new version first.
Thanks for concerning pgpool and pgpool users.
BTW, there two pgpool-II versions:
- pgpool-II 2.x. uses table lock. has conflict problem with autovacuum
if the target table is fairly large.
- pgpool-II 3.x. uses sequence row lock to avoid the autovacuum
problem. However now it has XID-wrapwround problem and Tom's fix.
So both versions are having problem at this point. Yesterday advisory
locking was suggested, but after thinking while, it seems using
advisory locking make fragile. So I'm still looking for other
ways. Probably creating a "secret" relation and acquire table locking
on it is the way to go. This is essentially a dirty alternative for
sequence table locking.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2011-06-02 19:54 UTC | newest]
Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-05-31 15:14 Re: pgpool versus sequences Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 22:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 22:25 ` Robert Haas <robertmhaas@gmail.com>
2011-06-01 22:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:08 ` Tatsuo Ishii <ishii@postgresql.org>
2011-06-01 23:47 ` Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 00:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 00:08 ` Tatsuo Ishii <ishii@postgresql.org>
2011-06-02 14:28 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:42 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:47 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 16:50 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 14:55 ` Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 15:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 15:27 ` Alvaro Herrera <alvherre@commandprompt.com>
2011-06-02 00:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-02 14:31 ` Robert Haas <robertmhaas@gmail.com>
2011-06-02 19:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2011-06-01 23:26 ` Tatsuo Ishii <ishii@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox