ng the subject:
https://wiki.postgresql.org/wiki/Pg_dump_improvements
regards,
--
Rafael Martinez Guerrero
Center for Information Technology
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote:
> On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote:
> > We think the behavior should be consistent, either it is allow to use
> > them or not, but not like it is today.
> >
>
> " As a general rule, i
quot;
LINE 3: VALUES (NEW.id, NEW.close)
^
QUERY: INSERT INTO public.test_close_trigger
(id, close)
VALUES (NEW.id, NEW.close)
CONTEXT: PL/pgSQL function test_close() line 3 at SQL statement
-
Thanks in advance.
regards,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/12/2013 03:28 PM, Stephen Frost wrote:
> * Rafael Martinez (r.m.guerr...@usit.uio.no) wrote:
>> Comments?
>
> Create a wiki page for it. :)
>
What about this to start with?:
https://wiki.postgresql.org/wiki/Pg_dump_improvem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 11:20 PM, Josh Berkus wrote:
> On 11/11/2013 06:24 AM, Stephen Frost wrote:
>> * Rafael Martinez (r.m.guerr...@usit.uio.no) wrote:
>>> * We need a pg_dump solution that can generate in one step all
>>> the nece
t do we need to implement some of these changes?
Thanks in advance for your time.
Some background information:
Ref:
http://wiki.postgresql.org/wiki/Todo
http://www.postgresql.org/message-id/4864f001.50...@archonet.com
http://www.postgresql.org/message-id/11646.1272814...@sss.pgh.pa.us
regards,
- --
-f option "
I think we should either update the psql --help information for
- --single-transaction and say that this parameter only works together
with -f or update the psql code so psql -1 < file.sql also works.
regards,
- --
Rafael Martinez Guerrero
Center for Information Technolog
ew keppalive values after the connection was broken. I
will check this later today.
regards,
- --
Rafael Martinez,
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Li
n the moment postgres gets startet in the master.
The only different I can see at the OS level is that in a) the
connection continues to have the status ESTABLISHED forever, and in b)
it gets status TIME_WAIT in the moment postgres is down in the master.
regards,
- --
Rafael Martinez,
Center for I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Haas wrote:
> On Fri, Jun 11, 2010 at 9:29 PM, Rafael Martinez
> I'm somewhat disinclined to try to address this for 9.0. We've had
> this problem for a long time, and I'm not sure that the fact that it
> can now
her server process exited
abnormally and possibly corrupted shared memory.
HINT: In a moment you should be able to reconnect to the database and
repeat your command.
- ----
regards,
- --
Rafael Martinez,
Center for Information Technology Services
U
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fujii Masao wrote:
> On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez
> wrote:
>>
>> Any thoughts about this? Is this a bug or a 'feature'?
>
> This is not a bug. Since pg_start_backup() uses "%X/%X" (not
e of format in 8.3.9 when the WAL ID does
not ends with '00'
* We have had WAL files ending with '00' with versions < 8.3.9 and the
format used have been the expected ("/<8 digits>").
Any thoughts about this? Is this a bug or a 'feature'?
Thanks i
Tom Lane wrote:
> Rafael Martinez writes:
>
>> All PITR backup history files created when running a PITR base backup on
>> all PostgreSQL clusters running in this new server (at different hours
>> during the night) got an identical 2nd part file name.
>
>>
L clusters runnig on the same server.
Is it normal to get the same 2nd part of the file name all the time? How
is this value generated?
This behavior is strange and I wonder if there is anything wrong with
this new server. Everything else looks ok and works without problems.
Thanks in advance
27;ve found it hard
> to justify working on given that it's not that difficult to handle
> outside of the database once the individual pieces are exposed.
>
Great, this is good enough and we get what we need. Thanks :-)
regards
--
Rafael Martinez,
Center for Information Tech
14.php
Maybe this time? :-)
Is there any chance of implementing a way of knowing when was the last
time statistics delivered via pg_stat_* were reset?
regards,
- --
Rafael Martinez,
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/raf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Rafael Martinez writes:
>> I am probably missing the point here, why is it not supposed to show the
>> size of the table(data) *without* indexes?
>
> Because pg_relation_size is defined at the "physic
to
the user and therefore pg_relation_size() should not differentiate
between data saved via toast or not.
The size of the table without the indexes should be reported regardless
the technique used to save the data on the disk.
regards,
- --
Rafael Martinez,
Center for Information Technology Serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Rafael Martinez writes:
>> I wonder why the function pg_relation_size(text) does not take into
>> account the space used by toast data in a table when returning the space
>> used by the table.
>
>
+indexes and pg_relation_size() to return data+toast.
Is this a deliberate decision? Could we change this behavior in the future?
We are using a 8.3 database.
Thanks in advance.
regards,
- --
Rafael Martinez,
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key
Alvaro Herrera wrote:
> Rafael Martinez wrote:
>
>> Shouldn't 'all' be a reserved word?, it has a special meaning when used
>> in pg_hba.conf.
>
> No, it works fine with a line like this:
>
> local "all" all md5
>
Andrew Dunstan wrote:
>
>
> Rafael Martinez wrote:
>>
>> Or throw an error saying 'ALL' is not a valid value and *not* reload the
>> pg_hba.conf file.
>
>
> But it's not invalid. It would designate a database or user named "ALL&q
u use uppercase when you
define connection type or authentication method.
regards,
- --
Rafael Martinez,
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.7 (GNU/Linux)
iD8DBQFKp7GVBh
interfaces (SQL/MED compliant)
* More exotic datatypes
* More query optimizer improvements
* Elimination of vacuum
* Improve XML support
* Pre-parsing phase that converts non-ISO syntax to supported syntax.
Thanks in advance for your feedback.
[1] http://friprog.no/ez/index.php?/nor/English
regards,
rs. We have databases with 9millons+
transactions and 2millons+ inserts/updates a day and we have never had
to run a reindex to get a good performance
PS.- RAID-0 for a database is a disaster waiting to happen.
regards
--
Rafael Martinez, <[EMAIL PROTECTED]>
Center for Information Technology S
are always 1 year back the main release. We are testing and planing
the move to 8.2 now, and it won't happen until desember. In a 6 month
cycle we will have to jump over every second release.
regards
--
Rafael Martinez, <[EMAIL PROTECTED]>
Center for Information Technology Services
Uni
last WAL file not yet archived
* Stops Backup process with pg_stop_backup()
* Waits for *.backup file to appear under the archivedir
* Removes old WAL archived files
* Removes old tar.bz2 data file
To create the tar.bz file and to delete old WAL files can take some
time. The total running time
On Tue, 2006-05-30 at 09:45 -0400, Tom Lane wrote:
> "Rafael Martinez, Guerrero" <[EMAIL PROTECTED]> writes:
> > The problem was that 000100080010.0006D5E8.backup was
> > already archived, but under pg_xlog/archive_s
atches will appear in next week's releases. Thanks again!
>
Thanks to you for finding and fixing the problem :-)
It looks like you are finish so I will update the server and you will
lose access to it.
regards
--
Rafael Martinez, <[EMAIL PROTECTED]>
Center for Information Tech
compile:
pg_dbsize.c: In function `relation_size':
pg_dbsize.c:295: too few arguments to function `textToQualifiedNameList'
make: *** [pg_dbsize] Error 1
Is the second parameter back again?
[1]: http://archives.postgresql.org/pgsql-patches/2005-05/msg00307.php
--
Rafael Martine
r postgres under the same
directory of initdb (/local/opt/postgresql/bin in our example) and not
under the directory of the initdb symblink target.
Any comment to this?
Thanks for your time.
--
Rafael Martinez, <[EMAIL PROTECTED]>
Center for Information Technology Services
University of Oslo, Norway
signature.asc
Description: This is a digitally signed message part
32 matches
Mail list logo
