Sorry for switching gear on you without notice. The logic is something like
this:
When remote node attaches to DB for synchronization then update a
common-to-all-tables version sequence. (ONLY in this case do we increment
the version sequence) This is currently handled by an external perl script
between the client and the backend in which I increment the sequences value
via nextval(version).
Any other time the server is accessed (i.e. normal backends with no perl
script) Ins/Upd/Del triggers are called on tables that are "marked" for
synchronization. The triggers set the effected rows "rowver" column to
version.last_value. Here I do not want to increment the version sequence
every time a row is changed, so I can't just put nextval(version) into the
trigger function. That would blow the synchronization algorithm.
The problem is that "normal" db sessions don't have an "on client connect
trigger" (for lack of better term, one that would fire only once when any
client connection was made and before any ins/upd/dels were processed) that
I can use to initialize the current value of the sequence. The only thing
that was available for version.last_value which I now know is unreliable
between backends.
In the triggers could I perhaps do . . .
1) check some flag to see if I need to initialize the version sequence, or
some flag that tells me that this is the first query executed by the
backend.
2) Initialize the version sequence by doing currval(nextval(version)-1) when
step one is true.
without running into problems across backends? It would increase overhead a
lot, but I'll live with that.
Am I just fooling myself again? Perhaps I'm just a fool.
--rob
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "rob" <rob@cabrion.com>
Cc: <pgsql-general@postgresql.org>; <bmccoy@chapelperilous.net>
Sent: Saturday, January 20, 2001 11:51 AM
Subject: Re: currval was (Re: [GENERAL] Re: Re: is PG able to handle a >500
GB Database? )
> "rob" <rob@cabrion.com> writes:
> > Is there a correct way to "initialize" currval without incrementing the
> > sequence?
>
> No, but for the purpose that was being discussed here, I don't see why
> you'd need to. Maybe you should explain the application logic that
> seems to require such a thing.
>
> regards, tom lane
>
