I am currently attempting to migrate one of our customers databases to
partitioned tables. This database is used to store firewall logs and
is currently in the range of 600GB (thats 90 days worth).
I am having problems with the rewrite rules though it seems to be skipping over
any rule that has
hi all,
Yahoo China sponsored a small project to build a WebDB interface
based on HTTP/JSON/REST etc. and it could be found from here:
http://search.cpan.org/~agent/OpenResty-0.1.10/lib/OpenResty.pm
any comments are welcome!
-laser
--
Sent via pgsql-general mailing list (pgsql-general@postgr
Craig Ringer <[EMAIL PROTECTED]> writes:
> I've just hit a reproducible error with a query that uses pg_trgm:
> ERROR: too many LWLocks taken
This is absolutely a bug. Please send a complete test case to
pgsql-bugs.
regards, tom lane
--
Sent via pgsql-general mailing l
Hi
I've just hit a reproducible error with a query that uses pg_trgm:
ERROR: too many LWLocks taken
I'm using PostgreSQL 8.3.1 .
The database is the one generated by the script I posted recently for
reading .po files. It's tiny, with only 7000 records in the table being
queried to produce this
Craig Ringer wrote:
BLazeD wrote:
[quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
exist: timestamp without time zone > time without time zone
That's really odd. I can't imagine why the timestamp > timestamp
operator might be absent.
Hmm I managed to read that erro
At 11:27p -0400 on Fri, 18 Apr 2008, BLazeD wrote:
[quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
exist: timestamp without time zone > time without time zone at character
14\nHINT: No operator matches the given name and argument type(s). You
might need to add explicit t
BLazeD <[EMAIL PROTECTED]> writes:
> [quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
> exist: timestamp without time zone > time without time zone at character
> 14
Well, it's quite right, there is no such operator.
PG 8.3 complains about this, whereas previous versions w
On Fri, Apr 18, 2008 at 9:04 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Apr 2008 14:59:34 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > I find it pretty unlikely that Slony would be unable to help you
> > upgrade here. Obviously you can upgrade one database at a time.
On Sun, Apr 20, 2008 at 12:48 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Sun, 20 Apr 2008 11:32:58 -0600
> "Scott Marlowe" <[EMAIL PROTECTED]> wrote:
>
> > Exactly. There are several things you can do on the replica that you
> > wouldn't do on the master for better performance. Really
On Sun, 20 Apr 2008 11:32:58 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> Exactly. There are several things you can do on the replica that you
> wouldn't do on the master for better performance. Really big numbers
> of WAL segments, no background writer, fsync off as mentioned, WAL on
> a
Just checking if the JDBC library's batch processing code is more
efficient with respect to the postgresql back end or not. Does it
really batch the requests and submit them once over the link, or does it
just send them to the database to be processed one at a time?
Thanks,
David
--
Sent via
On Friday 18 April 2008 8:27 pm, BLazeD wrote:
> Hi All
>
> I recently changed hosts for my PHP/PostgreSQL site and have been seeing
> alot of errors in the errors logs and also some on the site.
>
> [quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
> exist: timestamp without
BLazeD wrote:
[quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
exist: timestamp without time zone > time without time zone
That's really odd. I can't imagine why the timestamp > timestamp
operator might be absent.
What's the output of the command "select version()" on y
Zoltan Boszormenyi wrote:
> select version();
>
> It will tell you the compiler version and arch as well. You can deduce
> from there.
That approach is not reliable. I often build and run a 32-bit build of
PostgreSQL on a machine that claims to be something like
x86_64-unknown-linux-gnu.
--
S
On Sun, Apr 20, 2008 at 11:12 AM, Scott Ribe <[EMAIL PROTECTED]> wrote:
> > I am going to play with this and see where it breaks, but it's going to be
> > an enormous time investment to babysit it.
>
> One thing to remember, since you've already got backup in place and this
> replica would just
> I am going to play with this and see where it breaks, but it's going to be
> an enormous time investment to babysit it.
One thing to remember, since you've already got backup in place and this
replica would just be for upgrading, not a hot spare, turn off fsync during
the initial subscription. M
No, both negative.
Michael
Tom Lane wrote:
Michael Enke <[EMAIL PROTECTED]> writes:
For my setup, in 8.1 a delete query which deletes 20 entries depending on
rows in another table
runs about 7h, in 8.2 (and later) it runs 9s!
If those rowcount estimates are even close to accurate, the
On 18 Apr, 14:12, [EMAIL PROTECTED] (Karsten Hilbert) wrote:
>
> If one wants to operate on one/a range of row(s) but the
> code fetches "all" rows (for various values of all) then I'd
> suspect there's something missing in the SQL statement, say,
> a LIMIT or appropriate WHERE conditions - regardl
"Richard Huxton" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Dave wrote:
>> Lets say I have a Postgresql table where I store uploaded data for
>> all users, identified by user_id column. Is it possible to run a
>> query to measure the storage a user is consuming?
>
> Not really.
Hi All
I recently changed hosts for my PHP/PostgreSQL site and have been seeing
alot of errors in the errors logs and also some on the site.
[quote]PHP Warning: pg_query(): Query failed: ERROR: operator does not
exist: timestamp without time zone > time without time zone at character
14\nHINT:
20 matches
Mail list logo
