Hi,
I am now studying PostgreSQL.
in your web site:
Developer's Frequently Asked Questions (FAQ) for
PostgreSQL
Technical Questions
2.1) How do I efficiently access information in
tables from the backend code?
Since heap_open function needs the oid of the
relation, how
Gurjeet Singh said:
Also, I would recommend uninstalling cygwin before you install
mingw, because if the mingw doesn't behave properly (gcc won't compile
files etc...), you could be sure that there definitely is a conflict
between the cygwin and mingw.
If you don't wish to uninstall
I was just telling one of the ways to avoid the conflicts. It
generally happens that a newbie adds the cygwin paths to the env
variables and if he forgets to remove those, then, you know better,
which tools he'd be using!!! In such cases, a less experienced person
would just give up.
I
Currently, WAL files will be archived as soon as archive_command is set.
IMHO, this is not desirable if no permanent backup is wanted, but only
scheduled online backup because; it will flood the wal_archive
destination with files that will never be used.
I propose to introduce a GUC
If you call it exactly once, it'll say that exactly once. If you keep
calling it millions of times, it'll keep saying that.
OK. I wonder, though, why at some point it does in fact return 0.
Indeed. You forgot to complete the COPY sequence before returning
to the PQgetResult loop. As long
ipig wrote:
2.1) How do I efficiently access information in tables from the backend code?
Since heap_open function needs the oid of the relation, how can I get
those parameters for heap_open?
Suppose that at the beginning, I only know the name of the relation,
which functions I need to
That's not workable, unless you want to assume that nothing on the
system except Postgres uses SysV semaphores. Otherwise something else
could randomly gobble up the semid you want to use. I don't care very
much for requiring a distinct semid to be hand-specified for each
postmaster on a
On Thursday 25 May 2006 14:35, korry wrote:
That's not workable, unless you want to assume that nothing on the
system except Postgres uses SysV semaphores. Otherwise something else
could randomly gobble up the semid you want to use. I don't care very
much for requiring a distinct semid
I am having trouble remembering the name of the new GUC parameter,
standard_conforming_strings. I am thinking standard_strings is
clearer, and shorter. I would like to rename this. The parameter will
be new in 8.2.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB
Alvaro Herrera wrote:
ipig wrote:
2.1) How do I efficiently access information in tables from the backend
code?
Since heap_open function needs the oid of the relation, how can I get
those parameters for heap_open?
Suppose that at the beginning, I only know the name of the
Andreas Pflug [EMAIL PROTECTED] writes:
I propose to introduce a GUC permanent_archiving or so, to select
whether wal archiving happens permanently or only when a backup is in
progress (i.e. between pg_start_backup and pg_stop_backup).
This is silly. Why not just turn archiving on and off?
Massimiliano Poletto [EMAIL PROTECTED] writes:
If you call it exactly once, it'll say that exactly once. If you keep
calling it millions of times, it'll keep saying that.
OK. I wonder, though, why at some point it does in fact return 0.
Probably because you ran out of memory to create new
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
What I don't get is why everybody think that because one solution doesn't fit
all needs on all platforms(or NFS), it shouldn't be implemented on those
platforms it *does* work on.
(1) Because we're not really interested in supporting multiple
Bruce Momjian pgman@candle.pha.pa.us writes:
I am having trouble remembering the name of the new GUC parameter,
standard_conforming_strings. I am thinking standard_strings is
clearer, and shorter. I would like to rename this. The parameter will
be new in 8.2.
The name is already out in
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to force the
move.
Bruce,
You know that there is a tall stack of finicky, time-consuming work in
order to make
HiCan anyone offer advice on this please: Intermittently a postgres process appears to crash and the postmaster service needs restarting. The following is entered in the log:2006-03-15 09:50:03 LOG: server process (PID 348) was terminated by signal 125 2006-03-15 09:50:03 LOG: terminating
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
I propose to introduce a GUC permanent_archiving or so, to select
whether wal archiving happens permanently or only when a backup is in
progress (i.e. between pg_start_backup and pg_stop_backup).
This is silly. Why not just turn
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is silly. Why not just turn archiving on and off?
Not quite. I want online backup, but no archiving. Currently, I have to
edit postgresql.conf and SIGHUP to turn on archiving configuring a
(hopefully) writable directory, do the
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
This is silly. Why not just turn archiving on and off?
Not quite. I want online backup, but no archiving. Currently, I have to
edit postgresql.conf and SIGHUP to turn on archiving configuring a
(hopefully) writable
David Fetter wrote:
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to force the
move.
Bruce,
You know that there is a tall stack of finicky,
On Thursday 25 May 2006 10:47, chelsea boot wrote:
Hi
Can anyone offer advice on this please: Intermittently a postgres process
appears to crash and the postmaster service needs restarting. The
following is entered in the log:
2006-03-15 09:50:03 LOG: server process (PID 348) was
Bruce Momjian wrote:
David Fetter wrote:
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to force the
move.
Bruce,
You know that there is a tall stack of
On Thu, May 25, 2006 at 10:11:13AM -0700, Joshua D. Drake wrote:
Bruce Momjian wrote:
David Fetter wrote:
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to
I'm not used to the PG Internals. But let me see if I understood that.The LIKE operator, when applied on a static string and it is not preceded by '%', causes the planner to search for some indexes in the table in order to make a index scan. Otherwise,
i.e. using leading '%' on static text or
On Thu, 25 May 2006, Bruce Momjian wrote:
David Fetter wrote:
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to force the
move.
Bruce,
You know that there
David Fetter wrote:
On Thu, May 25, 2006 at 10:11:13AM -0700, Joshua D. Drake wrote:
Bruce Momjian wrote:
David Fetter wrote:
On Wed, May 24, 2006 at 10:33:53PM -0400, Bruce Momjian wrote:
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a
Larry Rosenman wrote:
I have Pervasive's blessing to spend paid time working on community
projects,
and this could be one of them, but every time I try to get more
information about
how things on BOTH gborg and pgfoundry are set up, it takes days, and
lots of the
people have no idea how it
Andreas Pflug [EMAIL PROTECTED] writes:
When dumping the table with psql \copy (non-binary), the resulting file
would be 6.6GB of size, taking about 5.5 minutes. Using psql \copy WITH
BINARY (modified psql as posted to -patches), the time was cut down to
21-22 seconds (filesize 1.4GB as
On Thu, 25 May 2006, Andrew Dunstan wrote:
Larry Rosenman wrote:
I have Pervasive's blessing to spend paid time working on community
projects, and this could be one of them, but every time I try to get more
information about
how things on BOTH gborg and pgfoundry are set up, it takes days,
On Thu, May 25, 2006 at 02:18:10PM -0300, Rodrigo Hjort wrote:
make a index scan. Otherwise, i.e. using leading '%' on static text or bound
paremeter, makes the planner always do a sequential scan. Is that the
scenario?
I think more exactly, the planner can't possibly know how to plan an
The thing is, I thought that the scripting work for this was already
done? Since we're doing CVS-CVS and mailman-mailman, the only major
scripting effort was required on the gborg-sql - pgfoundry-sql side of
things, which I *thought* was already written, just needed alot of testing?
I
Hello,
I encountered this the other day and set up a build farm client for it.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=meerkatdt=2006-05-25%2018:16:36
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
When dumping the table with psql \copy (non-binary), the resulting file
would be 6.6GB of size, taking about 5.5 minutes. Using psql \copy WITH
BINARY (modified psql as posted to -patches), the time was cut down to
21-22 seconds
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
Looking at CopySendData, I wonder whether any traction could be gained
by trying not to call fwrite() once per character. I'm not sure how
much per-call overhead there is in that function. We've done a lot of
work trying to optimize
Joshua D. Drake [EMAIL PROTECTED] writes:
I encountered this the other day and set up a build farm client for it.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=meerkatdt=2006-05-25%2018:16:36
That NaN problem has been discussed before, and I believe we concluded
it's a compiler bug. See
On Thu, 25 May 2006, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I encountered this the other day and set up a build farm client for it.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=meerkatdt=2006-05-25%2018:16:36
That NaN problem has been discussed before, and I
I'm just experimenting a bit with GIN, and it is occasionally getting
stuck looping in findParents() during WAL replay.
The attached patch seems to fix it. I also had to set ptr-off as
advertised in the comment above the function to avoid triggering
assertions.
GIN isn't fully transparent to me
Joshua D. Drake wrote:
The thing is, I thought that the scripting work for this was already
done? Since we're doing CVS-CVS and mailman-mailman, the only major
scripting effort was required on the gborg-sql - pgfoundry-sql side
of things, which I *thought* was already written, just needed alot
On May 25, 2006, at 11:24 AM, Andreas Pflug wrote:
BTW, I don't actually understand why you want this at all. If you're
not going to keep a continuing series of WAL files, you don't have
any
PITR capability. What you're proposing seems like a bulky,
unportable,
hard-to-use equivalent of
Marc,
The thing is, I thought that the scripting work for this was already
done? Since we're doing CVS-CVS and mailman-mailman, the only major
scripting effort was required on the gborg-sql - pgfoundry-sql side of
things, which I *thought* was already written, just needed alot of
testing?
Jim Nasby wrote:
On May 25, 2006, at 11:24 AM, Andreas Pflug wrote:
BTW, I don't actually understand why you want this at all. If you're
not going to keep a continuing series of WAL files, you don't have any
PITR capability. What you're proposing seems like a bulky, unportable,
hard-to-use
Andreas Pflug [EMAIL PROTECTED] writes:
That's right, but my proposal would implicitely switch on archiving
while backup is in progress, thus explicitely enabling/disabling
archiving wouldn't be necessary.
I'm not sure you can expect that to work. The system is not built to
guarantee
I think more exactly, the planner can't possibly know how to plan anindexscan with a leading '%', because it has nowhere to start.
The fact is that index scan is performed on LIKE _expression_ on a string not preceded by '%', except when bound parameter is used.
select * from table where field
Bruce,
I am asking again: what is the timetable for merging gborg and
pgfoundry, and if not, can we set a date to shut down to force the move.
Looking more like mid-June. I didn't have the time for this at the
beginning of May that I thought I would have.
--
--Josh
Josh Berkus
PostgreSQL
Rodrigo Hjort [EMAIL PROTECTED] writes:
I think more exactly, the planner can't possibly know how to plan an
indexscan with a leading '%', because it has nowhere to start.
The fact is that index scan is performed on LIKE expression on a string not
preceded by '%', except when bound
45 matches
Mail list logo
