[HACKERS] Question about SHM_QUEUE
Hello, I have a question about SHM_QUEUE. Why do we need this component? We've already made some modules under the assumption that the base offset of shared memory is mapped to the same address for all processes. See comment in freespace.h: * Note: we handle pointers to these items as pointers, not as SHMEM_OFFSETs. * This assumes that all processes accessing the map will have the shared * memory segment mapped at the same place in their address space. Then, can we replace SHM_QUEUE by a pointer-based double-linked list? It will be an intrusive version of Dllist. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] prepared statements logging
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 10, 2007 at 02:53:32AM -0700, marcofuics wrote:
Hi *
I am using the postgresql-8.2.3, with a jdbc-8.2-504 (the GeoNet
webServer tool...) My question is :
Is the PostGresDB server able to log the whole SELECT query?
{made by a prepared statement}
Looking at the log I can see only queries of the type:
TIP 5: don't forget to increase your free space map settings
Wrong list. This is one dedicated for people working on the innards of
PostgreSQL. You'd want one of pgsql-admin@postgresql.org or
[EMAIL PROTECTED].
Now to your question: there are many configuration parameters in the
config file (possibly in /etc/postgresql/8.2/main/postgresql.conf or
some similar location, depending on your OS and distribution) to control
the level of logging. Look there for entries named log_xxx and
debug_xxx.
HTH
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGHHpCBcgs9XrR2kYRAs4SAJ45gvCVcp4Avk4t7NgQ/SST0s35owCggdWQ
CcVc9UluRe4d/Gl8ERV7z4I=
=P8EJ
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] CIC and deadlocks
On 4/1/07, Tom Lane [EMAIL PROTECTED] wrote: Good point. I'm envisioning a procarray.c function along the lines of bool TransactionHasSnapshot(xid) which returns true if the xid is currently listed in PGPROC and has a nonzero xmin. CIC's cleanup wait loop would check this and ignore the xid if it returns false. Your point means that this function would have to take exclusive not shared lock while scanning the procarray, which is kind of annoying, but it seems not fatal since CIC isn't done all that frequently. When I looked at the code, it occurred to me that possibly we are OK with just taking shared lock on the procarray. That means that some other transaction can concurrently set its serializable snapshot while we are scanning the procarray. But that should not harm us: if we see the snapshot set, we wait for the transaction. A transaction which is setting its serializable snapshot NOW, can not see the tuples that we did not index, isn't it ? A patch based on the discussion is attached. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com CIC_deadlock.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about SHM_QUEUE
ITAGAKI Takahiro [EMAIL PROTECTED] writes: I have a question about SHM_QUEUE. Why do we need this component? It's a hangover from Berkeley days that no one has felt a need to remove yet. The convention back then was that shared memory might be mapped to different addresses in different processes. We've since adopted the assumption that everyone will see the same addresses, but we have not made any attempt to eradicate the old approach everywhere. Then, can we replace SHM_QUEUE by a pointer-based double-linked list? It will be an intrusive version of Dllist. What exactly will you gain by it? I'm not inclined to fool with that code for trivial reasons ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [DOCS] uuid type not documented
On 4/10/07, Peter Eisentraut [EMAIL PROTECTED] wrote: The problem is that most of the standard methods are platform dependent, as they require MAC addresses or a good random source, for instance. FYI: good random source is already available in pgcrypto, it uses either OpenSSL RAND_bytes() or internal strong PRNG. -- marko ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CIC and deadlocks
Pavan Deolasee [EMAIL PROTECTED] writes: When I looked at the code, it occurred to me that possibly we are OK with just taking shared lock on the procarray. That means that some other transaction can concurrently set its serializable snapshot while we are scanning the procarray. But that should not harm us: if we see the snapshot set, we wait for the transaction. A transaction which is setting its serializable snapshot NOW, can not see the tuples that we did not index, isn't it ? [ itch... ] The problem is with time-extended execution of GetSnapshotData; what happens if the other guy lost the CPU for a good long time while in the middle of GetSnapshotData? He might set his xmin based on info you saw as long gone. You might be correct that it's safe, but the argument would have to hinge on the OldestXmin process being unable to commit because of someone holding shared ProcArrayLock; a point you are definitely not making above. (Study the comments in GetSnapshotData for awhile, also those in xact.c's commit-related code.) I'm about to head to bed and am certainly in no condition to carry the proof through. Have at it ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Question about SHM_QUEUE
Tom Lane [EMAIL PROTECTED] wrote: I have a question about SHM_QUEUE. Why do we need this component? It's a hangover from Berkeley days that no one has felt a need to remove yet. Then, can we replace SHM_QUEUE by a pointer-based double-linked list? What exactly will you gain by it? I'm not inclined to fool with that code for trivial reasons ... Hmmm, my next question is whether we should use SHM_QUEUE or not in new modules. The point deluded me when I wrote DSM and I wondered the autovacuum-multiworkers patch uses SHM_QUEUE. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CIC and deadlocks
On 4/11/07, Tom Lane [EMAIL PROTECTED] wrote: [ itch... ] The problem is with time-extended execution of GetSnapshotData; what happens if the other guy lost the CPU for a good long time while in the middle of GetSnapshotData? He might set his xmin based on info you saw as long gone. You might be correct that it's safe, but the argument would have to hinge on the OldestXmin process being unable to commit because of someone holding shared ProcArrayLock; a point you are definitely not making above. (Study the comments in GetSnapshotData for awhile, also those in xact.c's commit-related code.) My argument was based on what you said above, but I obviously did not state it well :) Anyways, I think its better to be safe and we agree that its not such a bad thing to take exclusive lock on procarray because CIC is not something that happens very often. Attached is a revised patch which takes exclusive lock on the procarray, rest remaining the same. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com CIC_deadlock_v2.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UPDATE using sub selects
Hi, Hmm. That sounds like it would be a horrid mess. You need to decouple the execution of the subplan from the use of its outputs, apparently. There is some precedent for this in the way that InitPlans are handled: the result of the subplan is stored into a ParamList array entry that's later referenced by a Param node in the parent's expression tree. That would generalize easily enough to setting more than one Param, but I'm not clear on where you'd want to stick the subplan itself in the plan tree, nor on what controls how often it needs to get evaluated. Ended up using something similar to the above suggestion. I have posted the patch to -patches based on this. An important concern was where to stick the evaluation of the subqueries so that they end up becoming subplans which are used in the execution. For this I have added a new field in the Query structure. This entry gets preprocessed similar to other fields of the Query from within subquery_planner. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
[HACKERS] conflicting gettimeofday with MinGW
mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h that is not compatible with port.h. (current is mingw-runtime-3.12) int __cdecl gettimeofday(struct timeval *__restrict__, void *__restrict__ /* tzp (unused) */); The problem was already reported by Marc Lepage on June 26, 2006 shortly after the mingw-runtime release, (He reported back that it was a MinGW installation issue. But it is a version issue.). Now, we could probably make a case that MinGW needs to use struct timezone instead of void, but that change alone still does not make pg compile, because of the #define TIMEZONE_GLOBAL timezone in port.h. Any opinions on how to proceed ? Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] conflicting gettimeofday with MinGW
On Wed, Apr 11, 2007 at 01:45:28PM +0200, Zeugswetter Andreas ADI SD wrote: mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h that is not compatible with port.h. (current is mingw-runtime-3.12) int __cdecl gettimeofday(struct timeval *__restrict__, void *__restrict__ /* tzp (unused) */); The problem was already reported by Marc Lepage on June 26, 2006 shortly after the mingw-runtime release, (He reported back that it was a MinGW installation issue. But it is a version issue.). Now, we could probably make a case that MinGW needs to use struct timezone instead of void, but that change alone still does not make pg compile, because of the #define TIMEZONE_GLOBAL timezone in port.h. Any opinions on how to proceed ? There doesn't happen to be a #define you can set to make mingw backwards compatible with itself and not define that header? We don't use gettimeofday() from them anyway, we use the one in libpgport... //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] UUID generation functions
I have built some UUID generation functions using the library at http://www.ossp.org/pkg/lib/uuid/. This should cover all the usual ways to do it, and it also provides some special constants that could be useful. I have attached the code, but the code is actually against 8.2 with uuid defined as a domain over text, because I needed this functionality in a current project. I will adjust the code for the real uuid type in 8.3 if wanted. What should I do with this? contrib? Example output: test=# select uuid_nil(); uuid_nil -- ---- (1 row) test=# select uuid_ns_dns(); uuid_ns_dns -- 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (1 row) test=# select uuid_ns_url(); uuid_ns_url -- 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (1 row) test=# select uuid_ns_oid(); uuid_ns_oid -- 6ba7b812-9dad-11d1-80b4-00c04fd430c8 (1 row) test=# select uuid_ns_x500(); uuid_ns_x500 -- 6ba7b814-9dad-11d1-80b4-00c04fd430c8 (1 row) test=# select uuid_make_v1(); uuid_make_v1 -- ca06523c-e826-11db-8418-001aa008dc89 (1 row) test=# select uuid_make_v1mc(); uuid_make_v1mc -- cb9df960-e826-11db-bbd1-03614e7a3ea6 (1 row) test=# select uuid_make_v3(uuid_ns_url(), 'http://www.postgresql.org'); uuid_make_v3 -- cf16fe52-3365-3a1f-8572-288d8d2aaa46 (1 row) test=# select uuid_make_v4(); uuid_make_v4 -- ca16279c-f15d-4a33-a066-b657b338ccd8 (1 row) test=# select uuid_make_v5(uuid_ns_url(), 'http://www.postgresql.org'); uuid_make_v5 -- e1ee1ad4-cd4e-5889-962a-4f605a68d94e (1 row) -- Peter Eisentraut http://developer.postgresql.org/~petere/ pg-ossp-uuid.tar.gz Description: application/tgz ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Question about SHM_QUEUE
ITAGAKI Takahiro wrote: Tom Lane [EMAIL PROTECTED] wrote: I have a question about SHM_QUEUE. Why do we need this component? It's a hangover from Berkeley days that no one has felt a need to remove yet. Then, can we replace SHM_QUEUE by a pointer-based double-linked list? What exactly will you gain by it? I'm not inclined to fool with that code for trivial reasons ... Hmmm, my next question is whether we should use SHM_QUEUE or not in new modules. The point deluded me when I wrote DSM and I wondered the autovacuum-multiworkers patch uses SHM_QUEUE. Good question. I used SHM_QUEUE because I just believed the comments that said that ShmemBase would be different on each process, and so using plain pointers would not work. I admit I didn't even try. So if the list can be implemented in a different way, I have no problem with changing that code -- but then, if there's no practical problem with it I feel uninclined to continue messing with the patch until it's committed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Why need XLogReadBuffer have the paramter init?
Cann't we remove this param? We can rewrite like this: 1.XLogReadBuffer: * remove init; * everytime we cann't read a block, just log_invalid_page it, and return InvalidBuffer; 2.Also rewrite all functions calling XLogReadBuffer with init=true: skip current block if XLogReadBuffer return InvalidBuffer. e.g. replace Assert(BufferIsValid(buffer)) with: * if (!BufferIsValid(buffer)) return; Is there any harm? Another question: if oid counter wraparound occured, and one relfilenode was reused, e.g. see the following sequece: 1. Once there was a rel with oid ; 2. Then it's dropped; 3. Then OIDs counter wraparound occured; 4. Another rel was created, and reused oid ; If there's no checkpoint since the first step, and system crashes after step 4, is it possible that the new rel's data be destroyed? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] conflicting gettimeofday with MinGW
Zeugswetter Andreas ADI SD wrote: mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h that is not compatible with port.h. (current is mingw-runtime-3.12) int __cdecl gettimeofday(struct timeval *__restrict__, void *__restrict__ /* tzp (unused) */); The problem was already reported by Marc Lepage on June 26, 2006 shortly after the mingw-runtime release, (He reported back that it was a MinGW installation issue. But it is a version issue.). Now, we could probably make a case that MinGW needs to use struct timezone instead of void, but that change alone still does not make pg compile, because of the #define TIMEZONE_GLOBAL timezone in port.h. Any opinions on how to proceed ? I don't see 3.10 on the download page at http://www.mingw.org/download.shtml The current release is apparently 3.9. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Vista/IPv6
On Windows Vista, IPv6 is enabled by default, and cannot be uninstalled, or disabled easily on the loopback adaptor. localhost is ::1 by default, and the enhanced 'security' makes it insanely difficult to edit the hosts file. This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? Regards Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vista/IPv6
Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Question about SHM_QUEUE
Alvaro Herrera [EMAIL PROTECTED] writes: ITAGAKI Takahiro wrote: Hmmm, my next question is whether we should use SHM_QUEUE or not in new modules. The point deluded me when I wrote DSM and I wondered the autovacuum-multiworkers patch uses SHM_QUEUE. Good question. I used SHM_QUEUE because I just believed the comments that said that ShmemBase would be different on each process, and so using plain pointers would not work. I admit I didn't even try. So if the list can be implemented in a different way, I have no problem with changing that code -- but then, if there's no practical problem with it I feel uninclined to continue messing with the patch until it's committed. The main disadvantage of converting pointers to SHMEM_OFFSETs is that it reduces the compiler's ability to help you find mistakes (ie, treating a pointer to X as a pointer to Y). So I'd encourage people to use plain pointers in new code. But I don't feel a compulsion to convert existing code. Also, in a situation where you'd be writing void * (eg, a generic linked-list type...) there's just no gain in protection anyway. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vista/IPv6
Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vista/IPv6
On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. Let me pre-emt the discussion by saying that the msvc build does not detect ipv6 on the build machine (yet). Are you building with msvc or mingw on this machine? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vista/IPv6
Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. Something is broken then, because it clearly is turned on, yet the pg_hba.conf entry is commented out - hence my report. I assume it's initdb that's doing the check? Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
Magnus Hagander wrote: On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. Let me pre-emt the discussion by saying that the msvc build does not detect ipv6 on the build machine (yet). Are you building with msvc or mingw on this machine? msvc. Grrr. Eta to fix? Regards, Dave. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vista/IPv6
On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote: Magnus Hagander wrote: On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. Let me pre-emt the discussion by saying that the msvc build does not detect ipv6 on the build machine (yet). Are you building with msvc or mingw on this machine? msvc. Grrr. Eta to fix? Eh. None, so far :-) Point being - if you build on a ipv6 enabled machine, will that binary then work at all on a non-ipv6 machine? Consider binaries distributed by the installer... Might as well think up the proper fix before we just band-aid it for the regression tests.. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vista/IPv6
Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander: Point being - if you build on a ipv6 enabled machine, will that binary then work at all on a non-ipv6 machine? Consider binaries distributed by the installer... Might as well think up the proper fix before we just band-aid it for the regression tests.. The check is done by initdb (not on the build machine) and it checks if getaddrinfo(::1, ...) works. If that doesn't work then you don't have IPv6 for all practical purposes. So everything seems to be set up all right. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vista/IPv6
Magnus Hagander wrote: On Wed, Apr 11, 2007 at 03:33:21PM +0100, Dave Page wrote: Magnus Hagander wrote: On Wed, Apr 11, 2007 at 10:08:36AM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 15:36 schrieb Dave Page: This means that the regression tests fail to run, leaving a postmaster.log full of 'no pg_hba.conf entry for host ::1' errors. Should we have initdb enable the ::1 pg_hba.conf trust entry by default on Vista? Any better options? The default installation has that. ... as long as it's present and turned on on the build machine. Let me pre-emt the discussion by saying that the msvc build does not detect ipv6 on the build machine (yet). Are you building with msvc or mingw on this machine? msvc. Grrr. Eta to fix? Eh. None, so far :-) Point being - if you build on a ipv6 enabled machine, will that binary then work at all on a non-ipv6 machine? Consider binaries distributed by the installer... Might as well think up the proper fix before we just band-aid it for the regression tests.. Yes, it should. This was all tested back when we fixed Windows ipv6, around 8.1 timeframe. Look at the source of initdb and you'll see how it works. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Why need XLogReadBuffer have the paramter init?
Jacky Leng [EMAIL PROTECTED] writes: Cann't we remove this param? No. We can rewrite like this: 1.XLogReadBuffer: * remove init; * everytime we cann't read a block, just log_invalid_page it, and return InvalidBuffer; Your proposal degrades the robustness of the system by turning non-error cases into errors. If the caller is able to rewrite the page fully, we should not report an error when it's not available to read. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
Peter Eisentraut wrote:
Am Mittwoch, 11. April 2007 16:46 schrieb Magnus Hagander:
Point being - if you build on a ipv6 enabled machine, will that binary then
work at all on a non-ipv6 machine? Consider binaries distributed by the
installer... Might as well think up the proper fix before we just band-aid
it for the regression tests..
The check is done by initdb (not on the build machine) and it checks if
getaddrinfo(::1, ...) works. If that doesn't work then you don't have IPv6
for all practical purposes. So everything seems to be set up all right.
There is a configure time and a runtime check. The code is below - note
the first #ifdef.
cheers
andrew
#ifdef HAVE_IPV6
/*
* Probe to see if there is really any platform support for IPv6, and
* comment out the relevant pg_hba line if not. This avoids runtime
* warnings if getaddrinfo doesn't actually cope with IPv6.
Particularly
* useful on Windows, where executables built on a machine with IPv6 may
* have to run on a machine without.
*/
{
struct addrinfo *gai_result;
struct addrinfo hints;
int err = 0;
#ifdef WIN32
/* need to call WSAStartup before calling getaddrinfo */
WSADATA wsaData;
err = WSAStartup(MAKEWORD(2, 2), wsaData);
#endif
/* for best results, this code should match parse_hba() */
hints.ai_flags = AI_NUMERICHOST;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = 0;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;
if (err != 0 ||
getaddrinfo(::1, NULL, hints, gai_result) != 0)
conflines = replace_token(conflines,
hostall all ::1,
#hostall all
::1);
}
#else /* !HAVE_IPV6 */
/* If we didn't compile IPV6 support at all, always comment it out */
conflines = replace_token(conflines,
hostall all ::1,
#hostall all ::1);
#endif /* HAVE_IPV6 */
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] UUID generation functions
Peter Eisentraut [EMAIL PROTECTED] writes: I have built some UUID generation functions using the library at http://www.ossp.org/pkg/lib/uuid/. This should cover all the usual ways to do it, and it also provides some special constants that could be useful. What should I do with this? contrib? Adding a new outside dependency in contrib seems to require configure support. If you're willing to do that I have no objection. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] conflicting gettimeofday with MinGW
That page is ages out of date. The intended sync is apparently broken. The current download area is on sourceforge http://sf.net/project/showfiles.php?group_id=2435 Andreas mingw-runtime-3.10 introduced a gettimeofday declaration in sys/time.h that is not compatible with port.h. (current is mingw-runtime-3.12) int __cdecl gettimeofday(struct timeval *__restrict__, void *__restrict__ /* tzp (unused) */); The problem was already reported by Marc Lepage on June 26, 2006 shortly after the mingw-runtime release, (He reported back that it was a MinGW installation issue. But it is a version issue.). Now, we could probably make a case that MinGW needs to use struct timezone instead of void, but that change alone still does not make pg compile, because of the #define TIMEZONE_GLOBAL timezone in port.h. Any opinions on how to proceed ? I don't see 3.10 on the download page at http://www.mingw.org/download.shtml ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Vista/IPv6
Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: There is a configure time and a runtime check. The code is below - note the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] conflicting gettimeofday with MinGW
Zeugswetter Andreas ADI SD wrote: That page is ages out of date. The intended sync is apparently broken. The current download area is on sourceforge http://sf.net/project/showfiles.php?group_id=2435 *sigh* And what is in 3.12, which is apparently the current version? cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] conflicting gettimeofday with MinGW
That page is ages out of date. The intended sync is apparently broken. The current download area is on sourceforge http://sf.net/project/showfiles.php?group_id=2435 *sigh* And what is in 3.12, which is apparently the current version? Sorry that was implied. sys/time.h did not change between 3.10 and 3.12. There is no #define to remove the declaration. In cvs the file is marked as dead and gives a reference to cygwin's w32api. Maybe the answer is to simply note that the mingw-runtime binary from sourceforge above 3.9 has a broken sys/time.h (it is not the file from cygwin but the dead one from cvs). Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] UUID generation functions
# [EMAIL PROTECTED] / 2007-04-11 14:27:47 +0200: I have built some UUID generation functions using the library at http://www.ossp.org/pkg/lib/uuid/. This should cover all the usual ways to do it, and it also provides some special constants that could be useful. There's already a mapping for PostgreSQL in the library, is it bad? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Vista/IPv6
Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: There is a configure time and a runtime check. The code is below - note the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. The configure test just looks for a definition of struct sockaddr_in6. Taking a quick look It seems to me like this is unconditionally there in the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: There is a configure time and a runtime check. The code is below - note the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. The configure test just looks for a definition of struct sockaddr_in6. Taking a quick look It seems to me like this is unconditionally there in the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. That was my question. I just built with ipv6 enabled using my msvc build on my primary machine which does *not* have ipv6, and it still passes regression tests fine. Given that we have a runtime check, is there any reason at all not to enable ipv6 on all builds on msvc? (FWIW, it's been in the platform SDK at least since Windows 2000) //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vista/IPv6
Magnus Hagander wrote: On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: There is a configure time and a runtime check. The code is below - note the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. The configure test just looks for a definition of struct sockaddr_in6. Taking a quick look It seems to me like this is unconditionally there in the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. That was my question. I just built with ipv6 enabled using my msvc build on my primary machine which does *not* have ipv6, and it still passes regression tests fine. Given that we have a runtime check, is there any reason at all not to enable ipv6 on all builds on msvc? (FWIW, it's been in the platform SDK at least since Windows 2000) If we could use configure for MSVC this would have Just Happened (tm). I wonder how many other little bits we miss out on? Anyway, the obvious fix seems to be to add a line to src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vista/IPv6
On Wed, Apr 11, 2007 at 02:24:08PM -0400, Andrew Dunstan wrote: Magnus Hagander wrote: On Wed, Apr 11, 2007 at 02:03:11PM -0400, Andrew Dunstan wrote: Peter Eisentraut wrote: Am Mittwoch, 11. April 2007 17:06 schrieb Andrew Dunstan: There is a configure time and a runtime check. The code is below - note the first #ifdef. Yeah, the problem is that the msvc build has no intelligence to detect the IPv6 APIs to define HAVE_IPV6. So that needs to be developed. The configure test just looks for a definition of struct sockaddr_in6. Taking a quick look It seems to me like this is unconditionally there in the MSVC WS2tcpip.h , so maybe we should just force it for MSVC. That was my question. I just built with ipv6 enabled using my msvc build on my primary machine which does *not* have ipv6, and it still passes regression tests fine. Given that we have a runtime check, is there any reason at all not to enable ipv6 on all builds on msvc? (FWIW, it's been in the platform SDK at least since Windows 2000) If we could use configure for MSVC this would have Just Happened (tm). I wonder how many other little bits we miss out on? Well, if you can make that happen, certainly that'd be nice... (FWIW, I had ipv6 on my list of things to make happen, but I didn't realise it would cause this issue on a machine with ipv6 on it, since I don't have one) Anyway, the obvious fix seems to be to add a line to src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h Won't work, that hits both msvc and mingw. (assuming you maen pg_config.h.win32, since pg_config.h is a generated file) The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vista/IPv6
Magnus Hagander wrote: Anyway, the obvious fix seems to be to add a line to src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h Won't work, that hits both msvc and mingw. (assuming you maen pg_config.h.win32, since pg_config.h is a generated file) The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) Is that not what I suggested? It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. Which new lib? That seems odd since what we do on MinGW does work. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
Andrew Dunstan wrote: Magnus Hagander wrote: Anyway, the obvious fix seems to be to add a line to src/tools/msvc/Solution.pm to #define HAVE_IPV6 1 in pg_config.h Won't work, that hits both msvc and mingw. (assuming you maen pg_config.h.win32, since pg_config.h is a generated file) The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) Is that not what I suggested? I thought you meant put it in the actual .h file that is used to generate pg_config.h from. Apologies for my misunderstanding. It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. Which new lib? That seems odd since what we do on MinGW does work. The winsock libs. Our mingw build links them explicitly to all binaries, the msvc build only links it to the ones that actually need it. And with ipv6 support, initdb suddenly needs it. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] So are we calling it: Feature Freeze?
Bruce Momjian wrote: Joshua D. Drake wrote: Hello, Should we announce? There is some web work etc.. to be done. Sure. I don't remember us doing anything special to annouce feature freeze, but if there is something, please go ahead. Given that nobody else did anything, I've updated the roadmap page a bit for this. Patches are always welcome for further additions ;-) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] New email list about migration?
Should we create an email list just for migration questions? Seems it would be appropriate. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] New email list about migration?
Bruce Momjian wrote: Should we create an email list just for migration questions? Seems it would be appropriate. I think we have enough lists :). Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] New email list about migration?
Joshua D. Drake wrote: Bruce Momjian wrote: Should we create an email list just for migration questions? Seems it would be appropriate. -1 on that. I think we have enough lists :). +1 on that. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Fwd: patch to suppress psql timing output in quiet mode
[forwarded from -patches] I noticed that when psql accepts input from stdin or -f (but not -c), and timing is set to on in .psqlrc, timing results are printed out to stdout even when -q (quiet) is passed in. This may not be the perfect solution, but it fixes the problem (I'm having problems with bash scripts that are borking on time returned). current behavior: [EMAIL PROTECTED] psql]# echo select 0 | psql -tAq 0 Time: 1.155 ms [EMAIL PROTECTED] psql]# psql -tAqcselect 0 0 merlin Index: common.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/common.c,v retrieving revision 1.133 diff -c -r1.133 common.c *** common.c8 Feb 2007 11:10:27 - 1.133 --- common.c11 Apr 2007 17:20:21 - *** *** 918,924 PQclear(results); /* Possible microtiming output */ ! if (OK pset.timing) printf(_(Time: %.3f ms\n), elapsed_msec); /* check for events that may occur during query execution */ --- 918,924 PQclear(results); /* Possible microtiming output */ ! if (OK pset.timing !pset.quiet) printf(_(Time: %.3f ms\n), elapsed_msec); /* check for events that may occur during query execution */ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] [Fwd: Index Advisor]
Gurjeet Singh wrote: The interface etc. may not be beautiful, but it isn't ugly either! It is a lot better than manually creating pg_index records and inserting them into cache; we use index_create() API to create the index (build is deferred), and then 'rollback to savepoint' to undo those changes when the advisor is done. index_create() causes pg_depends entries too, so a 'RB to SP' is far much safer than going and deleting cache records manually. My complaint was not that the API used in the code was non-optimal(which I think was Tom's issue), but that the _user_ API was not very clean. Not sure what to recommend, but I will think about it later. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Vista/IPv6
Magnus Hagander [EMAIL PROTECTED] writes: The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. Try it and find out ;-) ... that's what we have a buildfarm for. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Fix for large file support
If we expose LET_OS_MANAGE_FILESIZE, should we add a flag to the control file so that you can't start a backend that has that defined against a cluster that was initialized without it? On Apr 6, 2007, at 2:45 PM, Tom Lane wrote: [ redirecting to -hackers for wider comment ] Zdenek Kotala [EMAIL PROTECTED] writes: Tom Lane wrote: LET_OS_MANAGE_FILESIZE is good way. I think one problem of this option I fixed. It is size of offset. I went thru the code and did not see any other problem there. However, how you mentioned it need more testing. I going to take server with large disk array and I will test it. I would like to add --enable-largefile switch to configure file to enable access to wide group of users. What you think about it? Yeah, I was going to suggest the same thing --- but not with that switch name. We already use enable/disable-largefile to control whether 64-bit file access is built at all (this mostly affects pg_dump at the moment). I think the clearest way might be to flip the sense of the variable. I never found LET_OS_MANAGE_FILESIZE to be a good name anyway. I'd suggest USE_SEGMENTED_FILES, which defaults to on, and you can turn it off via --disable-segmented-files if configure confirms your OS has largefile support (thus you could not specify both this and --disable-largefile). regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Eliminating unnecessary left joins
I agree with others that the way that query is constructed is a bit odd, but it does bring another optimization to mind: when doing an inner-join between a parent and child table when RI is defined between them, if the query only refers to the child table you can drop the parent table from the join, because each row in the child table must have one and only one row in the parent. Use-case: I'll often use views to make it easier to query several related tables, but not all queries against the views need to hit every table. IE: if a table has several status fields that have RI to parent tables that describe what each status is, you sometimes will query for the status description, sometimes not. I suspect that checking to see if tables have the right unique keys or RI would add a noticeable amount of extra work to query planning, so we might want a GUC to disable it. On Apr 7, 2007, at 12:45 PM, Ottó Havasvölgyi wrote: Sorry, I have left out the PK requirement. What Nicolas wrote is right, I also use an O/R mapper and inheritance is solved with vertical partitioning. The tables are connected to each other with the PK. And the mapper defines views for each class with left joins. The mapper generates queries based on these views. A high fraction of the joins would be eliminated almost in every query. My simple example: Class hierarchy and fields: Shape (ID, X, Y) | +-Circle (ID, Radius) | +-Rectangle (ID, Width, Height) The mapper creates 3 tables with the columns next to the class name. And it creates 3 views. One of them: RectangleView: SELECT r.ID as ID, s.X as X, s.Y as Y, r.Width as Width, r.Height as Height FROM Rectangle r LEFT JOIN Shape s ON ( r.ID=s.ID) Now if I query Rectangle object IDs, whose Width is greater than 5, it will generate this: SELECT ID FROM RectangleView WHERE Width5 In this case I don't need to left join the Shape table, because X and Y columns are not used. The other typical situation is when I execute more complex, not-O/ Rmapper-generated SQL commands based on these views for reporting. For example the average width of rectangles whose height is greater than 10. This optimization should be also applied to subqueries. Is this optimization relatively easy to introduce? I would gladly work on this, but unfortunately I don't know the codebase at all. I would really appreciate if someone competent implemented this feature in 8.4. Thank you in advance, Otto -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] elog(FATAL) vs shared memory
FWIW, you might want to put some safeguards in there so that you don't try to inadvertently kill the backend that's running that function... unfortunately I don't think there's a built-in function to tell you the PID of the backend you're connected to; if you're connecting via TCP you could use inet_client_addr() and inet_client_port(), but that won't work if you're using the socket to connect. On Apr 5, 2007, at 6:23 AM, Stuart Bishop wrote: Mark Shuttleworth wrote: Tom Lane wrote: (1) something (still not sure what --- Martin and Mark, I'd really like to know) was issuing random SIGTERMs to various postgres processes including autovacuum. This may be a misfeature in our test harness - I'll ask Stuart Bishop to comment. After a test is run, the test harness kills any outstanding connections so we can drop the test database. Without this, a failing test could leave open connections dangling causing the drop database to block. CREATE OR REPLACE FUNCTION _killall_backends(text) RETURNS Boolean AS $$ import os from signal import SIGTERM plan = plpy.prepare( SELECT procpid FROM pg_stat_activity WHERE datname=$1, ['text'] ) success = True for row in plpy.execute(plan, args): try: plpy.info(Killing %d % row['procpid']) os.kill(row['procpid'], SIGTERM) except OSError: success = False return success $$ LANGUAGE plpythonu; -- Stuart Bishop [EMAIL PROTECTED] http:// www.canonical.com/ Canonical Ltd.http://www.ubuntu.com/ -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Vista/IPv6
Magnus Hagander wrote: (FWIW, I had ipv6 on my list of things to make happen, but I didn't realise it would cause this issue on a machine with ipv6 on it, since I don't have one) The IPv6 support is finely tuned to deal with all kinds of combinations of API support, library support, and kernel support, or lack thereof, on the build system and on the host system. I suggest that you just use the logic that we have or emulate it, respectively. If it doesn't work, we will find out soon enough. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
Koichi Suzuki [EMAIL PROTECTED] writes: For more information, when checkpoint interval is one hour, the amount of the archived log size was as follows: cp: 3.1GB gzip: 1.5GB pg_compresslog: 0.3GB The notion that 90% of the WAL could be backup blocks even at very long checkpoint intervals struck me as excessive, so I went looking for a reason, and I may have found one. There has been a bug in CVS HEAD since Feb 8 causing every btree page split record to include a backup block whether needed or not. If these numbers were taken with recent 8.3 code, please retest with current HEAD. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: The proper fix is to put it in the msvc build sys, where it writes pg_config.h :-) It also needs a new lib for initdb. I have a patch for it, and it works here, I'm just asking if it's safe to enable it or if it may cause runtmie problems on platforms without ipv6. Try it and find out ;-) ... that's what we have a buildfarm for. Well, on the buildfarm the build host is the test host, so that doesn't quite take care of Magnus' concern. But that said, I do think it will probably Just Work - we did a lot of work during 8.1 to make sure it would, and I see no reason yet to think that work won't apply. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Fix for large file support
Jim Nasby [EMAIL PROTECTED] writes: If we expose LET_OS_MANAGE_FILESIZE, should we add a flag to the control file so that you can't start a backend that has that defined against a cluster that was initialized without it? I imagine we'd flag that as relsegsize = 0 or some such. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
The score below was taken based on 8.2 code, not 8.3 code. So I don't think the below measure is introduced only in 8.3 code. Tom Lane wrote: Koichi Suzuki [EMAIL PROTECTED] writes: For more information, when checkpoint interval is one hour, the amount of the archived log size was as follows: cp: 3.1GB gzip: 1.5GB pg_compresslog: 0.3GB The notion that 90% of the WAL could be backup blocks even at very long checkpoint intervals struck me as excessive, so I went looking for a reason, and I may have found one. There has been a bug in CVS HEAD since Feb 8 causing every btree page split record to include a backup block whether needed or not. If these numbers were taken with recent 8.3 code, please retest with current HEAD. regards, tom lane -- Koichi Suzuki ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
I don't fully understand what transaction log means. If it means archived WAL, the current (8.2) code handle WAL as follows: 1) If full_page_writes=off, then no full page writes will be written to WAL, except for those during onlie backup (between pg_start_backup and pg_stop_backup). The WAL size will be considerably small but it cannot recover from partial/inconsistent write to the database files. We have to go back to the online backup and apply all the archive log. 2) If full_page_writes=on, then full page writes will be written at the first update of a page after each checkpoint, plus full page writes at 1). Because we have no means (in 8.2) to optimize the WAL so far, what we can do is to copy WAL or gzip it at archive time. If we'd like to keep good chance of recovery after the crash, 8.2 provides only the method 2), leaving archive log size considerably large. My proposal maintains the chance of crash recovery the same as in the case of full_page_writes=on and reduces the size of archived log as in the case of full_page_writes=off. Regards; Hannu Krosing wrote: Ühel kenal päeval, T, 2007-04-10 kell 18:17, kirjutas Joshua D. Drake: In terms of idle time for gzip and other command to archive WAL offline, no difference in the environment was given other than the command to archive. My guess is because the user time is very large in gzip, it has more chance for scheduler to give resource to other processes. In the case of cp, idle time is more than 30times longer than user time. Pg_compresslog uses seven times longer idle time than user time. On the other hand, gzip uses less idle time than user time. Considering the total amount of user time, I think it's reasonable measure. Again, in my proposal, it is not the issue to increase run time performance. Issue is to decrease the size of archive log to save the storage. Considering the relatively little amount of storage a transaction log takes, it would seem to me that the performance angle is more appropriate. As I understand it it's not about transaction log but about write-ahead log. and the amount of data in WAL can become very important once you have to keep standby servers in different physical locations (cities, countries or continents) where channel throughput and cost comes into play. With simple cp (scp/rsync) the amount of WAL data needing to be copied is about 10x more than data collected by trigger based solutions (Slony/pgQ). With pg_compresslog WAL-shipping seems to have roughly the same amount and thus becomes a viable alternative again. Is it more efficient in other ways besides negligible tps? Possibly more efficient memory usage? Better restore times for a crashed system? I think that TPS is more affected by number of writes than size of each block written, so there is probably not that much to gain in TPS, except perhaps from better disk cache usage. For me pg_compresslog seems to be a winner even if it just does not degrade performance. -- Koichi Suzuki ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Makefile patch to make gcov work on Postgres contrib modules
I was trying to use gcov on Postgres and ran into a problem where some contrib modules were missing the key libcov symbols and failed to load. Korry very helpfully tracked down the missing bit: the broken modules were ones built using gcc -shared according to the rule in Makefile.linux which doesn't have -lcov. Actually better than adding -lcov, I think this rule really ought to have CFLAGS in it in case there are other CFLAGS that are necessary at link time. Index: src/makefiles/Makefile.linux === RCS file: /home/stark/src/REPOSITORY/pgsql/src/makefiles/Makefile.linux,v retrieving revision 1.22 diff -c -r1.22 Makefile.linux *** src/makefiles/Makefile.linux9 Dec 2005 21:19:36 - 1.22 --- src/makefiles/Makefile.linux11 Apr 2007 00:34:43 - *** *** 11,16 endif %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [EMAIL PROTECTED]: Re: Anyone interested in improving postgresql scaling?]
Kris Kennaway [EMAIL PROTECTED] writes: If there really are users who find 10 proctitle updates/second an unacceptably low update rate, then tune for the default case and provide an option to allow them to override the rate limit to whatever update rate they find appropriate. If you rate limit the naive way you would end up with info that's arbitrarily old and out of date. To get something that's guaranteed not to be older than some maximum age we would have to start with setting timers and setting the proctitle in a signal handler which would be much more complex than what I think you're imagining. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Makefile patch to make gcov work on Postgres contrib modules
Gregory Stark wrote: Actually better than adding -lcov, I think this rule really ought to have CFLAGS in it in case there are other CFLAGS that are necessary at link time. But why would -lcov appear in CFLAGS? If it's a library it should be in LIBS and perhaps in SHLIB_LINK. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Makefile patch to make gcov work on Postgres contrib modules
Gregory Stark [EMAIL PROTECTED] writes: %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ Surely CFLAGS should be irrelevant at link time. Maybe LDFLAGS? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Vista/IPv6
On Wednesday 11 April 2007 12:24, Andrew Dunstan wrote: If we could use configure for MSVC this would have Just Happened (tm). I wonder how many other little bits we miss out on? CMake anyone? wt -- Warren Turkal (w00t) ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
