> I find it hard to believe this crew's been quiet all day...
Me too. I was absolutely certain that postgresql.org was hosed up ;)
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister c
> just noticed Marc has restarted postmaster at db.hub.org and
> forget to specify -e option (European format!) for backend. That's why
> fts.postgresql.org doesn't works properly. I've sent message to him
> but probably better if somebody could talk with Marc or
> restart corresponding postamast
Hi,
just noticed Marc has restarted postmaster at db.hub.org and
forget to specify -e option (European format!) for backend. That's why
fts.postgresql.org doesn't works properly. I've sent message to him
but probably better if somebody could talk with Marc or
restart corresponding postamaster at
In a very volatile table I have a list of actions which need to be
completed by external systems -- somewhat like a queue. I'd like the
action row to be locked until it's completed so that multiple
processes chewing away at it won't try to complete the same external
action (easy enough -- exclusi
I extracted from Ayal the info that he was using timezone
'Asia/Jerusalem'. That zone has the interesting property that
the DST transitions happen *at midnight*, not at a sane hour like 2AM.
I suspect that that is triggering various & sundry bugs in older
versions of mktime().
On a relatively re
* Rod Taylor <[EMAIL PROTECTED]> [010430 22:10] wrote:
> Corrupted or not, after a crash take a snapshot of the data tree
> before firing it back up again. Doesn't take that much time
> (especially with a netapp filer) and it allows for a virtually
> unlimited number of attempts to solve the trou
